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
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 wrote:
> Hi Ian,
>
> Do you mean using the Geo
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 di
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 wrote:
> Actually the GeoJSONWriter looks like it would work perfect
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 cl
Yes, that is correct.
Ian
On Wed, 18 Mar 2020 at 13:13, Andrea Aime
wrote:
> On Wed, Mar 18, 2020 at 2:12 PM 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
On Wed, Mar 18, 2020 at 2:12 PM 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.
>
Just to match my previous answer and clarify... gt-geojsondatastore
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 wrote:
> If that module is unsupported, are there any supported methods
On Wed, Mar 18, 2020 at 2:07 PM Emilio Lahr-Vivaz
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.
>
None I'm afraid. GeoServer writes JSON
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 <
On Wed, Mar 18, 2020 at 12:03 AM Jody Garnett
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,
Yeah that is a lot of hard work from Andrea (the checks benefit from lots
of QA checks being performed).
Can you just make a new method?
/**
*
* @param output output stream to be used for feature content
* @param autoclose close writer after use
* @return a writer
*/
public static Write
Hi Jody,
This is more or less the approach that I described above. Since I was
encouraged to toss up a PR for that approach, I put one together. (By
the way, it was a good exercise. I really like the checkboxes and the
new improvements to the CI hooks! Those were awesome. I missed the
fo
I am not quite sure what I am seeing in this PR.
I was going to ask you to add a note to the javadoc explaining the API
contract (ie that we trust users to close the provided writer). But then I
got confused, if I am reading the code correctly, the other writers
returned (for example BufferedWrite
Hi all,
Here's a PR for the discussed approach:
https://github.com/geotools/geotools/pull/2839
I'm not wild about it, but it does fix the 'regression' / change I saw.
I think the idea of the method GeoJSONUtil.toWriter(Object output) is a
bit too broad, and that means that any solution whic
On Thu, Mar 12, 2020 at 10:11 PM Jim Hughes wrote:
> Hi Andrea,
>
> Ah! The context that some of the Objects need closing and others do not
> helps clarify things.
>
> I just wrote a client side version of such a wrapper to see if it'd work
> (it does). Sounds like an amendment to 'toWriter' to
Hi Andrea,
Ah! The context that some of the Objects need closing and others do not
helps clarify things.
I just wrote a client side version of such a wrapper to see if it'd work
(it does). Sounds like an amendment to 'toWriter' to have a no-op-close
wrapper around the 1) BufferedWriter, 2)
I'm hitting issues with the looking up EPSG codes in with
FilterFactory(2).bbox. E.g. things like
ff.bbox("geom",49.0,79.0,51.0,80.0,"EPSG:4326")
Are throwing errors like:
java.lang.RuntimeException: Failed to setup bbox SRS
Caused by: org.opengis.referencing.FactoryException: Type "EPSG" is
Hi,
the API is problematic because it happens to create a Writer out of Object,
using this method:
https://github.com/geotools/geotools/blob/master/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java#L117
Some of the "things" passed in need closing (the FileWriter creat
On Thu, Mar 12, 2020 at 7:51 PM Jim Hughes wrote:
> Hi all,
>
> As a happy coincidence, I was able to test the GeoTools RC with GeoMesa.
> I did hit an issue or two.
>
Hum... or two? What's the second?
Cheers
Andrea
==
GeoServer Professional Services from the experts! Visit http://goo.gl/it48
From API point-of-view, that makes sense. From a code point-of-view,
there's a writer created on line 274:
https://github.com/geotools/geotools/blob/master/modules/unsupported/geojson/src/main/java/org/geotools/geojson/GeoJSONUtil.java#L274-L278...
that writer isn't returned, so as-is, the code
Good timing on testing, it seems rough closing the writer after one
feature? I would update the javadoc to be clear about the API contract and
leave the writer open.
On Thu, Mar 12, 2020 at 11:50 AM Jim Hughes wrote:
> Hi all,
>
> As a happy coincidence, I was able to test the GeoTools RC with G
Hi all,
As a happy coincidence, I was able to test the GeoTools RC with
GeoMesa. I did hit an issue or two.
The first one is that GeoMesa uses GeoTools library code to write out
GeoJson. Calls to FeatureJSON.writeFeature(SimpleFeature feature,
Object output) use GeoJSONUtil.encode(String,
23-RC is deployed and on SF, will work on blog post while waiting for
future builds.
--
Jody Garnett
On Wed, 11 Mar 2020 at 07:25, Jody Garnett wrote:
> Thanks for letting me know, speed seems good from this end. Thanks for
> building from the tag, that may have to do for timezone testing.
> I
Thanks for letting me know, speed seems good from this end. Thanks for
building from the tag, that may have to do for timezone testing.
I will start geowebcache release cycle at end-of-day.
--
Jody Garnett
On Wed, 11 Mar 2020 at 02:17, Andrea Aime
wrote:
> Hi Jody,
> I'm having trouble connecti
Hi Jody,
I'm having trouble connecting to anything that's in the US, getting to the
build server is very slow,
downloading the package times out instead.
I've tried building out of github checkouts (that one works) but it still
gets stuck trying to download
from the boundless repository...
Will tr
Some notes from testing the project download:
1) README.md links
- broken link to
https://docs.geotools.org/stable/developer/procedures/contribute.html
- broken link to:
https://docs.geotools.org/stable/developer/procedures/pull_requests.html
2) VERSION.txt
Does not have the correct substitution
JDBC stores I think. This certainly sounds familiar
Ian
On Tue, 10 Mar 2020 at 10:05, Andrea Aime
wrote:
> Btw, I think Ian at one point worked on a setting on whether to prefer
> local time zone vs GMT... but I don't
> quite remember what it is supposed to affect... GML encoders? Converters?
>
Hi all,
thx for the release Jody, got a green build here:
[INFO] Reactor Summary for GeoTools 23-RC:
[INFO]
[INFO] GeoTools ... SUCCESS
[ 0.768 s]
[INFO] Build tools for Geotools 2 . SUCCESS
[ 0.044 s]
[INFO] Maven plugins for Geoto
Btw, I think Ian at one point worked on a setting on whether to prefer
local time zone vs GMT... but I don't
quite remember what it is supposed to affect... GML encoders? Converters?
Data stores?
Cheers
Andrea
On Tue, Mar 10, 2020 at 10:48 AM Andrea Aime
wrote:
> Hi Jody,
> tried with a local
Hi Jody,
tried with a local build with no remote repo, the GeoPackage tests fail,
seems a timezone issue
---
Test set: org.geotools.geopkg.GeoPkgDatetimeTest
31 matches
Mail list logo
