Hello Jukka, I'm using GeoServer 2.4.5. Interesting that that the demo data behaves correctly. My data is not from a shapefile. Rather, we have a custom routine which loads a database from various files, and the layer is defined as a view in that database.
Raj -----Original Message----- From: Rahkonen Jukka (Tike) [mailto:jukka.rahko...@mmmtike.fi] Sent: Monday, May 05, 2014 10:04 AM To: Tanikella, Rajanikanth (SCR US); geoserver-users@lists.sourceforge.net Subject: Re: [Geoserver-users] Why does GetFeature round my floating point numbers, but only for outputFormat=CSV? 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 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
