Hi,
At least it seems that the demo layers do not behave like that. The topp:states has plenty of double fields and values look the same with
http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.0.0&request=getfeature&typename=topp:states&outputformat=JSON
and with
http://demo.opengeo.org/geoserver/wfs?service=wfs&version=1.0.0&request=getfeature&typename=topp:states&outputformat=csv.
Topp:states comes from shapefile, how about your data? Which Geoserver version do you run?
-Jukka Rahkonen-
Tanikella, Rajanikanth (SCR US) wrote:
Hello All,
I've looked about but I haven't found any thread discussing this, so forgive me if
it has been covered and please point me to the post.When I use GetFeature I find floating point numbers are being rounded, but only
when I have the parameter outputFormat=CSV. I am using GeoServer v2.4.5. I
have documented this as a question on gis.stackexchange.com
(http://gis.stackexchange.com/questions/93194/why-does-geoservers-
getfeature-round-my-numbers-but-only-for-outputformat-csv) but I'll reiterate
here:Here's my request as JSON:
http://geothermal.smu.edu:9000/geoserver/gtda-
contributions/ows?service=WFS&version=1.0.0&request=GetFeature&typeNam
e=gtda-
contributions:UNDRadiogenicHeat&maxFeatures=1&outputFormat=application/
json...and an excerpt from the response. Note the values for latitude and longitude:
{
"type" : "FeatureCollection",
"totalFeatures" : 343,
"features" : [{
"type" : "Feature",
"id" : "UNDRadiogenicHeat.2540ea6b-f94a-3088-9b32-762c77a8e57f",
"geometry" : {
"type" : "Point",
"coordinates" : [-92.79726665, 47.90752513]
},
"geometry_name" : "shape",
"properties" : {
"latitude" : 47.90752513,
"longitude" : -92.79726665,
...Now the same request with outputFormat=cvs:
http://geothermal.smu.edu:9000/geoserver/gtda-
contributions/ows?service=WFS&version=1.0.0&request=GetFeature&typeNam
e=gtda-contributions:UNDRadiogenicHeat&maxFeatures=1&outputFormat=csv...and an except of the response. The same portion of the data has been
rounded off (48 instead of 47.90752513, and -93 instead of -92.79726665). (I
added the spaces for easy legibility):FID, latitude, longitude,...
UNDRadiogenicHeat.2540ea6b-f94a-3088-9b32-762c77a8e57f, 48, -93,...I've looked for configurations that might cause this, but I see none. I know there
are filters that could do this, but I get the impression that these need to be
explicitly requested, and the above requests do not include filters.Is there something I'm overlooking? Is there some way that GeoServer is
treating the data so glaringly differently just because I'm requesting CSV?Thank you for any insights.
Raj Tanikella
This message and any attachments are solely for the use of intended recipients.
The information contained herein may include trade secrets, protected health or
personal information, privileged or otherwise confidential information.
Unauthorized review, forwarding, printing, copying, distributing, or using such
information is strictly prohibited and may be unlawful. If you are not an intended
recipient, you are hereby notified that you received this email in error, and that
any review, dissemination, distribution or copying of this email and any
attachment is strictly prohibited. If you have received this email in error, please
contact the sender and delete the message and any attachment from your
system. Thank you for your cooperation------------------------------------------------------------------------------
Is your legacy SCM system holding you back? Join Perforce May 7 to find out:
• 3 signs your SCM is hindering your productivity • Requirements for
releasing software faster • Expert tips and advice for migrating your SCM
now http://p.sf.net/sfu/perforce
_______________________________________________
Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users