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 <mailto: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
<mailto:edgar.sol...@web.de> ha scritto:
>
>> hey Peppe,
>>
>> On 03.08.2016 11 <tel: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
<mailto:Jump-pilot-devel@lists.sourceforge.net>
>> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
<https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel>
>
>
>
------------------------------------------------------------------------------
> _______________________________________________
> Jump-pilot-devel mailing list
> Jump-pilot-devel@lists.sourceforge.net
<mailto:Jump-pilot-devel@lists.sourceforge.net>
> https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
<https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel>
>
------------------------------------------------------------------------------
_______________________________________________
Jump-pilot-devel mailing list
Jump-pilot-devel@lists.sourceforge.net
<mailto:Jump-pilot-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/jump-pilot-devel
<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
