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
