[TinyOWS-users] Does TinyOWS do reprojection?
Brent Fraser
bfraser at geoanalytic.com
Wed Feb 29 10:05:10 EST 2012
Oliver (and others),
Just to narrow down the question
"Does TinyOWS support re-projection in transactions to a PostGIS database?"
and a little more background:
My typical use-case is to store my data in PostGIS in a geographic SRS
such as EPSG:4326, but display (and edit) in EPSG:3857 (aka 900913).
We're (the Geomoose PSC) in the process of releasing GeoMoose v2.6
with a new JavaScript Feature Editor built on OpenLayers and using
WFS-T, and I'd like to document an example using TinyOWS as the WFS-T
server.
If the answer is "No, TinyOWS does not support re-projection", then I'll
just document storing and editing the data in EPSG:3857.
Best Regards,
Brent Fraser
On 2/15/2012 9:08 AM, Brent Fraser wrote:
> Oliver,
>
> Geomoose's Feature Editor is JavaScript built on top of OpenLayers'
> WFS-T support. Here's the line from the TinyOWS log
>
> [Wed Feb 15 08:39:17 2012] [QUERY] <wfs:Transaction
> xmlns:wfs="http://www.opengis.net/wfs" service="WFS" version="1.1.0"
> xsi:schemaLocation="http://www.opengis.net/wfs
> http://schemas.opengis.net/wfs/1.1.0/wfs.xsd
> http://thinkcentre1/cgi-bin/tinyows.exe
> http://thinkcentre1/cgi-bin/tinyows.exe?service=WFS&version=1.1.0&request=DescribeFeatureType&TypeName=censuscities"
> xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"><wfs:Update
> typeName="feature:censuscities"
> xmlns:feature="http://thinkcentre1/cgi-bin/tinyows.exe"><wfs:Property><wfs:Name>the_geom</wfs:Name><wfs:Value><gml:MultiSurface
> xmlns:gml="http://www.opengis.net/gml"
> srsName="EPSG:3857"><gml:surfaceMember><gml:Polygon><gml:exterior><gml:LinearRing><gml:posList>-10356035
> 5547218 -10356358.189312972 5548684.080055897 -10354924 5548340
> -10354228 5548341 -10353753 5548338 -10353752 5548272 -10353744
> 5547729 -10353740 5547434 -10353737 5547256 -10353738 5547232
> -10353738 5547220 -10353785 5546732 -10353784 5546689 -10353783
> 5546674 -10353763 5546063 -10353766 5546000 -10353799 5545999
> -10353909 5545996 -10354159 5546030 -10354246 5546041 -10354315
> 5546049 -10354339 5546049 -10354887 5546037 -10354900 5546039
> -10354971 5546046 -10355981 5546070 -10356034 5546069 -10356034
> 5546119 -10356035 5546523 -10356035 5546587 -10356036 5546723
> -10356035 5546769 -10356035 5546789 -10356031 5546972 -10356032
> 5547043 -10356035
> 5547218</gml:posList></gml:LinearRing></gml:exterior></gml:Polygon></gml:surfaceMember></gml:MultiSurface></wfs:Value></wfs:Property><wfs:Property><wfs:Name>statefp10</wfs:Name><wfs:Value>27</wfs:Value></wfs:Property><wfs:Property><wfs:Name>placefp10</wfs:Name><wfs:Value>53098</wfs:Value></wfs:Property><wfs:Property><wfs:Name>placens10</wfs:Name><wfs:Value>02396316</wfs:Value></wfs:Property><wfs:Property><wfs:Name>geoid10</wfs:Name><wfs:Value>2753098</wfs:Value></wfs:Property><wfs:Property><wfs:Name>name10</wfs:Name><wfs:Value>Randolph</wfs:Value></wfs:Property><wfs:Property><wfs:Name>namelsad10</wfs:Name><wfs:Value>Randolph
> city</wfs:Value></wfs:Property><wfs:Property><wfs:Name>lsad10</wfs:Name><wfs:Value>25</wfs:Value></wfs:Property><wfs:Property><wfs:Name>classfp10</wfs:Name><wfs:Value>C5</wfs:Value></wfs:Property><wfs:Property><wfs:Name>pcicbsa10</wfs:Name><wfs:Value>N</wfs:Value></wfs:Property><wfs:Property><wfs:Name>pcinecta10</wfs:Name><wfs:Value>N</wfs:Value></wfs:Property><wfs:Property><wfs:Name>mtfcc10</wfs:Name><wfs:Value>G4110</wfs:Value></wfs:Property><wfs:Property><wfs:Name>funcstat10</wfs:Name><wfs:Value>A</wfs:Value></wfs:Property><wfs:Property><wfs:Name>aland10</wfs:Name><wfs:Value>2477617</wfs:Value></wfs:Property><wfs:Property><wfs:Name>awater10</wfs:Name><wfs:Value>182190</wfs:Value>&
> lt;/wfs
> :Property><wfs:Property><wfs:Name>intptlat10</wfs:Name><wfs:Value>+44.5251562</wfs:Value></wfs:Property><wfs:Property><wfs:Name>intptlon10</wfs:Name><wfs:Value>-093.0193333</wfs:Value></wfs:Property><ogc:Filter
> xmlns:ogc="http://www.opengis.net/ogc"><ogc:FeatureId
> fid="censuscities.806"/></ogc:Filter></wfs:Update></wfs:Transaction>
>
> The coordinates in the GML polygon are indeed EPSG:3857. That is
> my display/edit projection in OpenLayers so nothing unexpected there.
> My expectation is that TinyOWS would create an UPDATE query containing
> the PostGIS ST_Transform() function to transform the geometry from
> EPSG:3857 to EPSG:4269 (my storage SRS). But it doesn't, and it
> doesn't even specify any SRS for the geometry, so the UPDATE fails with:
>
> [Wed Feb 15 08:39:17 2012] [ERROR] ERROR: new row for relation
> "censuscities" violates check constraint "enforce_srid_the_geom"
>
> But I could be wrong; I'm new to WFS-T and TinyOWS, and my knowledge
> of PostGIS is shallow...
> Best Regards,
> Brent Fraser
>
> On 2/15/2012 3:05 AM, Olivier Courtin wrote:
>> On Tue, Feb 14, 2012 at 1:10 AM, Brent Fraser
>> <bfraser at geoanalytic.com <mailto:bfraser at geoanalytic.com>> wrote:
>>
>> Brent,
>>
>> I'm alpha testing the new Feature Editor within GeoMoose v2.6.
>> It is a JavaScript application using OpenLayers 2.11, MS4W 3, and
>> PostGIS 1.5 at the backend.
>>
>>
>> Humm i don't know anything about Feature Editor,
>> and anyway, hat is the exact WFS request query sended to TinyOWS ?
>> (you could use TinyOWS log to grab it)
>>
>> --
>> Olivier
>>
>>
>> _______________________________________________
>> TinyOWS-users mailing list
>> TinyOWS-users at lists.maptools.org
>> http://lists.maptools.org/mailman/listinfo/tinyows-users
>
>
> _______________________________________________
> TinyOWS-users mailing list
> TinyOWS-users at lists.maptools.org
> http://lists.maptools.org/mailman/listinfo/tinyows-users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.maptools.org/pipermail/tinyows-users/attachments/20120229/5c36e254/attachment.htm
More information about the TinyOWS-users
mailing list