You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I'd like to be able to represent user data with arbitrary field names.
Right now the meta_type macro allows you to specify the designated field name of the geometry, which is position for Point, polygon for Polygon, etc.
Now if I have some user data with the position field present:
using GeometryBasics
p = meta(Point(3, 1), city="Abuja", rainfall=1221.2, position=1)
Users may be surprised that they get the geometry back when they do p.position, and not 1.
One way to work around this is do do explicitly either meta(p).position or metafree(p).
This bugs me a little, so I wanted to bring this up to see if there are alternatives.
Should we leave out getproperty overloading for the geometry altogether? Or does that not work well together with the tables interface?
If we do use getproperty overloading, perhaps it is best to always use the same name, such as geometry, geom, coordinates.
Some geospatial formats that I'd like to represent here also allow naming your geometry field. What can we do in that case?
Probably using a function rather than a symbol is more flexibly here, similarly how R's sf has the st_geometry function.
The text was updated successfully, but these errors were encountered:
I'd like to be able to represent user data with arbitrary field names.
Right now the
meta_type
macro allows you to specify the designated field name of the geometry, which isposition
forPoint
,polygon
forPolygon
, etc.Now if I have some user data with the
position
field present:Users may be surprised that they get the geometry back when they do
p.position
, and not1
.One way to work around this is do do explicitly either
meta(p).position
ormetafree(p)
.This bugs me a little, so I wanted to bring this up to see if there are alternatives.
Should we leave out getproperty overloading for the geometry altogether? Or does that not work well together with the tables interface?
If we do use getproperty overloading, perhaps it is best to always use the same name, such as
geometry
,geom
,coordinates
.Some geospatial formats that I'd like to represent here also allow naming your geometry field. What can we do in that case?
Probably using a function rather than a symbol is more flexibly here, similarly how R's sf has the st_geometry function.
The text was updated successfully, but these errors were encountered: