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 list Jump-pilot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
