yes Mike, you did miss > Or we could add a CRS element into GML Input Template section and boundedBy > like in GML2 into the data section: > > <?xml version='1.0' encoding='UTF-8'?> > <JCSDataFile xmlns:gml="http://www.opengis.net/gml"; > xmlns:xsi="http://www.w3.org/2000/10/XMLSchema-instance"; > > <JCSGMLInputTemplate> > <CollectionElement>featureCollection</CollectionElement> > <CRSElement>boundedBy</CRSElement> > <FeatureElement>feature</FeatureElement> > <GeometryElement>geometry</GeometryElement> > <ColumnDefinitions> > </ColumnDefinitions> > </JCSGMLInputTemplate> > > <featureCollection> > <gml:boundedBy> > <gml:Box srsName="http://www.opengis.net/gml/srs/epsg.xml#4326";> > <gml:coordinates decimal="." cs="," ts=" ">474.0,280.0 > 620.0,380.0</gml:coordinates> > </gml:Box> > </gml:boundedBy> > <feature> > ... > > -Jukka-
and > Jukka, > > this looks more like a workaround, misusing a bounding box definition's saved > srs although it of course should match the data's. > > the clean gml way would probably be (as you mentioned) to srs tag every > feature as the standard expects, but that of course would blow up the dataset > exponentially unnecessarily. > > ..ede and > Hi, > > Workaround or convenience as OGC writes in the WFS 2.0 standard: > > 11.3.6 Inheritance rules for srsName values > For convenience in constructing feature collection instances, the value of > the srsName attribute on the > gml:Envelope which is the value of the wfs:boundedBy property of a response > feature collection shall be > inherited by all directly expressed geometries in all properties of the > members of the collection, unless > overruled by the presence of a local srsName. Thus it is not necessary for a > geometry to carry a srsName > attribute, if it uses the same coordinate reference system as given on the > wfs:boundedBy property of the > envelope. Inheritance of the coordinate reference system continues to any > depth of nesting, but if overruled by > a local srsName declaration, then the new coordinate reference system is > inherited by all its children in turn > > -Jukka- that should be all :).. ede On 11/29/2017 23:19, Michaël Michaud wrote: > Hi, > > I've probably missed something. Are we talking about setting a SRID, setting > a "bounding box", or does "bounding box" means one srid for all ? > > Michaël > > > Le 29/11/2017 à 17:12, edgar.sol...@web.de a écrit : >> Jukka and All, >> >> let's not overengineer it! i am halfway through w/ implementing the bounding >> box solution, which is >> - GML2 spec compatible >> - automagically available in GML2 writer, as it is the same writer we use >> for JML >> - fulfills 1,2,3 of the JUkka list >> . >> JML versions will be needed when we start breaking backward compatibility. i >> do not see that coming for now. why invent the wheel, when we have a >> perfectly standardized format specification that we can implement already >> (GML2). >> >> ..ede >> >> On 29.11.2017 16:39, Rahkonen Jukka (MML) wrote: >>> Hi, >>> >>> >>> QGIS opens vectors both with its own providers, both through GDAL. JML is >>> opened with GDAL. Sidecar files are used if drivers are made to support >>> them and because GDAL JML driver will need a refresh anyway we are free to >>> decide how to include the information about SRID. >>> >>> >>> My preferences are: >>> >>> 1) New JML should be backwards compatible and new OJ should open the >>> old JML files also in the future >>> >>> 2) Because JML is XML and encodes geometries as GML 2 it would not >>> harm if the new format contains both valid XML and GML2 structures. >>> >>> 3) I do not like the sidecars because it brings a need to zip the >>> files together and people tend to forget to put the sidecars into the >>> package. >>> >>> >>> For me 1) is essential and I am flexible with 2) and 3). I can take care >>> that the GDAL driver will be updated if we can agree on how to include SRID >>> into JML. Attribute in the featureCollection with a working web link looks >>> simple but I do not know how much harm it could make to break GML2. The two >>> software that I know to read JML are OpenJUMP and GDAL. >>> >>> >>> <featureCollection srsName="http://www.opengis.net/def/crs/EPSG/0/4326";> >>> >>> >>> It might be good to include also JML version somewhere. If the original is >>> without version number we could say that the version number defaults to 1.0 >>> and the new one with SRID is JML 1.1 of JML 2. Suggestions where in the JML >>> file to tell that? Are there more possible needs for JML 2.0 like some >>> geometry types which are not supported by GML2? >>> >>> >>> -Jukka Rahkonen- >>> >>> >>> *Lähettäjä:*Giuseppe Aruta [mailto:giuseppe.ar...@gmail.com] >>> *Läh**etetty:*29. marraskuuta 2017 12:14 >>> *Vastaanottaja:* OpenJump develop and use >>> <jump-pilot-devel@lists.sourceforge.net> >>> *Aihe:* Re: [JPP-Devel] Fwd: setting SRID >>> >>> >>> Gdal/ogr2ogr is used by QGIS. >>> >>> Can QGIS independently decode external sidecar files, like aux.xml? or is >>> everything done by gdal. >>> >>> Limiting to raster files (AFAIR) some gis sofware were able to read >>> external auxiliary files (on demand by the user) to catch info about >>> projection. >>> >>> Peppe >>> >>> >>> 2017-11-29 8:11 GMT+01:00 Michaël Michaud <m.michael.mich...@orange.fr >>> <mailto:m.michael.mich...@orange.fr>>: >>> >>> 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 >>> <mailto: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 <http://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 <http://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 <http://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 >>> <mailto:edgar.sol...@web.de> >>> To: OpenJump develop and use >>> <jump-pilot-devel@lists.sourceforge.net >>> <mailto: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 >>> <mailto: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 >>> <mailto: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
