[sr.org] Discussion of open and authoritative projection databases

Mon Oct 3 20:41:09 PDT 2016

Good Morning!

I think we should add to the list of projection databases this open source project:

https://github.com/orbisgis/cts

I feel it is an open database in gitgut with a neutral approach. Look at the description of the OPEN JUMP developers below:

Best regards,

Manfred

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most 
engaging tech sites, SlashDot.org! http://sdm.link/slashdot_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel at lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
Hi Manfred,
I will give a brief description on how CRS information plugin works.

CRS info is based on the CRS list srid.txt, located into
org.openjump.core.ccordsys.utils folder. Plus some methods located into the
same folder (thanks to Michael that made this part more flexible and
intuitive)

The file srid.txt is a series of rows. Each row describes a projection with
only 3 parameters:
<SRID of projection>;<description of projection>;[Unit of  projection]
example:
<32632>;<WGS 84 UTM zone 32N>;[metre]
Note that <description of projection> uses a neutral description which is
neither OCG nor ESRI (see point c)
There are no other parameters for transformations as this plugin provides
only CRS information (and keep srid.txt file as small/simple as possible)

How it works:

a) Layer properties plugins read auxiliary files (.prj or .aux) or geotiff
tag to get a proj info:
Many methos are invoked depending on the type of the file and where this
info can be located. In this last case this plugin uses different
strategies depending also to the  auxiliary file.

b) at first stage, a method search the presence of a projection WKT and
reads the proj description (which is usually located between first double
quotes into the WKT code, after PROJC[ or GEOGC[ strings) (see
ProjUtils.decodeProjDescription).
Giving an example, the output  could be "WGS 84 / UTM zone 32N" (for OGC
wkt) or "WGS_1984_UTM_Zone_32N" (for ESRI wkt) - the method doesn't define
neither the WKID nor the authority, it only reads the proj code description

c) Afterwards, a second method convert that description in a neutral
"readable string".
 What is a readable string?  Exploring http://spatialreference.org, I found
that there are some semantic rules adopted by ESRI wkt  that can be
converted into OGC and viceversa. For instance ESRI separate words of proj
description using udescore "_" while OGC uses spaces or slashes"/".
Decoding those rules, it was easy to create a method that convert both OGC
and ESRI to a valid neutral text (see methos
ProjUtils.decodeProjDescription).
for instance,  both "WGS 84 / UTM zone 32N"  and  "WGS_1984_UTM_Zone_32N"
are converted to "WGS 84 UTM zone 32N".

d) a third method searches text "WGS 84 UTM zone 32N"on srid.txt.
It finds the row: <32632>;<WGS 84 UTM zone 32N>;[metre] and gives back WKID
32632

e) a forth simple method try to guess the authority from the WKID number
following these rules:
 1) WKID <32768 or >5999999  will result in an AUTHORITY name of "EPSG".
 2) A WKID in range between 33000 and 199999 will result in an AUTHORITY
name of "ESRI".
        // (
http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/whnjs.htm#SOAP_Geometry_FindSRByWKID.htm
)

f) the final output is the complete description ESRI:32632 - WGS 84 UTM
zone 32N - metre

g) if no string on srid.txt is found, the final output will be the complete
projection WKT string, so users can copy and try to use
http://prj2epsg.org/search service to find the real (almost) WKID

Nothe that the method d) doesn't cover all the possibilities (I found that
old qgis adopted different rules to describes projections).
In this case,
 ProjUtils.decodeProjDescription is build nin order to adopt new rules in
the future
OR
It is possible to add alias into srid.txt.
for instance:
<4326>;<WGS 84>;[degree]
<4326>;<GCS WGS 84>;[degree]

Best regards
Peppe

2016-09-29 22:45 GMT+02:00 Michaël Michaud <m.michael.michaud at orange.fr>:

