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