Sure you can!
Il 02/Ott/2016 06:34, "manf...@egger-gis.at" <manf...@egger-gis.at> ha
scritto:
> Thank you for your detailed description.
>
> Can i send this description to osgeo discuss list (spatialrefrence)?
>
> We talked there about this in september:
>
> https://lists.osgeo.org/pipermail/spatialreference.
> org/2016-September/thread.html
>
> Nobody mentioned your idea...
>
> Best regards,
>
> Manfred
>
> -----Original Message-----
> From: "Giuseppe Aruta" <giuseppe.ar...@gmail.com>
> Sent: Saturday, October 1, 2016 12:04pm
> To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net>
> Subject: Re: [JPP-Devel] Add SRID and units to Task
>
> ------------------------------------------------------------
> ------------------
> 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@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.mich...@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, manf...@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.mich...@orange.fr>
> > > Sent: Thursday, August 4, 2016 5:32pm
> > > To: jump-pilot-devel@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.sol...@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@lists.sourceforge.net
> > >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > >>
> > >> ------------------------------------------------------------
> > ------------------
> > >> _______________________________________________
> > >> Jump-pilot-devel mailing list
> > >> Jump-pilot-devel@lists.sourceforge.net
> > >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > >>
> > >
> > > ------------------------------------------------------------
> > ------------------
> > > _______________________________________________
> > > Jump-pilot-devel mailing list
> > > Jump-pilot-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> > >
> > >
> > >
> > >
> > > ------------------------------------------------------------
> > ------------------
> > > _______________________________________________
> > > Jump-pilot-devel mailing list
> > > Jump-pilot-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
> >
> > ------------------------------------------------------------
> > ------------------
> > _______________________________________________
> > Jump-pilot-devel mailing list
> > Jump-pilot-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
> >
>
>
>
>
> ------------------------------------------------------------
> ------------------
> 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@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
>
------------------------------------------------------------------------------
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@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
