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

Extracting a set of features from FeatureCollection #75

Closed
ConnectedSystems opened this issue Jul 7, 2023 · 12 comments · Fixed by #76
Closed

Extracting a set of features from FeatureCollection #75

ConnectedSystems opened this issue Jul 7, 2023 · 12 comments · Fixed by #76

Comments

@ConnectedSystems
Copy link
Contributor

For a given FeatureCollection, it would be useful to be able to retrieve a set of features, such as:

geodata = GeoJSON.read("some geojson file")

# This works
geodata[1]

# This is not supported
geodata[1:10]

I could submit a PR to do this if there is interest. I believe an additional function hooking into getindex in the general location below would do fine:

https://github.com/JuliaGeo/GeoJSON.jl/blob/f88f2c121bc7c6994fb055171fe663af46ad74a1/src/geojson_types.jl#L268C1-L268C71

Alternatively, if the above isn't desirable, what is the GeoJSON "way" of extracting a set of features?

@rafaqz
Copy link
Member

rafaqz commented Jul 7, 2023

GeoInterface.getfeature is the more generic method for getting features. But also doesnt take a range as far as I know.

But you can broadcast it over a range?

@juliohm
Copy link
Member

juliohm commented Jul 7, 2023

@ConnectedSystems if you are looking into a high-level interface to these geometries and features, take a look at GeoTables.jl which loads all these file formats agnostically into a table type that works like a dataframe:

https://juliaearth.github.io/GeoStats.jl/stable/quickstart.html

Answering your specific question, you can do geodata[1:10,:] if you load geodata = GeoTables.load("foo.geojson").

@ConnectedSystems
Copy link
Contributor Author

ConnectedSystems commented Jul 8, 2023

Thanks @rafaqz that works, don't know why I didn't think of it (you seem to pop up everywhere! Hope you get a break every now and then)

@juliohm @rafaqz a general question if you don't mind. The interface provided by GeoTables/GeoStatsViz seems nice and as a bonus supports geopackages, but it doesn't seem directly compatible with GeoMakie, which is what I am using.

Will the two be compatible at some point, or is one favoured over the other now?

@rafaqz
Copy link
Member

rafaqz commented Jul 8, 2023

@ConnectedSystems haha yes I maintain this too 😳

You can also just convert a GeoJSON.Table directly to a DataFrame, so GeoTables.jl is kind of redundant in this case.

We have done a lot of work making a generic compatability layer with GeoInterface.jl.

So GeoInterface.jl objects can also be used directly in Makie with GeoInterfaceMakie.jl. We can make it automatic here now we have glue packages in Juloa 1.9, we are just all busy and havent had time for all the PRs.

Most JuliaGeo people don't actively work on GeoStats packages, so compatability is generally up to @juliohm

But as the main julia plotting framework now we actively work with Makie and GeoMakie people, and will support compatability efforts going forward.

@juliohm
Copy link
Member

juliohm commented Jul 8, 2023 via email

@rafaqz
Copy link
Member

rafaqz commented Jul 8, 2023

I would suggest instead sticking to the JuliaGeo stack for all use cases and contibuting feature requests, bug reports and fixes to improve the ecosystem if you have problems.

There may be some areas not polished, largely because our dev time is stretched accross actually writing these low level tools, maintaining things like GDAL and LibGEOS, and doing high level plotting (and like everything else we do).

An alternative stack like Meshes/GeoStats that rejects JuliaGeo compatability in some cases and does not contribute to the low level tools it depends on, like this package, is not a long term plan.

@juliohm
Copy link
Member

juliohm commented Jul 9, 2023

An alternative stack like Meshes/GeoStats that rejects JuliaGeo compatability in some cases and does not contribute to the low level tools it depends on, like this package, is not a long term plan.

I understand your frustration @rafaqz, but that is not true. We have submitted issues (#49, #67, JuliaGeo/Shapefile.jl#53, JuliaGeo/Shapefile.jl#95) and pull requests (#68) fixing these issues in the past and plan to continue improving the backends.

Unfortunately you cannot force people to share your vision @rafaqz. Some of us simply do not believe in the statement that the GeoInterface.jl should be used everywhere. We are confident that the path we are taking with Meshes.jl geometries in our stack is the one we need. We cannot afford that interface for various reasons.

I would suggest instead sticking to the JuliaGeo stack for all use cases and contibuting feature requests, bug reports and fixes to improve the ecosystem if you have problems.

Now, regarding your recommendation above, please be more empathetic towards the people who are just trying to use these packages to solve their scientific problems as end-users. I feel that you are completely ignoring their backgrounds when you suggest them to become contributors of low-level packages, disregarding the alternative views in the Julia community as "rebels" who do not fit in your long term plan.

With that said, I wish that people trying out these different packages will have a smooth experience, specially students and those people who are new to Julia programming.

@ConnectedSystems please feel free to reach me out directly on Zulip if you need further assistance with the alternative solution I shared above. I hope it helped you advance with your work somehow.

@yeesian
Copy link
Member

yeesian commented Jul 9, 2023

I could submit a PR to do this if there is interest. I believe an additional function hooking into getindex in the general location below would do fine

@ConnectedSystems I think there is interest and this will be welcome, thank you!

@yeesian
Copy link
Member

yeesian commented Jul 9, 2023

@juliohm I'll appreciate if you do not use github issue threads for promoting packages outside of the scope of the package(s) and the organization that they fall under. (https://github.com/JuliaGeo/meta/blob/master/GettingInvolved.md#ask-questions-for-how-a-given-package-should-work)

@ConnectedSystems
Copy link
Contributor Author

I could submit a PR to do this if there is interest. I believe an additional function hooking into getindex in the general location below would do fine

@ConnectedSystems I think there is interest and this will be welcome, thank you!

Okay, great I will do this soon.

@juliohm I'll appreciate if you do not use github issue threads for promoting packages outside of the scope of the package(s) and the organization that they fall under.

I did ask the initial question so I suppose it's on me for raising the topic.

In any case, thank you @rafaqz and @juliohm for taking the time to respond.

@rafaqz
Copy link
Member

rafaqz commented Jul 12, 2023

@ConnectedSystems its not on you at all, sorry this happened in your issue. Julio started this by coming to promote his GeoTables package.

He made his own separate organisation for those packages so as not to have to collaborate with us. Pointing users there in github issues on packages he does not contribute to is a kind of parasitic behaviour.

I would personally like to see it replaced with actual collaboration and contribution of code before he comments here again.

@juliohm
Copy link
Member

juliohm commented Jul 12, 2023 via email

@JuliaGeo JuliaGeo locked as too heated and limited conversation to collaborators Jul 12, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants