[gdal-dev] Achieving Better WKT -> EPSG Code Autodetection When Importing Layers to Postgis
Andrew Joseph
ap.joseph at live.com
Sat Sep 23 10:41:54 PDT 2017
Even:
> No need for a complicated thing like a JNI bridge, but someone has to
code it in GDAL. All the basic functionnality is there. Just needs to be
put together.
The main reason I suggested geotools is that one only needs to write only a
few trivial lines of code to get the correct EPSG identifier for a given
WKT string -so in theory, most of the work would be the JNI bindings
themselves. I provided a working sample below that would autodetect the
example SRID correctly as 2277. The only downside I have encountered so far
is the slow search speed -but that could be mitigated by caching strings
that have already been mapped. I wonder if there is a repository somewhere
that has a large number of arbitrary WKT strings from "the wild" mapped to
the correct EPSG code -would be useful for getting at least a rough sense
of accuracy for any given wkt -> epsg conversion solution.
Andrea:
> prj2epsg.org uses that (a much older version of it actually) along with
pure and simple full text search matches.
I was actually the person who asked them to put up that repo up on github
because I initially wanted to try their codebase for wkt -> epsg
conversion, thinking that it would be superior (and faster) than raw
geotools -but was astounded when I saw the wrong projection come back for
the WKT string. It might be worth submitting a pull request with updated
dependencies -since prj2epsg is typically referenced in various open source
GIS documentation and on gis.stackexchange as the simplest way to upload a
.prj file and get back the correct EPSG code.
import org.geotools.factory.Hints;
import org.geotools.referencing.CRS;
import org.opengis.referencing.FactoryException;
public class BasicWktParser {
static {
System.setProperty("org.geotools.referencing.forceXY", "true");
Hints.putSystemDefault(Hints.FORCE_AXIS_ORDER_HONORING, "http");
Hints.putSystemDefault(Hints.COMPARISON_TOLERANCE, 1e-9);
}
public static void main(String[] args) throws FactoryException {
String identifier = CRS.lookupIdentifier(CRS.parseWKT(args[0]), true);
System.out.println(identifier);
}
}
relevant build.gradle declarations:
dependencies {
compile (group: 'org.geotools', name: 'gt-epsg-hsql', version: '17.2') {
exclude module: 'jai_core'
}
compile (group: 'org.geotools', name: 'gt-epsg-extension', version:
'17.2') {
exclude module: 'jai_core'
}
}
repositories {
mavenCentral()
maven {
url "http://repo.boundlessgeo.com/main/"
}
maven {
url "http://download.osgeo.org/webdav/geotools/"
}
}
On Sat, Sep 23, 2017 at 8:00 AM, Andrea Aime <andrea.aime at geo-solutions.it>
wrote:
> Hi Even,
> just a quick note about GeoTools and http://prj2epsg.org
>
> In terms of matching via GeoTools, we have spent quite some time building
> tables of aliases and
> some lax equivalence rules, think DMS is same a deegree, some tolerance on
> the parameter
> values, and so on.
>
> prj2epsg.org uses that (a much older version of it actually) along with
> pure and simple full text search matches.
>
> It basically extracts a set of keywords from the WKT and searches against
> a similar database
> built by indexing all of the EPSG database contents. This is actually what
> happens when you put
> in that prj file, the result you're pointing to is the 3rd match.
> If you input instead something that is actually equivalent, then you'll
> get a single result.
>
> Looks like Boundless made the old code for the site publicly available on
> github really recently:
> https://github.com/boundlessgeo/prj2epsg
> Still using a GeoTools 2.6.6, oh dear! :-)
>
> Cheers
> Andrea
>
>
> On Sat, Sep 23, 2017 at 11:19 AM, Even Rouault <even.rouault at spatialys.com
> > wrote:
>
>> > I've had this issue for years, but concede I might be missing
>> something. Is
>>
>> > there anything that can remedy this issue utilizing existing
>> functionality?
>>
>>
>>
>> No need for a complicated thing like a JNI bridge, but someone has to
>> code it in GDAL. All the basic functionnality is there. Just needs to be
>> put together. A basic approach would be to iterate over the EPSG codes from
>> the gcs.csv and pcs.csv files, use importFromEPSG() and compare the
>> resulting WKT with the user WKT. Some fuzzing would be needed to be robust
>> to slight naming variations, etc. This was actually an idea for a GSoc
>> project, but anyone is free to pick it up and bring his/her contribution.
>>
>>
>>
>> In the .prj you pointed, prj2epsg first suggestion, EPSG:32139, is
>> actually completely inappropriate given it uses meter as linear unit,
>> whereas the .prj uses foot_us. EPSG:2277 looks to be the exact match. And
>> another interesting thing is that the .prj has Standard_Parallel_1 =
>> 30.11666666666667 and Standard_Parallel_2 = 31.88333333333333. Whereas
>> EPSG:2277 has them in the reverse order. Which is equivalent
>> mathematically, but a matcher should be aware of that equivalence. So not
>> completely a trivial task.
>>
>>
>>
>> Even
>>
>>
>>
>> --
>>
>> Spatialys - Geospatial professional services
>>
>> http://www.spatialys.com
>>
>> _______________________________________________
>> gdal-dev mailing list
>> gdal-dev at lists.osgeo.org
>> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>>
>
>
>
> --
>
> Regards,
>
> Andrea Aime
>
> ==
> 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
> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D+55054+%C2%A0Massarosa&entry=gmail&source=g>
> 55054
> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D+55054+%C2%A0Massarosa&entry=gmail&source=g>
> Massarosa
> <https://maps.google.com/?q=Via+di+Montramito+3/A+%0D+55054+%C2%A0Massarosa&entry=gmail&source=g>
> (LU)
> phone: +39 0584 962313 <+39%200584%20962313>
> fax: +39 0584 1660272 <+39%200584%20166%200272>
> mob: +39 339 8844549 <+39%20339%20884%204549>
>
> 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.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20170923/b2722032/attachment.html>
More information about the gdal-dev
mailing list