... is someone of you a member of this mail list: disc...@lists.osgeo.org Last week we discussed a solution of a central web-database where all coordinate systems are registered. This database should be promoted by OSGeo.
Maybe i can send you the mail traffic? Best regards, Manfred -----Original Message----- From: "Michaël Michaud" <m.michael.mich...@orange.fr> Sent: Sunday, September 4, 2016 12:48pm To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net> Subject: Re: [JPP-Devel] Add SRID and units to Task ------------------------------------------------------------------------------ _______________________________________________ Jump-pilot-devel mailing list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel Hi Peppe, Thanks for your new explanations and references, For EPSG codes from 6,000,000 - 6,999,999 : I finally agree with you. These codes are deprecated but "remain in EPSG dataset". Michaël Le 04/09/2016 à 16:11, Giuseppe Aruta a écrit : > Hi Michaël > thanks for the explanation. It was a bit confusing (not only for me) > when studing this topic > -------------------------------- > EPS codes > > http://www.ihsenergy.com/epsg/geodetic2.html > reading this page it seems that EPSG code range are: > 0 - 32767 and 6,000,000 - 6,999,999 (since ver. 6.6) > > --------------------------------- > > regarding SRID vs CUSTOM, > > According to Wikipedia SRID "is a unique value used to unambiguously > identify projected, unprojected, and local spatial coordinate system > definitions" > https://en.wikipedia.org/wiki/Spatial_reference_system#Identifier > (In that case it seems to be the equivalent of ESRI WKID > (https://developers.arcgis.com/javascript/3/jsapi/spatialreference-amd.html). > > while > > CUSTOM, as I understood, is a local projection > (http://wiki.gis.com/wiki/index.php/Custom_projection). > ESRI defines CUSTOM codes (200000-209199) which are outside the > "official ones". > EPSG uses a different "authority acronym" SR-ORG to define them so > there are SR-ORG/ESRI overlaping codes. > Thi is a new proposal, that needs to be inspect, anyhow > > a) recognized as integer > UNKNOWN: -1, 0 : UNKNOWN > EPSG: 1-32766 [ or 1026-32766(**) ] and 5999999-2147483647 > ESRI: 33000-200000 : ESRI registry > FranceGéoportail: 310024802 to 310915814 - FranceGéoportail , not > recognized by EPSG, the info seems quite outdated > (http://www.wms.lautre.net/projgp.html) > > SRID: other (no intention to define whether the codes are defined by > users (CUSTOM) or not, no intention to define if it belongs to other > authority that EPSG/ESRI) > b) recognized as string > I would let it blank, even if we only have INGF codes. > > Peppe > > (*) according to this page (http://www.wms.lautre.net/projgp.html) > (**) http://www.ihsenergy.com/epsg/geodetic2.html > > 2016-09-04 12:54 GMT+02:00 Michaël Michaud > <m.michael.mich...@orange.fr <mailto:m.michael.mich...@orange.fr>>: > > Hi Peppe, > > Just wonder why you want to retrieve authorities from srid ? > If it is important, why not adding authority in the srid.txt file ? > It is quite impossible to get authority from code as codes are > supposed to be unique for a single authority only. > By chance, EPSG is so well-known that most implementions (ESRI, > GeoTIFF, PostGIS) take care to use the same code for the same CRS, > and add new CRS in a specific range of codes unused by EPSG. But > every implementor has its own rules, and what I've found is very > confusing. > > negative srid : unused, except -1 which used to mean UNKNOWN in > postgis 1.x > 0 : means UNKNOWN in GeoTIFF and PostGIS 2.x > 1-2000 : unused but valid EPSG codes for CRS > 2000-32766 : EPSG codes also used by ESRI (WKID), PostGIS, GeoTIFF > for the same CRSs... > In GeoTIFF, projected CRS codes seem to start at 20000, > but smaller EPSG codes exist in EPSG database > note : SR-ORG codes (1-9000) are overlapping EPSG code range > 32767 : user-defined in GeoTIFF implementation ( don't know what > is the difference between user-defined and private-user > implementation ?) > 32768-max : > GeoTIFF : 32768-65535 : private user implementation > ESRI : 32768 - 33000 : unused ? > ESRI : 33000-200000 : ESRI authority > ESRI : 200000-209199 : ESRI Custom codes > PostGIS : 32768 - 910000 : ? (can be used for ESRI WKID ?) > PostGIS : 910000 - 998999 : Custom codes > SpatialReference : EPSG:61000000-69000000 (superseded, not > referenced in EPSG database) > > GeoTIFF Projection and ProjCoordTrans are other types of beast. > They do not define a Coordinate Reference System. > > What I would keep : > -1, 0 : UNKNOWN > 1-32766 : EPSG registry > 33000-200000 : ESRI registry > other : CUSTOM/SRID > > Not sure why you distinguish SRID from CUSTOM. Have they different > meaning/usage ? > > Michaël > > > Le 03/09/2016 à 19:43, Giuseppe Aruta a écrit : >> Maybe I should correct on this way - to save compatibility with >> geotif >> >> Code : >> >> integer >> EPSG : [2000..32767] or [5999999..2147483647] >> ESRI : [32999..200000] >> GEOTIF PROJECTION: [1..28]* >> CUSTOM : [29..1999] or [32769..32999] or [200000..6999999] >> NOT DEFINED: [-1] >> USER DEFINED: [0] or [32768] >> >> not integer >> IGNF: >> >> * See >> http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/GeoTiff.html >> <http://www.sno.phy.queensu.ca/%7Ephil/exiftool/TagNames/GeoTiff.html>. >> The geotif method in Proj Utils class, in the GeoKeyDirectoryTag, >> scans geographic/geocentric projection if no projected value is >> recognized >> >> Peppe >> >> 2016-09-03 12:22 GMT+02:00 Giuseppe Aruta >> <giuseppe.ar...@gmail.com <mailto:giuseppe.ar...@gmail.com>>: >> >> I understand. I don't do any work today. And wait for your >> commits >> Peppe >> >> 2016-09-03 12:01 GMT+02:00 Michaël Michaud >> <m.michael.mich...@orange.fr >> <mailto:m.michael.mich...@orange.fr>>: >> >> Hi Peppe, >> >> If you're not changing ProjUtils class today, I'll make >> some refactoring. >> Would be nice if you can double check after my commit. >> >> About test on srid integer, there is not much of a >> problem. Just a small inconsistency betwwen comment and >> code on CUSTOM authority >> >> Comment : >> CUSTOM : [200000..209199] >> >> Code : >> EPSG : ]-∞..32768[ or ]5999999..2147483647] >> ESRI : ]32999..200000[ >> CUSTOM : [32768..32999] or [200000..5999999] >> >> Michaël >> >> >> Le 02/09/2016 à 16:00, Giuseppe Aruta a écrit : >>> Hi Michaël, >>> thanks for the suggestions. >>> >>> >srid.txt encoding >>> I upgraded SVN repository with a UTF-8 version. >>> >>> >I noticed that tests done on the srid integer value are >>> not consistent between the comments and the code. >>> Sorry. I am still not familiar with some developing >>> terminology (and the usage of Java). >>> Does it means I should remove those comments from that >>> position? >>> >>> >ProjUtils is a very big class and contains redundant code >>> Yes. During the long syage of thge class I added many >>> extra code. Right now I realized that >>> readSRSFromAuxiliaryFile_1 method was not used (and I >>> removed from repository). I will use your suggestions >>> and make it simpler and smaller, following OJ philosophy. >>> >>> Thanks again >>> >>> Peppe >>> >>> 2016-09-02 0:05 GMT+02:00 Michaël Michaud >>> <m.michael.mich...@orange.fr >>> <mailto:m.michael.mich...@orange.fr>>: >>> >>> Hi Peppe, >>> >>> Thanks for the work. Here are some suggestions. >>> >>> I noticed that tests done on the srid integer value >>> are not consistent between the comments (and the >>> referenced site >>> >>> http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/whnjs.htm#SOAP_Geometry_FindSRByWKID.htm >>> >>> <http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/whnjs.htm#SOAP_Geometry_FindSRByWKID.htm>) >>> and the code. >>> >>> Also I think there is a problem with srid.txt >>> encoding (with the addition of IGNF registry which >>> includes non ASCII characters). I suggest that we >>> code the file in UTF-8 (it is currently recognized >>> as ISO 8859-1 by my IDE) and read it as UTF-8 so >>> that it behaves similarly on windows or linux (using >>> *InputStreamReader >>> >>> <http://docs.oracle.com/javase/8/docs/api/java/io/InputStreamReader.html#InputStreamReader-java.io.InputStream-java.lang.String->**(**InputStream >>> >>> <http://docs.oracle.com/javase/8/docs/api/java/io/InputStream.html>**in,**String >>> >>> <http://docs.oracle.com/javase/8/docs/api/java/lang/String.html>** >>> charset*Name)) >>> >>> ProjUtils is a very big class and contains redundant >>> code. Maybe a few helper methods would help >>> - getSRSDef(int srid) // to get SRSDef from SRID >>> (computed 3 times in the file) >>> - normalizeSRSName(String srs) // to normalize >>> SRSName writing (whitespaces, separators...) >>> - getSRSDef(String prjName) // read from srid.txt >>> ... >>> >>> In readSRSFromAuxiliaryFile_1 and >>> readSRSFromAuxiliaryFile methods, tests could be >>> organized this way >>> >>> projectSourceFilePrj >>> projectSourceRFilePrj // not used in >>> readSRSFromAuxiliaryFile_1 >>> projectSourceRFileAux >>> >>> // List<String> fileList : useless ! >>> >>> if (projectSourceFilePrj.exists()) {/**/} >>> else if (projectSourceRFilePrj .exists()) {/**/} >>> else if (projectSourceRFileAux.exists()) {/**/} >>> else >>> >>> // if (!prjname.isEmpty()) {/* */} : no more needed >>> if you wrote a getSRSDef(String prjName) method >>> >>> Michaël >>> >>> >>> Le 01/09/2016 à 07:23, Giuseppe Aruta a écrit : >>>> Hi all, >>>> sorry for the long time I took to answer. >>>> I understood the difficulties. My idea was limited >>>> to work on the measurement part of Coordinate >>>> systems (something that I started to do on my >>>> Measurement plugin). The reprojection part was put >>>> aside. >>>> After reading the opinions of all, I decided to >>>> abandon the idea to a add projection ID to the Task >>>> and to limit the work in small steps only at layer >>>> level, without core modifications. >>>> I added to projection detection of layers >>>> (LayerProperty and RasterLayerProperty plugins) the >>>> capability to show the relative measure unit. >>>> It was easy as it required only some extra info on >>>> the SRID registry file >>>> (org.openjump.core.ccordsys.utils.srid.txt) >>>> In the future I will work on modified (measurement, >>>> zoom, scale) plugin that detect that measure unit , >>>> Measure Plugin will remain the main place for this >>>> work. >>>> Best regards >>>> Peppe >>>> >>>> @Michael I added on SRID registry file also IGNF >>>> and IGN Gèoportail codes, trying to set the most >>>> possible common "synonimous". But I didn't test it >>>> as I didn't find datas on that Authority. Could you >>>> give a quick look, please. I took the informaion >>>> ffor IGN Gèoportail form this page >>>> (http://www.wms.lautre.net/projgp.html >>>> <http://www.wms.lautre.net/projgp.html> - 2011) >>>> >>>> 2016-08-04 23:32 GMT+02:00 Michaël Michaud >>>> <m.michael.mich...@orange.fr >>>> <mailto:m.michael.mich...@orange.fr>>: >>>> >>>> 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 >>>> <mailto:edgar.sol...@web.de> ha scritto: >>>> > >>>> >> hey Peppe, >>>> >> >>>> >> On 03.08.2016 11 <tel:03.08.2016%2011>: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 >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> >> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>> > >>>> > >>>> > >>>> >>>> ------------------------------------------------------------------------------ >>>> > _______________________________________________ >>>> > Jump-pilot-devel mailing list >>>> > Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> > >>>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>> > >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>>> >>>> >>>> >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> >>>> _______________________________________________ >>>> Jump-pilot-devel mailing list >>>> Jump-pilot-devel@lists.sourceforge.net >>>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>>> >>>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>>> >>>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>> >>> ------------------------------------------------------------------------------ >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> >>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> Jump-pilot-devel mailing list >>> Jump-pilot-devel@lists.sourceforge.net >>> <mailto:Jump-pilot-devel@lists.sourceforge.net> >>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >>> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >> >> ------------------------------------------------------------------------------ >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> <mailto:Jump-pilot-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> >> >> >> >> ------------------------------------------------------------------------------ >> >> _______________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> <mailto:Jump-pilot-devel@lists.sourceforge.net> >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> <https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel> > > ------------------------------------------------------------------------------ > _______________________________________________ Jump-pilot-devel > mailing list Jump-pilot-devel@lists.sourceforge.net > <mailto:Jump-pilot-devel@lists.sourceforge.net> > https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel > <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
