search

yeesian / ArchGDAL.jl

A high level API for GDAL - Geospatial Data Abstraction Library
https://yeesian.github.io/ArchGDAL.jl/stable/
Other
142 stars 26 forks source link

implement Base.getproperty on Feature and FeatureLayer #255

Open visr opened 3 years ago

visr commented 3 years ago

If we iterate through a layer, we get features. These make up our rows in the tables interface. Therefore I assumed they would behave somewhat like a NamedTuple. In https://discourse.julialang.org/t/find-if-point-is-within-geojson-polygons/70416 I tried feature.name to get the name of the feature, but it doesn't work.

Would it be a good idea to add Base.getproperty methods for Features?

Actually now I'm a bit confused. In #118 we defined propertynames and getproperty on the table (then a separate type, now FeatureLayer). It looks like we have to re-add those for FeatureLayer now as well? Or would this conflict with the new schema somehow @mathieu17g?

rafaqz commented 3 years ago

Defining getproperties for the row object should mean the rowaccess-based Tables.jl interface will just work too? Thats how a Vector of NamedTuple works.

Its also nice to have that symmetry where the objects have the same properties as the row names.

visr commented 3 years ago

Yeah although the current Tables interface for ArchGDAL is already row based, since that corresponds to GDAL's data model better.

yeesian commented 3 years ago

Might we run into situations where there are spaces in the fieldnames?

mathieu17g commented 3 years ago

Or would this conflict with the new schema somehow @mathieu17g?

I do not see why it would.