Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

clashing meta fields #48

Open
visr opened this issue May 22, 2020 · 0 comments
Open

clashing meta fields #48

visr opened this issue May 22, 2020 · 0 comments

Comments

@visr
Copy link
Member

visr commented May 22, 2020

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant