[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: "",
                 featureNS: "",
                 featureType: "saunders_lines",
                 featurePrefix: "feature",
                 geometryName: "the_geom",
             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,


More information about the TinyOWS-users mailing list