Properties, CRS and other optional geo_interface items about pygeoif HOT 10 CLOSED

Sorry for answering so late, I have not noticed it.

It is designed after https://gist.github.com/sgillies/2217756 which does not mention the crs.

If you'd like to add it and it does not break anything that would be fine with me. Thanks for bringing this up :-)

from pygeoif.

If I may join the conversation on this, I wrote a slightly nonstandard Feature class for Total Open Station: https://github.com/steko/totalopenstation/blob/3d61f426278b867c5845e92056861c94ab635772/totalopenstation/formats/__init__.py#L33

This was even before pygeoif had a Feature class of its own (actually, both were done on 4th March, go figure! 😀 ). Now I'd like to stick with the pygeoif version, but can we discuss the possibility of having a top-level key id that is not nested in properties, in line with the the GeoJSON spec for Feature objects? If there is agreement on this, I could submit a pull request. Otherwise I will happily subclass from pygeoif.Feature.

Thanks for creating pygeoif and for keeping it alive with contributions from others.

from pygeoif.

I searched through the GeoJSON spec at GeoJSON.org and the Feature seems to
be the only object with this top level ID as an option. Did you notice it
anywhere else?
On Aug 1, 2015 5:27 AM, "Stefano Costa" [email protected] wrote:

If I may join the conversation on this, I wrote a slightly nonstandard
Feature class for Total Open Station:
https://github.com/steko/totalopenstation/blob/3d61f426278b867c5845e92056861c94ab635772/totalopenstation/formats/__init__.py#L33

This was even before pygeoif had a Feature class of its own (actually,
both were done on 4th March, go figure! [image: 😀] ). Now I'd
like to stick with the pygeoif version, but can we discuss the possibility
of having a top-level key id that is not nested in properties, in line
with the the GeoJSON spec for Feature objects? If there is agreement on
this, I could submit a pull request. Otherwise I will happily subclass from
pygeoif.Feature.

Thanks for creating pygeoif and for keeping it alive with contributions
from others.

—
Reply to this email directly or view it on GitHub
#4 (comment).

from pygeoif.

Yes, it's only allowed for Feature objects (my wording was not clear in the previous message).

from pygeoif.

I made a PR ---> #10

Does this work for your use case?

from pygeoif.

Yes, that's what I was thinking of, thanks!

I only have one question: why did you make _feature_id private instead of choosing feature_id? Alternatively, the shorter fid could have been used, too (not saying this short would be the best, just asking).

from pygeoif.

I made _feature_id private because _geometry and _properties have been private since before I started looking at this project. I just wanted to blend in with what was already going on. I should have added a _feature_id = None to the class to match the _properties and _geometry but I just noticed that I missed it.

I preferred to use just id as the variable name but that collides with some python built in stuff as far as I can tell. I used feature_id over fid as it makes the code more readable to me.

from pygeoif.

Right, I see the rationale and I agree. As you say, there should be a _feature_id = None and, I think, also a @property as for _properties and _geometry.

from pygeoif.

I updated #10 based on this discussion.

from pygeoif.

Looks OK.

from pygeoif.