Hi Peppe,
Just wonder why you want to retrieve authorities from srid ?
If it is important, why not adding authority in the srid.txt file ?
It is quite impossible to get authority from code as codes are supposed
to be unique for a single authority only.
By chance, EPSG is so well-known that most implementions (ESRI, GeoTIFF,
PostGIS) take care to use the same code for the same CRS, and add new
CRS in a specific range of codes unused by EPSG. But every implementor
has its own rules, and what I've found is very confusing.
negative srid : unused, except -1 which used to mean UNKNOWN in postgis 1.x
0 : means UNKNOWN in GeoTIFF and PostGIS 2.x
1-2000 : unused but valid EPSG codes for CRS
2000-32766 : EPSG codes also used by ESRI (WKID), PostGIS, GeoTIFF for
the same CRSs...
In GeoTIFF, projected CRS codes seem to start at 20000, but
smaller EPSG codes exist in EPSG database
note : SR-ORG codes (1-9000) are overlapping EPSG code range
32767 : user-defined in GeoTIFF implementation ( don't know what is the
difference between user-defined and private-user implementation ?)
32768-max :
GeoTIFF : 32768-65535 : private user implementation
ESRI : 32768 - 33000 : unused ?
ESRI : 33000-200000 : ESRI authority
ESRI : 200000-209199 : ESRI Custom codes
PostGIS : 32768 - 910000 : ? (can be used for ESRI WKID ?)
PostGIS : 910000 - 998999 : Custom codes
SpatialReference : EPSG:61000000-69000000 (superseded, not
referenced in EPSG database)
GeoTIFF Projection and ProjCoordTrans are other types of beast. They do
not define a Coordinate Reference System.
What I would keep :
-1, 0 : UNKNOWN
1-32766 : EPSG registry
33000-200000 : ESRI registry
other : CUSTOM/SRID
Not sure why you distinguish SRID from CUSTOM. Have they different
meaning/usage ?
Michaël
Le 03/09/2016 à 19:43, Giuseppe Aruta a écrit :
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
<http://www.sno.phy.queensu.ca/%7Ephil/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
<mailto: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 <mailto: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
<mailto: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
<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
<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
<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
<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
