From: Jim H. <jh...@cc...> - 2020-03-20 20:54:11
|
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 <ela...@cc... > <mailto:ela...@cc...>> 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 >> <ela...@cc... <mailto:ela...@cc...>> 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 >>> <ela...@cc... <mailto:ela...@cc...>> 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 >>>> <jod...@gm... >>>> <mailto:jod...@gm...>> 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 >>>> Geo...@li... <mailto:Geo...@li...> >>>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> _______________________________________________ >>> GeoTools-Devel mailing list >>> Geo...@li... >>> <mailto:Geo...@li...> >>> https://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> >>> -- >>> Ian Turton >> >> >> >> -- >> Ian Turton > > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > <mailto:Geo...@li...> > https://lists.sourceforge.net/lists/listinfo/geotools-devel > > > > _______________________________________________ > GeoTools-Devel mailing list > Geo...@li... > https://lists.sourceforge.net/lists/listinfo/geotools-devel |