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 France Géoportail: 310024802 to 310915814 - France Gé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>: > 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. > 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>: > >> 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>: >> >>> 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>: >>> >>>> 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) 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 - 2011) >>>> >>>> 2016-08-04 23:32 GMT+02:00 Michaël Michaud <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 ha scritto: >>>>> > >>>>> >> hey Peppe, >>>>> >> >>>>> >> On 03.08.2016 11 <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 >>>>> >> 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 >>>> listJump-pilot-devel@lists.sourceforge.nethttps://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 >>> listJump-pilot-devel@lists.sourceforge.nethttps://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 > listJump-pilot-devel@lists.sourceforge.nethttps://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
