[Geotools-devel] Reminder: GeoTools / GeoServer Meeting at 19:30 UTC on Tuesday
GeoTools / GeoServer committee meeting on Skype at 19:30 UTC on Tuesday: http://www.timeanddate.com/worldclock/fixedtime.html?msg=GeoTools+%2F+GeoServer+Meetingyear=2015month=6day=9hour=19min=30sec=0ah=1 -- Ben Caradoc-Davies b...@transient.nz Director Transient Software Limited http://transient.nz/ New Zealand -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
[Geotools-devel] [JIRA] (GEOT-5143) GeoJSON parsing error with large numbers
Title: Message Title
Chris Erickson created an issue
GeoTools / GEOT-5143
GeoJSON parsing error with large numbers
Issue Type:
Bug
Affects Versions:
13-beta
Assignee:
Unassigned
Created:
08/Jun/15 10:07 PM
Priority:
Medium
Reporter:
Chris Erickson
We have a site which is receiving customer-submitted data.
In one case, a submitted feature has a z-value of -27449444222548394000, which is obviously bogus.
Regardless, GeoTools crashes when trying to parse it:
Line | Method
- 65 | forInputString in java.lang.NumberFormatException
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
|444 | parseLong in java.lang.Long
|540 | valueOf . . . in ''
|236 | parse in org.geotools.geojson.GeoJSONUtil
|655 | parse . . . . in org.geotools.geojson.geom.GeometryJSON
|196 | read in ''
An example for the failing geoJSON is:
{type:LineString,coordinates:[[-82.14000994324927,38.1423427727003,-5.884389895313654e-49],[-82.13694429588939,38.13721961023166,-27449444222548394000]]}
[Geotools-devel] ContentFeatureSource final methods
Hi all, Firstly, I just want to say that I really like GeoTools/GeoServer. The extensibility is fantastic, and it's pretty fun to develop against. I'm working on a geotools datastore implementation for a project. I've heeded the GT recommendation of using ContentDataStore, since AbstractDataStore has been deprecated. I'm running into an issue though. I'm injecting query hints in a GSProcess via invertQuery(...) in order to communicate to my datastore that I want to do a rendering transformation, and I'm trying to offload the heavy lifting for this transform to an external system. I've seen a similar technique used in other projects. I've found that invertQuery is getting a Query.ALL as the targetQuery, regardless of what I pass in a CQL statement/bounding box. This comes from RenderedImageMapOutputFormat, which kicks off the transform with the following call: Object result = helper.applyRenderingTransformation(transformation, layer.getFeatureSource(), layer.getQuery(), Query.ALL, readGG, coverageCRS, interpolationHints); Since I can't add Hints to a Query.ALL, I'm wrapping it in a new Query for now as a workaround. I'm wondering if I'm doing something wrong to get to this point though, since I know that Hints are being added in this method in other systems. Is this expected behavior? If so, is there a more elegant way to do this kind of thing? My second issue is coming from ContentDataStore. The SimpleFeatureCollection is gotten by calling ContentFeatureSource.getFeatures(query). This method is final in ContentFeatureSource. It creates a ContentFeatureCollection, which derives the feature type from the feature source. From what I can tell, this makes it impossible to return a collection with a different feature type than the ContentFeatureSource normally builds by default. Any thoughts on this? Again, if there is a cleaner way to handle all of this, or if it sounds like I'm misusing the API, please let me know.If not, I'd like to propose that ContentFeatureSource.getFeatures(query) have the final keyword removed, which would allow me to return a subclass of ContentFeatureCollection that derives its feature type from the Query dependent FeatureReader as opposed to the type dependent ContentFeatureSource. Thanks for your time! -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
Re: [Geotools-devel] Envelope conversion loses emptyness
I like the 2nd option you propose. We have an API challenge with ReferencedEnevelope in that calling new ReferencedEnvelope is *never* the correct course of action (since depending on the CRS we may need to create a ReferencedEnvelope or ReferencedEnvelope3D. We have a factory method ReferencedEnvelope.create( .. ) that should be used. This would also be an appropriate location to detect an empty bounds and respond accordingly. -- Jody Garnett On 8 June 2015 at 02:30, Peilke, Hendrik hendrik.pei...@ibykus.de wrote: Hi, while writing some tests for the handling of empty imagemosaics, I noticed the following: If new ReferencedEnvelope(GeneralEnvelope ...) gets called and the GeneralEnvelope is empty (maxx minx or mmaxy miny), the resulting ReferencedEnvelope is not. Investigating further shows, that the constructor delegates to its superclass constuctor Envelope(minx,maxx,miny,maxy) inside JTS which then uses the method init(minx,maxx,miny,maxy). This method switches minx and maxx, if minx is greater than maxx and same with miny and maxy (by the way also the setBounds method calls this init method). So if the GeneralEnvelope was empty, the resulting ReferencedEnvelope is not. It seems odd, that JTS does this switching here, but they probably have not thought that anybody would like to construct an empy ReferencedEnvelope by any other statement than new ReferencedEnvelope(). Imho this behavior is unwanted and can be solved by either - changing JTS, which will cause a lot of code to fail and probably somebody had something in mind when switching coordinates (if not, then this should be the right place - all users and code should be able to provide correct order (as in clockwise or counterclockwise coordinates for Polygons and their holes)) - care for the special case of empty Envelopes in the ReferencedEnvelope class (and maybe also for empty bounding boxes and Rectangle2Ds?), but this would also leave out the robust coordinate switching of JTS and the question is if this is really the right place (seems only if JTS would not change and then what other Envelopes does GeoTools implement?) - care for the special case in the code where needed. This seems wrong to me, but is the only possibility, if the base is to be left as is Are there any other possibilities? Or did this problem occur already (maybe with an empty bounding box)? Did I miss something, which lead to total misunderstanding? If not, what suggestion would be the most preferable? Regards, Hendrik Peilke -- IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel -- ___ 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
[Geotools-devel] [JIRA] (GEOT-5142) Shapefile datastore support for removeSchema
Title: Message Title Morten Buhr created an issue GeoTools / GEOT-5142 Shapefile datastore support for removeSchema Issue Type: Improvement Assignee: Unassigned Components: data Created: 08/Jun/15 10:46 AM Priority: Medium Reporter: Morten Buhr The missing implementation of removeSchema prevents GeoServer to make a proper cleanup of an ImageMosaic coverage data store (using the purge=all parameter on the REST call for removing a coverage store) in the case where a shapefile is used as datastore for indexing the image mosaic. Especially the .properties file is not removed, which prevents re-uploading the ImageMosiac data store to the GeoServer using the same same storage name and the same image data. Add Comment
[Geotools-devel] Envelope conversion loses emptyness
Hi, while writing some tests for the handling of empty imagemosaics, I noticed the following: If new ReferencedEnvelope(GeneralEnvelope ...) gets called and the GeneralEnvelope is empty (maxx minx or mmaxy miny), the resulting ReferencedEnvelope is not. Investigating further shows, that the constructor delegates to its superclass constuctor Envelope(minx,maxx,miny,maxy) inside JTS which then uses the method init(minx,maxx,miny,maxy). This method switches minx and maxx, if minx is greater than maxx and same with miny and maxy (by the way also the setBounds method calls this init method). So if the GeneralEnvelope was empty, the resulting ReferencedEnvelope is not. It seems odd, that JTS does this switching here, but they probably have not thought that anybody would like to construct an empy ReferencedEnvelope by any other statement than new ReferencedEnvelope(). Imho this behavior is unwanted and can be solved by either - changing JTS, which will cause a lot of code to fail and probably somebody had something in mind when switching coordinates (if not, then this should be the right place - all users and code should be able to provide correct order (as in clockwise or counterclockwise coordinates for Polygons and their holes)) - care for the special case of empty Envelopes in the ReferencedEnvelope class (and maybe also for empty bounding boxes and Rectangle2Ds?), but this would also leave out the robust coordinate switching of JTS and the question is if this is really the right place (seems only if JTS would not change and then what other Envelopes does GeoTools implement?) - care for the special case in the code where needed. This seems wrong to me, but is the only possibility, if the base is to be left as is Are there any other possibilities? Or did this problem occur already (maybe with an empty bounding box)? Did I miss something, which lead to total misunderstanding? If not, what suggestion would be the most preferable? Regards, Hendrik Peilke IBYKUS AG für Informationstechnologie, Erfurt / HRB 108616 - D-Jena / Vorstand: Helmut C. Henkel, Dr. Lutz Richter Vorsitzender des Aufsichtsrates: Dr. Wolfgang Habel -- ___ GeoTools-Devel mailing list GeoTools-Devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
