[Featureserver] Assorted problems

Christopher Schmidt crschmidt at metacarta.com
Fri Mar 27 07:38:49 EDT 2009


On Fri, Mar 27, 2009 at 09:31:09AM +0000, Peter Robins wrote:
> I've been trying out featureserver; it worked fine with small amounts of test 
> data, but I've been having a frustrating time trying to get it to work with 
> real data.
> 
> 1. trying to load kml data with whitespace, such as
>     <LineString>
>       <coordinates>
>         -1.619196,42.963177,0.000000
>         -1.617908,42.961761,0.000000
>         -1.616836,42.960506,0.000000 . . .
> -> Unable to determine bounding box for feature with geometry 
> {'type': 'Line', 'coordinates': [[u'-1.619196', u'42.963177', u'0.000000'], 
> [u''], [u''], [u''], [u''], [u''], [u''], [u''], [u'-1.617908', u'42.961761', 
> u'0.000000'], [u''], [u''], [u''], [u''], [u''], [u''], [u''] ......
> so seems not to be ignoring whitespace.

You're trying to upload KML data? If so, yes, it seems that this is not
supported. Patches welcome.

> 2. querying e.g. "?queryable=title&title=Trinidad" doesn't work; something to 
> do with utf8 data in the field you're querying?
>   'ascii' codec can't encode character u'\xe9' in position 12: ordinal not in 
> range(128)
> ...
>   File "/var/www/cgi-bin/FeatureServer/DataSource/DBM.py", line 108, in select
>     (key in props and str(props[key]) != val):

Yeah, using 'str' like that is a bug. Should be str(props[key],
"utf-8"). If you test that and it works, give me a patch and I'll apply
it. 

> 3. on homepage, under "To set up your own FeatureServer:" says
> echo '{"id":1, "geometry":{"type":"Point", "coordinates":[[0,5]]}}' | curl -d 
> @- http://example.com/cgi-bin/featureserver-/featureserver.cgi/all.gml
> 
> This is wrong, isn't it? Surely the suffix on the server call should match the 
> datasource, so should be 
> http://example.com/cgi-bin/featureserver-/featureserver.cgi/layer/all.json 
> (and gml is read only). 

Correct, that is a mistake.     

> On the other hand, it doesn't seem to matter what 
> goes before the suffix; even using .../featureserver.cgi/layer/delete.json 
> will add the feature

Correct, any non-integer there behaves the same.

> 4. I'd suggest a global replace Berkley -> Berkeley on both programs and 
> website. This is not just being pedantic. For example, 
> http://featureserver.org/doc/DataSources.html says:
> "A sample BerkleyDB configuration might look like:
> [scribble]
> type=BerkleyDB"
> This won't work. There is no such datasource. (Not that BerkeleyDB works 
> anyway; still a problem even in trunk "'BerkeleyDB' object has no 
> attribute 'unique'".)

I think this means that a global removal of BerkeleyDB is in order.
Done.

> 5. What's the status with trunk? I tried a checkout, thinking it might solve 
> some of these issues, but it does not seem to be complete; for example, 
> FeatureServer/Feature/ is missing. So looks like it hasn't been tested very 
> much.

FeatureServer/Feature.py no longer exists in trunk; it is moved into
vectorformats/Feature.py (and it is there and works).

> 6. For completeness, http://featureserver.org/doc/DataSources.html could do 
> with an SQLite example:
> 
> [myfeatures]
> type=SQLite
> file=/home/example/features.sqlite

Updated in svn.

-- 
Christopher Schmidt
MetaCarta



More information about the Featureserver mailing list