[TinyOWS-users] Problem inserting features
Brian May
bmay at mapwise.com
Mon Sep 19 19:29:09 EST 2011
Carlos, Rahkonen and Oliver,
Thank you for your quick response!
Carlos - I checked to make sure 900913 was in the spatial_ref_sys table
and its there. I have split up my software stack and am using
apache/tinyows in regular cgi mode + postgres with the test data on the
linux machine for now.
Rahkonen - I have been able to get working view, insert, delete the
France data and my custom data table via QGIS 1.6 on Windows by
switching part of the software stack to the linux machine. I haven't
tested the OpenLayers example using this current config yet. Still
working on getting my custom data to work withthe OL test utilizing the
OL Transactional tutorial on the tinyows site.
I am using the OSGeo Live Version 5 virtual machine for Virtual Box.
That has worked really well, but some software required for this was
missing or outdated. For example, tinyows was version 0.9, and in order
to compile from source, I needed the libxml2-dev package, and flex was
missing. Postgres is 8.4 and I left it at that. Postgis is 1.5.2.
Interesting that the demo worked using OSGeo4W with some updates. Thanks
for the tip on feature ids for inserts.
Oliver - see inline comments below:
On 9/19/2011 5:53 PM, Olivier Courtin wrote:
> On Mon, Sep 19, 2011 at 10:22 PM, Brian May<bmay at mapwise.com> wrote:
>> Getting TinyOWS to work has been a long and winding road - still no success
>> - and almost ready to give up. Here's the latest on what I have tried and
>> the results.
>>
>> I ended up trying it out on linux and got further down the road, but
>> different problems. I compiled it from source from SVN. I can insert
>> features via QGIS and OpenLayers now, but the inserted features do not have
>> any geometry (confirmed via checking out the table in postgres). And I can
>> see existing features in QGIS that I manually added via a direct connect to
>> postgres, but not in OpenLayers! I have been running down a lot of rabbit
>> holes trying to get this figured out, burning a lot of time and I could
>> really use some help.
> Naive question but do you use a PostGIS version>= 1.5.0 ?
Yes, "POSTGIS="1.5.2" GEOS="3.2.2-CAPI-1.6.2" PROJ="Rel. 4.7.1, 23
September 2009" LIBXML="2.7.8" USE_STATS"
>
> If so i suggest that you follow strictly the existing tutorial,
> http://tinyows.org/trac/wiki/OpenLayersHowToTransactional
>
> What happen then ?
I did with the pure windows stack which used tinyows 1rc3, and that is
when I was getting "premature end of script headers" on inserts.
>
> Then use a QGIS>= 1.6 as a WFS-T client,
> same question what behaviour ?
Yes, with QGIS, getting same behavior on inserts using the pure Windows
stack. Now, using the trunk version of tinyows on linux, QGIS does
everything fine.
>
>
>> Also, I may have found a few bugs in the process. For example, if you have
>> two geometry columns in your table, and do not inform tinyows of the
>> additional geometry column via the config file, it produces a 500 error when
>> testing from the browser.
> There's no need (and so no way) to indicate to TinyOWS if a column is a geometry
> or not (it used geometry/geography column table/view to do so)
>
> So i'm curious about how you are exactly able to obtain a HTTO 500 error type.
OK, OpenLayers has a parameter for the geometry column, so I thought it
may mean something to tinyows. I just realized i am using OL 2.11rc4, so
will try more tests with stable 2.11.
// Open Street Map - Default
var OSM = new OpenLayers.Layer.OSM("OpenStreetMap");
// WFS
var saveStrategy = new OpenLayers.Strategy.Save();
wfs = new OpenLayers.Layer.Vector(
"Custom Lines TEST", {
strategies: [new OpenLayers.Strategy.BBOX(), saveStrategy],
projection: new OpenLayers.Projection("EPSG:900913"), //
projection of the data - wfs 1.1.0 supports server-side projection
protocol: new OpenLayers.Protocol.WFS({
srsName: "EPSG:900913", // output projection
version: "1.1.0",
url: "http://192.168.2.105:9091/cgi-bin/tinyows",
featureNS: "192.168.2.105:9091/",
featureType: "saunders_lines",
featurePrefix: "feature",
geometryName: "the_geom",
schema:
"http://192.168.2.105:9091/cgi-bin/tinyows?service=wfs&request=DescribeFeatureType&version=1.1.0&typename=feature:saunders_lines"
}),
visibility: true
});
//wfs = wfsCustomLines;
map.addLayers([OSM, wfs]);
>
>
>> Does tinyows expect the_geom vs. wkb_geometry?
>> Tried both and it seems to operate the same, except when you have them both
>> there at the same time.
> Humm there's no naming convention if that is the question,
> thing meaningfull is the type (geometry or geography so)
>
>> I don't remember if this is in the docs, but you must have a record in the
>> geometry_columns table for tinyows to recognize the layer at all - you can
>> have your config all set up right, and it just won't show the layer as being
>> available.
> Indeed it is a basis rule of PostGIS administration:
> to keep your geometry data sync to geometry_columns table.
>
> populate_geometry_columns() could help so...
>
>> If you change the geometry column name in your table and the geometry column
>> name in the geometry_columns table don't match - doing ./tinyows --check
>> produces the following error:
>> row number 0 is out of range 0..-1
>> tinyows: src/struct/buffer.c:254: buffer_add_str: Assertion `str' failed.
>> Aborted
> PostGIS 2.0 will avoid this as now geometry_column becoming a View
> and forbid the database admistrator to unsync datas and metadatas.
>
> A fix was commited as r615 for previous version.
> Should be better now.
OK. I had manually copied over table defs and data and forgot to
properly configure the geometry_columns record when I received errors
related to that. For example, first, the record for the table wasn't
there, that is when the layer failed to show running tinyows --check.
When I put the wrong geometry column name (like if you manually register
the table), that is when I got the Assertion 'str' failed error. I think
that when I had the geometry column named wrong and tried accessing
tinyows via URL is when I got the 500 error. I'll do more testing. So, I
was making mistakes along the way not quite knowing what the problem was
until I carefully reviewed the data configuration. Sounds good on the
PostGIS 2.0 change.
>
>> Is there any reason why having your data in 900913 projection would be a
>> problem? Wasn't my first choice, but I figured i could eliminate projection
>> problems that way since the map is in 900913.
> As long as your srid is rightly set in sptail_ref_sys table,
> it should not be a specific issue for TinyOWS
>
> Cf Carlos answer,
>
>> Also, not sure why, but after some change I made, the url
>> http://myurl/cgi-bin/tinyows?service=WFS&request=DescribeFeatureType&version=1.1.0&
>> is producing a much more terse output than before. Haven't figured out what
>> it is yet, although if I take out my custom layer, and just have the france
>> demo, the verbose output comes back.
>>
>> If its easier to help debug this, I can open it up to the outside world
>> temporarily.
> If you give me enough information to reproduce it,
> i can go on, but right not yet the case.
>
OK, sounds like the OpenLayers problem may be on the OpenLayers side now
that QGIS is working correctly.
Also, since tinyows is just a cgi program, there is no effect on the
tinyows config by restarting Apache, right? And tinyows reads the
tinyows.xml file every time its called, right?
I'll keep banging away at it and keep you posted. One thing I may be
able to help with in the end is some kind of trouble-shooting tips.
Seems like I've hit about as many pitfalls as you can. There are a lot
of good references in the mailing list archives, but its a bit
scattered. If you like I'll volunteer to help organize some of that into
the main site. I am really excited about the promise of this software,
especially WFS-T via OpenLayers.
Thanks for all your help,
Brian
More information about the TinyOWS-users
mailing list