> Hi Manfred,
>
> Just to make it clear. OpenJUMP uses two different pieces of codes to
> get the CRS from a datasource and to perform transformations.
>
> To get CRS information from datasource (either vector or raster), we use
> a small plugin based on a list of CRS prepared by Peppe and included in
> OpenJUMP CORE (maybe Peppe can tell more about it) :
> org.openjump.core.ccordsys.utils.srid.txt
>
> For coordinate transformation, OpenJUMP PLUS uses CTS
> (https://github.com/orbisgis/cts), which itself uses a snapshot of EPSG
> database for CRS definitions.
>
> For the sake of completeness, OpenJUMP also uses a list of EPSG codes in
> WMS plugin to know if the requested dataset must be interpreted in
> latlon or in lonlat order.
>
> None of these resources describes the area in which each CRS is valid.
>
> Michaël
>
>
>
> Le 29/09/2016 à 06:00, manfred at egger-gis.at a écrit :
> > Good morning!
> >
> > I published a first version of my tool including registered EPSG-Codes
> in geotools 2.6.0.  :
> >
> > http://www.egger-gis.at/shapefile-projectionfinder/
> >
> > Before i start to develop a OPEN JUMP PLUGIN i want to ask which
> databases OPEN JUMP uses for transformations?
> >
> > I the last weeks i saw in your email traffic that you included different
> sources of projection definitions (EPSG, ESRI, user defs, ...)?
> >
> > And is it possible to make different .prj files? You know ESRI can not
> read WKT by OGC...
> >
> > Best regards,
> >
> > Manfred Egger
> >
> > Alois-Schrott-Str. 34
> > 6020 Innsbruck
> > Austria
> >
> > Web: http://egger-gis.at
> >
> > -----Original Message-----
> > From: "Michaël Michaud" <m.michael.michaud at orange.fr>
> > Sent: Thursday, August 4, 2016 5:32pm
> > To: jump-pilot-devel at lists.sourceforge.net
> > Subject: Re: [JPP-Devel] Add SRID and units to Task
> >
> > Hi Peppe,
> >
> > Your explanation is clear.
> >
> > I tend to be on the same opinion as Jukka on this topic because I
> > generally use OpenJUMP as a toolbox, and I generally know exactly what I
> > want to do with my data.
> >
> > But I admit that to visualize heterogeneous data, OpenJUMP has not much
> > to offer to the user to solve projection problems, and the beginner can
> > be bothered by the lack of assistance.
> >
> > Here are a few recommandation :
> >
> > 1 - Projection issues may be tricky. It is magic as long as the only
> > need is visualization, but if the user need to reproject his dataset, he
> > must be aware of the consequences (reversibility, topology
> > consistency...). Last time I have been screwed by a projection problem
> > is with FME. I imported shapefiles with a prj in a project using the
> > "same" projection. It was supposed to be a no-op (doing nothing), except
> > that FME did a transformation from projection A (defined by prj
> > parameters) to projection A (defined by internal FME parameters), which
> > resulted in an invisible switch of  a few micrometers difficult to see,
> > but which broke the consistency with another layer (which did not follow
> > the same process). Of course this can be avoided in FME, but this is
> > just an example to illustrate that without a great care, something
> > supposed to be magic may become dramatic.
> >
> > 2 - From my point of view, one of the most difficult problem is to be
> > able to recognize that two coordinate reference system with different
> > origins (different registries, different formats, different libraries,
> > different definitions) represent the same thing (see the above problem
> > with FME). I think you already worked on that problem.
> >
> > 3 - Your mail explains quite clearly what already exists and where you
> > want to go. I think that to anticipate difficulties, we can suppose that
> > a SRID is associated to the task and try to define OpenJUMP behaviour in
> > different situations :
> > - default behaviour when creating a new task : asking for a srid or not
> > ? it is a good thing if OJ can infer information from prj files or other
> > sources, but I don't like having to answer esoteric questions before I
> > can start working.
> > - task without srid : does it take the srid of the first layer imported
> > ? What if layers without srid are already imported ?
> > - can we change the srid of a task if layers with srid are already
> > imported ?
> > - importing a layer with a different srid : 1) the layer is just tagged
> > (layer srid mismatch task srid), 2) the layer is automatically
> > reprojected by the renderer ? 3) the user is invited to reproject the
> > layer ? 4) There are some options to define OpenJUMP behaviour
> > - how to deal with layers without projection : can we import them in a
> > task with a srid ? can we edit them ? Do we set the task projection to
> > the layer projection automatically ?
> > - if a reprojected layer is not editable, an interesting option would be
> > to set the task srid to the selected layer srid (-> makes the selected
> > layer editable, and reproject other layers)
> > - etc.
> >
> > 4- Implementation : no real opinion. Ede's advice will certainly make
> > the code more flexible, but also a bit more complex. And how to
> > represent the coordinate system property ? Another difficult question.
> > We already have SRID represented by an int at the geometry level (JTS)
> > and a CoordinateSystem at the FeatureSchema level. IMHO, the first is a
> > bit too lightweight (cannot handle non EPSG crs). The second is too
> > lightweight if we want to use it to effectively transform coordinates
> > (cannot handle much transformations) and too heavyweight if we just use
> > it as a reference to be used by CTS library (or any other).
> >
> >
> > My 3 cents
> >
> > Michael
> >
> >
> >
> > Le 03/08/2016 à 15:13, Gmail a écrit :
> >> LoopThis thread needs a larger explanation.
> >> I try to simplify it.
> >> other GIS like Kosmo or GVSig implemented Coordinate system framework
> >> following these steps:
> >> a) first step they add a projection object to the task (usually as EPSG
> or
> >> ESRI code). In Kosmo user has to set that. QGIS also allows to set Task
> >> projection loading that from the first loadedf file (with SRID).
> >> b) QGIS define the Unit of the task from SRID ( ex. 4326>degree,
> >> 32632>metre) while GvSig And Kosmo require to set it manually.
> >> c) a projection object is set to each loaded layer. This is done reading
> >> layer metadata or manually
> >> d) if the task and the layer projection object are different a
> >> transformation should be set. Those software use ( for vector) proj4
> >> libraries. In this step Qgis and newer gvsig allows on fly reprojection.
> >> e) this transformation is taken into account only by layer renderes on
> the
> >> workbench. Which changes geometry before drawing it.
> >> This transformation is saved into project file and taken into account
> >> whenever the project file is loaded.
> >> f) Note that Kosmo (and probably Gvsig) doesn't allow any spatial
> operation
> >> on reprojected layers. The only way to modify them is to save them
> reprojected.
> >>
> >> Recently I did few modifications on shape file reading in order to
> expand
> >> capability to set layer SRId  when reading file. Layer properties
> plugins
> >> already have this capability for both raster and vector ( included
> >> geotif*). Together with database and wfs capability to record layer
> srid we
> >> probably get almost point C of my list.
> >>
> >> My idea is to work on point A and B, integrating parts if my measure
> plugin
> >> in to OJ core in order to have measurements\zoom when task projection is
> >> geographic or possibility that oj display meter or feet unit on
> >> measurements \ scale bar.
> >> The other points can be faced in the future, including in fly
> reprojection.
> >>
> >> My project:
> >> 1) Oj already as a srid registry embedded that I added when I defined
> srid
> >> detection capability from auxiliary files. It is a simple list of
> >> projection, a series of lines with only srid number and a proj.
> description
> >> ( ex <32632>;<WGS 84 UTM zone 32>), build using proj4 registries and
> excel.
> >> I could expand each line with unit ( ex <32632>;<WGS 84 UTM zone
> 32>;<metre>)
> >> 2) expand Task class with srid code and unit. User can define manually .
> >> 3) modify measure /zoom plugins according units, meter, foot, degree (
> in
> >> this last case I would limit only to wgs84 ) using classes fro my
> measure
> >> plugin.
> >>
> >> Peppe
> >>
> >>
> >>
> >>
> >>
> >> *
> >>
> >>
> >>
> >> Inviato con AquaMail per Android
> >> http://www.aqua-mail.com
> >>
> >>
> >> Il 03 agosto 2016 12:32:48 edgar.soldin at web.de ha scritto:
> >>
> >>> hey Peppe,
> >>>
> >>> On 03.08.2016 11:11, Giuseppe Aruta wrote:
> >>>> Hi all,
> >>>> The title explains what is my idea. In a possible future we can
> extend OJ
> >>>> projection capabilities.  And the 1st step I would explore is to add
> SRID
> >>>> code to a task (to centralize possible transformations)
> >>> can you elaborate?
> >>>
> >>>> and unit of measurements (retriving from SRID, which will affect other
> >>>> plugins/tools like measure tools, measure area/length, display scales
> etc,
> >>>> especially for Geographic coordinate systems).
> >>> same here.
> >>>
> >>>> I gave a look at Task class , should I implement (srid and unit) as
> >>>> properties into the associate xml file? Does it breaks compatibility?
> >>> ..ede
> >>>
> >>> ------------------------------------------------------------
> ------------------
> >>> _______________________________________________
> >>> Jump-pilot-devel mailing list
> >>> Jump-pilot-devel at lists.sourceforge.net
> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >> ------------------------------------------------------------
> ------------------
> >> _______________________________________________
> >> Jump-pilot-devel mailing list
> >> Jump-pilot-devel at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >>
> >
> > ------------------------------------------------------------
> ------------------
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> >
> >
> > ------------------------------------------------------------
> ------------------
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
>
> ------------------------------------------------------------
> ------------------
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>