-
Notifications
You must be signed in to change notification settings - Fork 10
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
Comments
But you can broadcast it over a range? |
@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 |
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? |
@ConnectedSystems haha yes I maintain this too 😳 You can also just convert a 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. |
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
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3OF2G4HTR5D5PYK2ADXPD6NNANCNFSM6AAAAAA2BHGLOY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
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. |
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.
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. |
@ConnectedSystems I think there is interest and this will be welcome, thank you! |
@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) |
Okay, great I will do this soon.
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. |
@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. |
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
<#75 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAZQW3L2GBB3LZ2Y2TBTFYLXPZKQRANCNFSM6AAAAAA2BHGLOY>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
For a given FeatureCollection, it would be useful to be able to retrieve a set of features, such as:
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?
The text was updated successfully, but these errors were encountered: