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
