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
