Hi,
thank You for all the suggestions.
I thought about the tolerance myself, but though this is set to 1 mm in our feature types, it has no effect, when storing data or querying data for display. In these cases always all 15 digits are used (coordinates seem to be stored as double precision). As I understand it, this tolerance is only for comparing coordinates and it is not even certain, that it is used in every function, that in some way needs to test, if points are identical.
It would be fine, if the WFS standard could be extended to be able to choose the necessary precision in each request, as Justin suggested. But in my opinion this should not be a proprietary extension of GeoServer in the long term.
We use zipped GML and this might be the reason, that the performance is not as bad as I feared (though the digits can not be compressed any more). So it might make sense to always ouput the data with the full precision of the database. But this must be done in floating point notation (3.44324556501234E-3 instead of 0.00344324556501234). This also would circumvent the problem, if some of the data are stored projected in meters and some in decimal degrees, like EPSG:4326 (which needs much more digits after the comma to get the same precision).
Is it already possible somehow to switch to floating point notation in GML output somehow?
Best Regards,
Gerhard
--
Gerhard Sommer
Magistrat Wien (MA 14-ADV), Rathausstraße 1, 1082 Wien, Austria
E-Mail: gerhard.sommer@anonymised.com
Tel: +43 (1) 4000 91326
Fax: +43 (1) 4000 99 91326
-----Original Message-----
From: Rahkonen Jukka *EXTERN* [mailto:Jukka.Rahkonen@anonymised.com]
Sent: Thursday, January 08, 2009 4:10 PM
To: Sommer Gerhard
Cc: geoserver-users@lists.sourceforge.net
Subject: Re: [Geoserver-users] WFS-T Update and coordinate precision
Hi,
How about trying to set tolerance in Oracle so that it won't
even try to store coordinates with too many decimals? I have
been thinking that perhaps the SDO_TOLERANCE parameter in
DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE) in
user_sdo_geom_metadata table exists for that reason but never
bothered to study if it really is so.
-Jukka Rahkonen-
> -----Alkuperäinen viesti-----
> Lähettäjä: Justin Deoliveira [mailto:jdeolive@anonymised.com]
> Lähetetty: 8. tammikuuta 2009 16:54
> Vastaanottaja: Sommer Gerhard
> Kopio: geoserver-users@lists.sourceforge.net
> Aihe: Re: [Geoserver-users] WFS-T Update and coordinate precision
>
> Hi Gerhard,
>
> I understand the issue. I am not aware of anyone running up
> against th is problem or any existing solutions.
>
> I guess an ideal solution would be to allow you to specify
> the number of decimals in the request explicitly. We
> currently have the idea of format options for this. For
> example, if you wanted to make a getFeature for portrayal purposes:
>
> ...&request=getFeature&format_options=decimals:2
>
> And for analyitcal purposes:
>
> ...&request=getFeature&format_options=decimals:15
>
> Unfortunately this is not implemented. Although it would be
> fairly straight forward. If interested I suggest you create a
> new feature request in the issue tracker.
>
> An alternative solution which could be implemented now is to
> use the GML-ZIP output format. It sends back compressed GML.
> The downside of this is that your client has to be prepared
> to unzip on download.
>
> Hope that helps,
>
> -Justin
>
> Sommer Gerhard wrote:
> > Hallo,
> >
> > using GeoServer to update polygons in an Oracle Locator
> database, we found out recently, that precision problems
> arise, when using GML to update features.
> >
> > As the real world precision of the coordinates is lower
> than 1 cm and to minimize the size of GML documents, we set
> GeoServer to output coordinates with only 2 decimal places.
> But though the coordinates originally stored in the database
> also only had 2 decimal places, after manipulating the data
> using batch processes and desktop GIS software, the
> coordinates stored in double precision in the database have
> more significant numbers after the decimal point (i.e. 75.34
> is now 75.3400000023561).
> >
> > If we get a polygon with GetFeatures and update it using
> WFS-T, though the point has not been changed at all, we have
> 75.34 in the database, while in the neighbouing polygon the
> same point still has 75.3400000023561. Though in the real
> world this is not really relevant, for the software the two
> points are not the same anymore and there are intersections
> and holes between this polygon and the surrounding polygons.
> >
> > The solution would be to set GeoServer to output for
> example 15 decimal places, but then all GetFeature requests,
> even those, that are only for display purposes, produce
> unnecessarily large GML documents. Also, for small coordinate
> values between 0 and 1, this only would work, if we could use
> floating point notation in GML, which to my knowlege is
> currently not possible in GeoServer.
> >
> > Has anybody encountered the same problem and, if so, how
> has it been solved?
> >
> > Best Regards,
> > Gerhard
> > --
> > Gerhard Sommer
> > Magistrat Wien (MA 14-ADV), Rathausstraße 1, 1082 Wien, Austria
> > E-Mail: gerhard.sommer@anonymised.com
> > Tel: +43 (1) 4000 91326
> > Fax: +43 (1) 4000 99 91326
> >
> >
> >
>
----------------------------------------------------------------------
> > -------- Check out the new SourceForge.net Marketplace.
> > It is the best place to buy or sell services for just about
> anything
> > Open Source.
> > http://p.sf.net/sfu/Xq1LFB
> > _______________________________________________
> > Geoserver-users mailing list
> > Geoserver-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
>
> --
> Justin Deoliveira
> OpenGeo - http://opengeo.org
> Enterprise support for open source geospatial.
>
> --------------------------------------------------------------
> ----------------
> Check out the new SourceForge.net Marketplace.
> It is the best place to buy or sell services for just about
> anything Open Source.
> http://p.sf.net/sfu/Xq1LFB
> _______________________________________________
> Geoserver-users mailing list
> Geoserver-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/geoserver-users
>
--------------------------------------------------------------
----------------
Check out the new SourceForge.net Marketplace.
It is the best place to buy or sell services for
just about anything Open Source.
http://p.sf.net/sfu/Xq1LFB
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users