Extracting a set of features from FeatureCollection

[ConnectedSystems]

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]

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]

@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]

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]

@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]

The GeoStats.jl framework and software stack is developed around a single set of well-tested geometries from Meshes.jl that meet the requirements of our advanced geodata science pipelines. GeoTables.jl just loads the data from disk using different backends (GeoJSON.jl Shapefile.jl ArchGDAL.jl) in JuliaGeo and converts the loaded geometries using GeoInterface.jl to Meshes.jl geometries to start the work. It can also save the tables back to disk in any format using these backends.

The JuliaGeo efforts are around the GeoInterface.jl, to make different types of geometries from external libraries (e.g. GDAL, LibGEOS) work in Julia. GeoMakie.jl provides a special axis type that can be used to plot all types of geometries (including Meshes.jl) on different projections. The JuliaGeo geometries themselves are plotted with GeoInterfaceMakie.jl but the recipes are quite rough at this point compared to what we have in our visualization stack devoted to Meshes.jl geometries only.

If you seek a user-friendly experience I recommend our stack at this point. If you seek a well-established set of GIS libraries to perform operations in 2D like LibGEOS, I recommend sticking to the GeoInterface.jl initiative.

Em sáb., 8 de jul. de 2023 03:42, Rafael Schouten @.***> escreveu:

@ConnectedSystems https://github.com/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 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 https://github.com/juliohm

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

— Reply to this email directly, view it on GitHub https://github.com/JuliaGeo/GeoJSON.jl/issues/75#issuecomment-1626887167, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3OF2G4HTR5D5PYK2ADXPD6NNANCNFSM6AAAAAA2BHGLOY . You are receiving this because you were mentioned.Message ID: @.***>

[rafaqz]

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]

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 (https://github.com/JuliaGeo/GeoJSON.jl/issues/49, https://github.com/JuliaGeo/GeoJSON.jl/issues/67, https://github.com/JuliaGeo/Shapefile.jl/issues/53, https://github.com/JuliaGeo/Shapefile.jl/issues/95) and pull requests (https://github.com/JuliaGeo/GeoJSON.jl/pull/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]

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]

@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]

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]

@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]

It is really sad to see that behavior in open source communities. I do not approve it.

Rafael will never accept the fact that I have different opinions on how these geometry types should be used and developed. He calls me a parasit even though I develop Julia packages long before he joined the Julia community... I'm also the parasit who co-developed the JuliaImages, JuliaGraphs and JuliaML organizations and who maintains the main package in JuliaGeometry today, which is Meshes.jl (a package that he is against for personal reasons).

I will also refresh his mind about his "GeoData.jl" attempt, which was a separate effort disconnected from the already existing GeoStats.jl stack. We even made a video call back then to see how we could join efforts, but I quickly realized how he was not interested in making the existing stack better, but just getting attention to his own personal project. He said and I quote:

"You get the stats with GeoStats.jl, I get the data with GeoData.jl"

This kind of mentality that favors personal interest over community and user experience is the one I see as parasitic.

Now, to finalize this discussion, which is very non-productive as usual. Let me point out that the OP asked for a simple question: how to index multiple features at once with GeoJSON.jl. I replied pointing out that a higher level GeoTables.jl package existed wrapping GeoJSON.jl into a table type that has this functionality implemented. I don't think that this is off-topic at all. My intent was to help an end-user and give him/her a workaround.

I'll stop helping JuliaGeo users on GitHub threads following the recommendations above though. I expect that moderators JuliaGeo also jump in when people from the community are called parasits. This should not be acceptable.

Em qua., 12 de jul. de 2023 05:00, Rafael Schouten @.***> escreveu:

@ConnectedSystems https://github.com/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 tgose 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.

— Reply to this email directly, view it on GitHub https://github.com/JuliaGeo/GeoJSON.jl/issues/75#issuecomment-1632032628, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAZQW3L2GBB3LZ2Y2TBTFYLXPZKQRANCNFSM6AAAAAA2BHGLOY . You are receiving this because you were mentioned.Message ID: @.***>