Hi all,
I wanted to follow up on this. I am glad we were able to test the
GeoTools RC and I think this dicussion has been useful. At the minute,
Emilio and I have ways to use either module to do what we want to in
GeoMesa. Given that, nothing here should hold up the release, etc.
Since my PR isn't a great solution (and hence isn't reaching consensus),
I'm fine closing or having someone else closing it.
Emilio and I had a chance to try out the gt-geojsonstore, and we have a
few suggestions for improvements:
1. On the write path, it is our opinion that if you pass in a
writer/stream, then it shouldn't get closed. Instead, it'd make sense
for GeoJSONWriter to implement Flushable.
2. In terms of dependencies, I'd like to suggest that the module use
JTS's GeoJsonWriter[*] for writing out geometries instead of jts-jackson
(which depends on JTS 1.13).
3. On the read path, there's a tiny bug(**) which prevents the use of
URLs.
Further, what all should happen around feature ID handling? Even if the
GeoJSON spec doesn't cover it, would it make sense for the Writer and
Reader to handle feature IDs in a way so that they can be written and
read back in?
Is there a good way to have a consistent FeatureType throughout the
entire GeoJSONReader? Having it change feature to feature is somewhat
unexpected?
Anyhow, I'd love to see GeoTools have a nice SimpleFeatureCollection <->
GeoJson set of libraries. Lemme know how I can help! Just to ask, is
the plan to clean up and promotoe the gt-geojsonstore to an extension?
Cheers,
Jim
*
https://github.com/locationtech/jts/blob/master/modules/io/common/src/main/java/org/locationtech/jts/io/geojson/GeoJsonWriter.java
**
https://github.com/geotools/geotools/blob/master/modules/unsupported/geojsonstore/src/main/java/org/geotools/data/geojson/GeoJSONDataStoreFactory.java#L147
should be 'name' not 'file'.
On 3/18/2020 4:18 PM, Jody Garnett wrote:
Ian could we add a utility class to the gt-geojson jar for handling
this case (parsing geojson in isolation)? The GeoJSONWriter could make
us of the utility class to avoid duplication.
--
Jody Garnett
On Wed, 18 Mar 2020 at 10:42, Emilio Lahr-Vivaz <elahrvi...@ccri.com
<mailto:elahrvi...@ccri.com>> wrote:
Hi Ian,
Do you mean using the GeoJSONDataStore? I wasn't actually aware of
it until now, but I think it wouldn't work to use the feature
writer directly as that will write out to a file, correct? We
(GeoMesa) have a command line tool that abstracts around
OutputStream for exporting data in different formats (json, avro,
parquet, csv, etc) and to different places (stdout, file, hdfs, etc).
One small issue that I see is that the writer closes the
OutputStream:
https://github.com/geotools/geotools/blob/master/modules/unsupported/geojsonstore/src/main/java/org/geotools/data/geojson/GeoJSONWriter.java#L160
This makes it slightly tricky for us to use, as for some use cases
we keep writing to the output stream after writing out the geojson.
I've previously looked around for 'best practices' around when to
close an output stream, and haven't really found any. My thought
is that generally the code that creates the stream should be
responsible for closing it. Would you be open to me putting up a
PR to change the writer behavior in that regard?
Thanks,
Emilio
On 3/18/20 12:40 PM, Ian Turton wrote:
Emilio,
could you not just create a FeatureStore or FeatureWriter and
write features out that way as with any other datastore? But
anyway glad that it seems to work for you.
Ian
On Wed, 18 Mar 2020 at 14:00, Emilio Lahr-Vivaz
<elahrvi...@ccri.com <mailto:elahrvi...@ccri.com>> wrote:
Actually the GeoJSONWriter looks like it would work
perfectly. Our workflow is: start writing the export (i.e.
write the type 'FeatureCollection' and start the 'features'
array); write 0-n features as they come back from various
asynchronous queries; finish writing the export (i.e. write
the closing array bracket and close the FeatureCollection
element). The old gt-geojson module didn't support this pattern.
Thanks,
Emilio
On 3/18/20 9:10 AM, Ian Turton wrote:
I'm not quite sure what the use case for that would be, but
if you would like to propose modifications to GeoJSONWriter
in gt-geojsondatastore I'm happy to consider them.
Ian
On Wed, 18 Mar 2020 at 13:06, Emilio Lahr-Vivaz
<elahrvi...@ccri.com <mailto:elahrvi...@ccri.com>> wrote:
If that module is unsupported, are there any supported
methods for writing a feature as geojson? For our use
case, we need to write each feature individually, and
not as a feature collection.
Thanks,
Emilio
On 3/18/20 4:00 AM, Andrea Aime wrote:
On Wed, Mar 18, 2020 at 12:03 AM Jody Garnett
<jody.garn...@gmail.com
<mailto:jody.garn...@gmail.com>> wrote:
Since this is an unsupported module should we just
break the existing API contract in order to be
clear about expectations?
Jody, since this is a unsupported module a quick band
aid should do no?
Also consider the module is in bad shape, and Ian has
expressed a desire to level it down to the ground
and replace it with a jackson based machery coming from
the geojsonstore module.
Since it seems like a goner anyways, clean API should
likely be the last of our concerns?
Cheers
Andrea
==
GeoServer Professional Services from the experts! Visit
http://goo.gl/it488V for more information. == Ing.
Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S.
Via di Montramito 3/A 55054 Massarosa (LU) phone: +39
0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
/Con riferimento alla normativa sul trattamento dei
dati personali (Reg. UE 2016/679 - Regolamento generale
sulla protezione dei dati “GDPR”), si precisa che ogni
circostanza inerente alla presente email (il suo
contenuto, gli eventuali allegati, etc.) è un dato la
cui conoscenza è riservata al/i solo/i destinatario/i
indicati dallo scrivente. Se il messaggio Le è giunto
per errore, è tenuta/o a cancellarlo, ogni altra
operazione è illecita. Le sarei comunque grato se
potesse darmene notizia. This email is intended only
for the person or entity to which it is addressed and
may contain information that is privileged,
confidential or otherwise protected from disclosure. We
remind that - as provided by European Regulation
2016/679 “GDPR” - copying, dissemination or use of this
e-mail or the information herein by anyone other than
the intended recipient is prohibited. If you have
received this email by mistake, please notify us
immediately by telephone or e-mail./
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
--
Ian Turton
--
Ian Turton
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
<mailto:GeoTools-Devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/geotools-devel
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
_______________________________________________
GeoTools-Devel mailing list
GeoTools-Devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
