Re: [JPP-Devel] Add SRID and units to Task

[Michaël Michaud]

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 : [20..209199]

Code :
EPSG : ]-∞..32768[ or ]599..2147483647]
ESRI : ]32999..20[
CUSTOM : [32768..32999] or [20..599]

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 >:


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

**(**InputStream

**in,**String
** 
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 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
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

Re: [JPP-Devel] Add SRID and units to Task

[Giuseppe Aruta]

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 :

> 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 : [20..209199]
>
> Code :
> EPSG : ]-∞..32768[ or ]599..2147483647]
> ESRI : ]32999..20[
> CUSTOM : [32768..32999] or [20..599]
>
> 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 :
>
>> 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
>> *
>> *(**InputStream
>> *
>> * in, **String
>> *
>> * 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 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 :
>>
>>> 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, Open

Re: [JPP-Devel] Add SRID and units to Task

[Giuseppe Aruta]

Maybe I should correct on this way - to save compatibility with geotif

Code :

integer
EPSG : [2000..32767] or [599..2147483647]
ESRI : [32999..20]
GEOTIF PROJECTION: [1..28]*
CUSTOM : [29..1999] or [32769..32999] or [20..699]
NOT DEFINED: [-1]
USER DEFINED: [0] or [32768]

not integer
IGNF:

* See http://www.sno.phy.queensu.ca/~phil/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 :

> 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 :
>
>> 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 : [20..209199]
>>
>> Code :
>> EPSG : ]-∞..32768[ or ]599..2147483647]
>> ESRI : ]32999..20[
>> CUSTOM : [32768..32999] or [20..599]
>>
>> 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 :
>>
>>> 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
>>> *
>>> *(**InputStream
>>> *
>>> * in, **String
>>> *
>>> * 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 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
>>> P