hey Mike,
i see where you're getting at, but currently i am just looking for a way to
transport the SRID info of a vector layer down to the jump writer. for this
purpose the CoordinateSystem object suits me just fine.
there's no reason not to use it for now, as it is updated and stores the info
we want for SRID tagged JML. it has the big advantage that it is attached to
the FeatureSchema, which is part of the FeatureCollection, which is all that is
piped down to the reader.
should we decide to streamline SRID tagging over all layerable types, we will
have to provide a legacy compatibility anyway, which means keeping
FeatureSchema.setCoordinateSystem(...) et al. anyway.
the reprojection code can easily be left untouched and unused, as it is since
ages and will trouble nobody. of course we can as well simply strip it as it
was never used anyways.
hope you'll agree.. ede
On 20.12.2017 22:28, Michaël Michaud wrote:
> Hi Ede,
>
> OpenJUMP includes all successive attempts to manage SRID and Coordinate
> Transformation and it has become really messy with the time...
>
> here are some reasons (AFAIR) why I did not use CoordinateSystem at the first
> place :
> - Since RasterLayer and WMSLayer have been implemented, layer is no more the
> only Layerable and I thought that SRID should be managed at a higher level
> - in between, SRIDStyle has been added to OpenJUMP : I'm not sure it is the
> best place to handle SRID either, but as it is lightweight, I think
> developpers have felt more comfortable to work with that (including me)
> - but the main reason is that CoordinateSystem is not a thin wrapper around a
> SRID. It includes a Projection object which is supposed to implement
> Coordinate Transformation algorithms but which was not compatible with the
> tansformation library I was working on.
>
> Any way, it is a difficult area and if you have ideas to improve the way
> layers, datasources, cts, SRIDStyle work together, you're welcome.
>
> For me some important points are :
> - a single point to perform transformation (currently cts, but ideally, it
> should be pluggable)
> - an easy way to manage srid through datasource, layerable, geometries, UI (I
> admit I had some difficulties to get SRID information from the
> ShapefileWriter when I added prj writer)
>
> Michaël
>
> Le 20/12/2017 à 17:23, edgar.sol...@web.de a écrit :
>> Mike & All,
>>
>> just had a look at r5543 and saw that FeatureSchema since the first commit
>> in 2005 has a field and getter/setter for
>> com.vividsolutions.jump.coordsys.CoordinateSystem, which is a light wrapper
>> around an EPSG code.
>>
>> that is news to me and means that the SRID is already attached to vector
>> layers, as every FeatureCollection holds a FeatureSchema.
>>
>> not sure what was difficult to add the SRID support to the SHP writer in
>> that case Mike. could you explain?
>>
>> ..ede
>>
>> On 29.11.2017 08:11, Michaël Michaud wrote:
>>> Hi Ede, Jukka,
>>>
>>> I've no idea about the best way to store srid information into jml.
>>> - Customized light way (e.g. attribute of the featureCollection tag) or
>>> - A pure gml way (a URI or URN on each geometry)
>>>
>>> I don't think that the first way can be a problem, but other gml drivers
>>> will not be able to read it
>>> (AFAIK, the only external jml driver is the ogr2ogr addon made on jukka's
>>> request).
>>>
>>> In both case I think we must keep registry information (default = EPSG) et
>>> SRS code as a String.
>>>
>>> About transfering information from SRIDStyle to writer, I had hard time to
>>> find a way for shapefile.
>>>
>>> I set 2 properties ("EPSG" and SRID taken from SRIDStyle) through
>>> InstallStandardDataSourceQueryChoosersPlugin
>>>
>>> Maybe also available for jml ?
>>>
>>> If you want to have a look, changes are in r5543
>>>
>>> Michaël
>>>
>>>
>>>
>>> Le 28/11/2017 à 23:18, edgar.sol...@web.de a écrit :
>>>> putting this back on the list..
>>>>
>>>> just asking because Jukka asked for SRID support for JML
>>>> https://sourceforge.net/p/jump-pilot/mailman/message/36133057/
>>>>
>>>> we negotiated a plain GML2 solution via a bounding box. now i am
>>>> engineering a way to route the layers SRID style value to the file writer,
>>>> which traditionally only receive the feature collection.
>>>> how'd you transfer this and possibly other informations to the legacy
>>>> writers?
>>>>
>>>> ..ede
>>>>
>>>>
>>>> On 11/28/2017 23:10, Michaël Michaud wrote:
>>>>> Ede,
>>>>>
>>>>> Just had a look into WritableDataStoreDataSource code.
>>>>>
>>>>> Generally, it uses the srid defined in the DataSource properties to write
>>>>> geometries to PostGIS.
>>>>>
>>>>> There is a single corner case where a second geometry is stored into an
>>>>> attribute of type Object, in which case, it will try to use the embeded
>>>>> Geometry SRID.
>>>>>
>>>>> This corner case could probably be ignored if there was a real interest
>>>>> to let a default 0 value in Geometry SRID.
>>>>>
>>>>> I still must check the old PostGIS writer...
>>>>>
>>>>> Michaël
>>>>>
>>>>>
>>>>> Le 28/11/2017 à 21:43, Edgar Soldin a écrit :
>>>>>> On 11/28/2017 20:52, Michaël Michaud wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>>
>>>>>>>>> Hi Ede,
>>>>>>>>>
>>>>>>>>> I just realize that I haven't received message posted to
>>>>>>>>> jump-pilot-devel for months (beginning of august I think)
>>>>>>>> ok, what about the issue "setting SRID"? any comment?
>>>>>>> I'm not sure. That's right, we don't manage srid at the object level
>>>>>>> (and most GIS and Database also manage srid information at the table
>>>>>>> level).
>>>>>>> On the other hand, I think setting SRID on every object is quite cheap,
>>>>>> how is iterating over millions of features cheap? :)
>>>>>>
>>>>>>> and I must check how srid is handle when writing to database (maybe the
>>>>>>> JTS writer uses the srid embeded in the Geometry to write the correct
>>>>>>> EWKB into postgis).
>>>>>> ahh, good to know.
>>>>>>
>>>>>>>> and that my last messages have not been sent to the list (just thought
>>>>>>>> that the list was sleeping...).
>>>>>>>> your last message i see is from the 31.07.2017
>>>>>>>>
>>>>>>>> https://sourceforge.net/p/jump-pilot/mailman/search/?q=michaud&limit=25&page=0&sort=posted_date%20desc
>>>>>>> ya, last message I received is from august 1st.
>>>>>>>
>>>>>> just checked.. sf.net limited the admin access to user management for
>>>>>> privacy concerns.. so you have to cchek your account yourself. the link
>>>>>> is below.
>>>>>>
>>>>>> you are on no blocklist afaics.. ede
>>>>>>
>>>>>>>>
>>>>>>>>> Any idea ? May be a problem with my own webmail or with my
>>>>>>>>> subscription...
>>>>>>>> spam folder? maybe your mail provider blocks sf.net because there was
>>>>>>>> spam?
>>>>>>>>
>>>>>>>>> Do you know how we can check subscribers ?
>>>>>>>> you can check your account
>>>>>>>>
>>>>>>>> https://sourceforge.net/projects/jump-pilot/lists/jump-pilot-devel/unsubscribe
>>>>>>>>
>>>>>>>> let me have a look in the sf.net admin section.. ede
>>>>>>>>
>>>>>>>>> Michaël
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Le 28/11/2017 à 14:59, Edgar Soldin a écrit :
>>>>>>>>>> Mike, have you seen this message? ..ede
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> -------- Forwarded Message --------
>>>>>>>>>> Subject: setting SRID
>>>>>>>>>> Date: Sun, 26 Nov 2017 19:52:34 +0100
>>>>>>>>>> From: edgar.sol...@web.de
>>>>>>>>>> To: OpenJump develop and use <jump-pilot-devel@lists.sourceforge.net>
>>>>>>>>>>
>>>>>>>>>> hey All,
>>>>>>>>>>
>>>>>>>>>> i just found this method in SRIDStyle.java while adding a setting to
>>>>>>>>>> route through the writers. it applies the new srid to _every_
>>>>>>>>>> geometry, which sounds slow on big datasets and unnecessary as we do
>>>>>>>>>> not support multi SRID layers currently, or do we?
>>>>>>>>>>
>>>>>>>>>> ..ede
>>>>>>>>>>
>>>>>>>>>> public void updateSRIDs(Layer layer) {
>>>>>>>>>> ...
>>>>>>>>>> // apply srid for each geometry
>>>>>>>>>> for (Object feature :
>>>>>>>>>> layer.getFeatureCollectionWrapper().getFeatures()) {
>>>>>>>>>> ((Feature)feature).getGeometry().setSRID(srid);
>>>>>>>>>> }
>>>>>>>>>> }
>>>>>>>>>>
>>>> ------------------------------------------------------------------------------
>>>> 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
>>>
>>> ------------------------------------------------------------------------------
>>> 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
>>
>> ------------------------------------------------------------------------------
>> 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
>
>
> ------------------------------------------------------------------------------
> 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
------------------------------------------------------------------------------
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
