Manfred, hires versions of both are available in our svn https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/logo/ & https://sourceforge.net/p/jump-pilot/code/HEAD/tree/core/trunk/icon/ . as long as they are used in conjunction with OJ, you are free to use them as they are. feel free to post us a link when you are done!
..ede On 28.11.2016 07:37, Giuseppe Aruta wrote: > Hi Manfred > Sorry for the late answer. > This is interesting. If you have papers that could be of general interest > for OJ community we can put on our wiki. > Which symbols do you mean? > Peppe > > Il 22/Nov/2016 12:42, "manf...@egger-gis.at" <manf...@egger-gis.at> ha > scritto: > >> Hello, >> >> i will present your neutral (look below) approach on 9th January 2017 at >> the University of Salzburg/Austria. I think your idea is very user friendly. >> >> I think CTS (https://github.com/orbisgis/cts) is updated with every new >> version of EPSG-Database provided by http://www.epsg-registry.org/? >> >> Another question: Can i add your OPEN JUMP SYMBOL to my website? >> >> Best regards, >> >> Manfred >> >> -----Original Message----- >> From: "Giuseppe Aruta" <giuseppe.ar...@gmail.com> >> Sent: Saturday, October 1, 2016 12:04pm >> To: "OpenJump develop and use" <jump-pilot-devel@lists.sourceforge.net> >> Subject: Re: [JPP-Devel] Add SRID and units to Task >> >> ------------------------------------------------------------ >> ------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, SlashDot.org! http://sdm.link/slashdot______ >> _________________________________________ >> Jump-pilot-devel mailing list >> Jump-pilot-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel >> Hi Manfred, >> I will give a brief description on how CRS information plugin works. >> >> CRS info is based on the CRS list srid.txt, located into >> org.openjump.core.ccordsys.utils folder. Plus some methods located into >> the >> same folder (thanks to Michael that made this part more flexible and >> intuitive) >> >> The file srid.txt is a series of rows. Each row describes a projection with >> only 3 parameters: >> <SRID of projection>;<description of projection>;[Unit of projection] >> example: >> <32632>;<WGS 84 UTM zone 32N>;[metre] >> Note that <description of projection> uses a neutral description which is >> neither OCG nor ESRI (see point c) >> There are no other parameters for transformations as this plugin provides >> only CRS information (and keep srid.txt file as small/simple as possible) >> >> How it works: >> >> a) Layer properties plugins read auxiliary files (.prj or .aux) or geotiff >> tag to get a proj info: >> Many methos are invoked depending on the type of the file and where this >> info can be located. In this last case this plugin uses different >> strategies depending also to the auxiliary file. >> >> b) at first stage, a method search the presence of a projection WKT and >> reads the proj description (which is usually located between first double >> quotes into the WKT code, after PROJC[ or GEOGC[ strings) (see >> ProjUtils.decodeProjDescription). >> Giving an example, the output could be "WGS 84 / UTM zone 32N" (for OGC >> wkt) or "WGS_1984_UTM_Zone_32N" (for ESRI wkt) - the method doesn't define >> neither the WKID nor the authority, it only reads the proj code description >> >> c) Afterwards, a second method convert that description in a neutral >> "readable string". >> What is a readable string? Exploring http://spatialreference.org, I >> found >> that there are some semantic rules adopted by ESRI wkt that can be >> converted into OGC and viceversa. For instance ESRI separate words of proj >> description using udescore "_" while OGC uses spaces or slashes"/". >> Decoding those rules, it was easy to create a method that convert both OGC >> and ESRI to a valid neutral text (see methos >> ProjUtils.decodeProjDescription). >> for instance, both "WGS 84 / UTM zone 32N" and "WGS_1984_UTM_Zone_32N" >> are converted to "WGS 84 UTM zone 32N". >> >> d) a third method searches text "WGS 84 UTM zone 32N"on srid.txt. >> It finds the row: <32632>;<WGS 84 UTM zone 32N>;[metre] and gives back WKID >> 32632 >> >> e) a forth simple method try to guess the authority from the WKID number >> following these rules: >> 1) WKID <32768 or >5999999 will result in an AUTHORITY name of "EPSG". >> 2) A WKID in range between 33000 and 199999 will result in an AUTHORITY >> name of "ESRI". >> // ( >> http://help.arcgis.com/en/arcgisserver/10.0/apis/soap/ >> whnjs.htm#SOAP_Geometry_FindSRByWKID.htm >> ) >> >> f) the final output is the complete description ESRI:32632 - WGS 84 UTM >> zone 32N - metre >> >> g) if no string on srid.txt is found, the final output will be the complete >> projection WKT string, so users can copy and try to use >> http://prj2epsg.org/search service to find the real (almost) WKID >> >> Nothe that the method d) doesn't cover all the possibilities (I found that >> old qgis adopted different rules to describes projections). >> In this case, >> ProjUtils.decodeProjDescription is build nin order to adopt new rules in >> the future >> OR >> It is possible to add alias into srid.txt. >> for instance: >> <4326>;<WGS 84>;[degree] >> <4326>;<GCS WGS 84>;[degree] >> >> Best regards >> Peppe >> >> >> >> 2016-09-29 22:45 GMT+02:00 Michaël Michaud <m.michael.mich...@orange.fr>: >> >>> Hi Manfred, >>> >>> Just to make it clear. OpenJUMP uses two different pieces of codes to >>> get the CRS from a datasource and to perform transformations. >>> >>> To get CRS information from datasource (either vector or raster), we use >>> a small plugin based on a list of CRS prepared by Peppe and included in >>> OpenJUMP CORE (maybe Peppe can tell more about it) : >>> org.openjump.core.ccordsys.utils.srid.txt >>> >>> For coordinate transformation, OpenJUMP PLUS uses CTS >>> (https://github.com/orbisgis/cts), which itself uses a snapshot of EPSG >>> database for CRS definitions. >>> >>> For the sake of completeness, OpenJUMP also uses a list of EPSG codes in >>> WMS plugin to know if the requested dataset must be interpreted in >>> latlon or in lonlat order. >>> >>> None of these resources describes the area in which each CRS is valid. >>> >>> Michaël >>> >>> >>> >>> Le 29/09/2016 à 06:00, manf...@egger-gis.at a écrit : >>>> Good morning! >>>> >>>> I published a first version of my tool including registered EPSG-Codes >>> in geotools 2.6.0. : >>>> >>>> http://www.egger-gis.at/shapefile-projectionfinder/ >>>> >>>> Before i start to develop a OPEN JUMP PLUGIN i want to ask which >>> databases OPEN JUMP uses for transformations? >>>> >>>> I the last weeks i saw in your email traffic that you included >> different >>> sources of projection definitions (EPSG, ESRI, user defs, ...)? >>>> >>>> And is it possible to make different .prj files? You know ESRI can not >>> read WKT by OGC... >>>> >>>> Best regards, >>>> >>>> Manfred Egger >>>> >>>> Alois-Schrott-Str. 34 >>>> 6020 Innsbruck >>>> Austria >>>> >>>> Web: http://egger-gis.at >>>> >>>> -----Original Message----- >>>> From: "Michaël Michaud" <m.michael.mich...@orange.fr> >>>> Sent: Thursday, August 4, 2016 5:32pm >>>> To: jump-pilot-devel@lists.sourceforge.net >>>> Subject: Re: [JPP-Devel] Add SRID and units to Task >>>> >>>> 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: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 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 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
