Hi,
You must push the beast into the corner and then you can catch it. Eliminate one possibility at a time. I would start by converting your data into shapefile and creating a test layer from that. If it fails in a similar way you can make a minimal shapefile with couple of features and send it for further investigations. If it works, the fault is somewhere on the database side. Convert some data from your view into a regular table and test again. It table works but view not, then it is something in how the view is handled.
-Jukka Rahkonen-
Tanikella, Rajanikanth (SCR US) wrote:
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.rahkonen@anonymised.com]
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-usersThis 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