I am excited about this work, thanks for the heads up in the meeting last week.
Is it worth having this in the SRS Demo page (as an wkt2epsg replacement). -- Jody Garnett On 19 November 2016 at 05:36, Andrea Aime <andrea.a...@geo-solutions.it> wrote: > Hi, > during the last two weekends I worked a bit on a long standing pet peeve > of mine... the inability > to determine a EPSG code from a shapefile in the GeoServer UI, while > configuring a new shapefile. > > Yes, one normally works with a limited number of CRSs, and yes, one can go > and use prj2epsg,.org but > in fact, up to GeoServer 1.7 doing the identification from the UI was > actually possible, using a dedicated > button that initiated the long "scan all possible CRSs and compare them > one by one approach". > > Unfortunately some found it counter-intuitive or strange, and requested > that button to be removed in 2.0 > > Before just going and adding it back, I looked at how the "fast" lookup is > performed today and found ways to > improve it. I have been testing against a collection of 4000+ unique wkt > files from ESRI software and > run a quick tool that tried to fast lookup all of them... matching none! > Here are the result: > > SUCCESS: 0 > LOOKUP_FAILED: 3198 > NOT_IN_DATABASE: 1152 > AXIS_DIRECTION: 20 > EXCEPTION: 125 > Total: 4495 > > Legend: > > - SUCCESS: fast lookup matched an actual EPSG code > - LOOKUP_FAILED: no match found with fast lookup, even if one is > available in the EPSG database > - NOT_IN_DATABASE: the CRS has no match in the EPSG database > - AXIS_DIRECTION: the CRS exists in the EPSG database, but with axis > directions that cannot be expressed in WTK (e.g. south along 60° east) > - EXCEPTION: the WKT failed to parse to start with, normally because > the projection is not known (most common missing projection is Cassini) > > The fast lookup currently uses only the code (which the WKTs lack) and the > CRS name (which is not a match for any entry in the EPSG database). > Now, the EPSG factory actually had ways to make a few quick queries in the > DB to search for a match, but > used them only in the full lookup code path, and if they also failed, then > it actually scanned everything... this did not make much sense. > > So I've moved the queries in the fast lookup path, making sure that they > were actually fast (< 100ms per lookup, often < 20ms), > made several adjustments to the code in order to better handle parameter > lookup tolerance, axis order issues, uom variants > in some params, DMS and degrees considered different when they are just > different formattings of the same unit, > and got with the following results after the changes [1]: > > SUCCESS: *3203* > LOOKUP_FAILED: *76* > NOT_IN_DATABASE: 1077 > AXIS_DIRECTION: 20 > EXCEPTION: 119 > Total: 4495 > Total time spent in lookups: 81398ms > Average time per entry: 18ms > > As you can see, the success rate went up dramatically, and the average > lookup time is quite small (this test benefits > of caching, so the actual first lookup takes longer). > > The residual failed lookups are due mostly to two causes: > > - ESRI using the same datum name for datums that are actually > different in the EPSG database (thus breaking the Geotools existing datum > name alias support) > - WKTs reporting a projection as a 2 standard parallel one, while the > EPSG database reports the same as a one standard parallel with scale > factor. At the end they are the same, but I did not invest time into > encoding that equality path (the changes were getting a bit too long to > code on and started to feel like actual work, so I stopped) > > I added tests for a number of sample cases, and had to fix a few tests > that were checking failing lookups that now do succeed. > Pull requests here: > https://github.com/geotools/geotools/pull/1394 > https://github.com/geoserver/geoserver/pull/1989 > > I intend to merge into master (after review, if anyone feels like looking > into it), not sure if and when to backport as this is a > spare time thing, so interactive testing has been limited. > > Cheers > Andrea > > [1]: you can see a decrease in the "not in database" numbers and > exceptions, that's mostly because of the DMS treatment > > -- > == > 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 > > *AVVERTENZE AI SENSI DEL D.Lgs. 196/2003* > > Le informazioni contenute in questo messaggio di posta elettronica e/o > nel/i file/s allegato/i sono da considerarsi strettamente riservate. Il > loro utilizzo è consentito esclusivamente al destinatario del messaggio, > per le finalità indicate nel messaggio stesso. Qualora riceviate questo > messaggio senza esserne il destinatario, Vi preghiamo cortesemente di > darcene notizia via e-mail e di procedere alla distruzione del messaggio > stesso, cancellandolo dal Vostro sistema. Conservare il messaggio stesso, > divulgarlo anche in parte, distribuirlo ad altri soggetti, copiarlo, od > utilizzarlo per finalità diverse, costituisce comportamento contrario ai > principi dettati dal D.Lgs. 196/2003. > > > > The information in this message and/or attachments, is intended solely for > the attention and use of the named addressee(s) and may be confidential or > proprietary in nature or covered by the provisions of privacy act > (Legislative Decree June, 30 2003, no.196 - Italy's New Data Protection > Code).Any use not in accord with its purpose, any disclosure, reproduction, > copying, distribution, or either dissemination, either whole or partial, is > strictly forbidden except previous formal approval of the named > addressee(s). If you are not the intended recipient, please contact > immediately the sender by telephone, fax or e-mail and delete the > information in this message that has been received in error. The sender > does not give any warranty or accept liability as the content, accuracy or > completeness of sent messages and accepts no responsibility for changes > made after they were sent or for other risks which arise as a result of > e-mail transmission, viruses, etc. > > ------------------------------------------------------- > > ------------------------------------------------------------ > ------------------ > > _______________________________________________ > 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
