Peppe,
I committed a new version of ProjUtils (ProjUtils2).
The code is not tested and not yet active. Let me know if you think we
can go on this way (I may have broken some tests in my willing to simplify).
If you're OK with proposed changes, I think we can go a step further :
- GeoTiffEnvelope : unused and seems redundant with
LoadSextanteRasterImagePlugIn#getGeoReferencing
- readSRIDFromGeoTiffFile should benefit from refactoring (using
getPrjNameFromGeoDirTags),
but I wondered if it must really be distinct from readSRSFromGeoTiffFile ?
GeoTIFF stuff :
Maybe there is some refactoring possible between ProjUtils, and
TiffTags/TiffUtils classes in rasterimage package.
A method to get the SRID from geotiff would make sense in TiffTags
class. What do yo think ?
Michaël
Le 04/09/2016 à 16:11, Giuseppe Aruta a écrit :
Hi Michaël
thanks for the explanation. It was a bit confusing (not only for me)
when studing this topic
--------------------------------
EPS codes
http://www.ihsenergy.com/epsg/geodetic2.html
reading this page it seems that EPSG code range are:
0 - 32767 and 6,000,000 - 6,999,999 (since ver. 6.6)
---------------------------------
regarding SRID vs CUSTOM,
According to Wikipedia SRID "is a unique value used to unambiguously
identify projected, unprojected, and local spatial coordinate system
definitions"
https://en.wikipedia.org/wiki/Spatial_reference_system#Identifier
(In that case it seems to be the equivalent of ESRI WKID
(https://developers.arcgis.com/javascript/3/jsapi/spatialreference-amd.html).
while
CUSTOM, as I understood, is a local projection
(http://wiki.gis.com/wiki/index.php/Custom_projection).
ESRI defines CUSTOM codes (200000-209199) which are outside the
"official ones".
EPSG uses a different "authority acronym" SR-ORG to define them so
there are SR-ORG/ESRI overlaping codes.
Thi is a new proposal, that needs to be inspect, anyhow
a) recognized as integer
UNKNOWN: -1, 0 : UNKNOWN
EPSG: 1-32766 [ or 1026-32766(**) ] and 5999999-2147483647
ESRI: 33000-200000 : ESRI registry
FranceGéoportail: 310024802 to 310915814 - FranceGéoportail , not
recognized by EPSG, the info seems quite outdated
(http://www.wms.lautre.net/projgp.html)
SRID: other (no intention to define whether the codes are defined by
users (CUSTOM) or not, no intention to define if it belongs to other
authority that EPSG/ESRI)
b) recognized as string
I would let it blank, even if we only have INGF codes.
Peppe
(*) according to this page (http://www.wms.lautre.net/projgp.html)
(**) http://www.ihsenergy.com/epsg/geodetic2.html
2016-09-04 12:54 GMT+02:00 Michaël Michaud
<m.michael.mich...@orange.fr <mailto:m.michael.mich...@orange.fr>>:
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
<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
