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> 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> > 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> >> 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> >>> 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 >>> listGeoTools-Devel@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/geotools-devel >>> >>> >>> _______________________________________________ >>> GeoTools-Devel mailing list >>> 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 > 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
