[postgis-users] Failing hstore query

[Zenon Panoussis]

> Looks fine to me. Which brings me to couple of troubleshooting questions:

There's a rule of thumb that when something that should work
doesn't and you've checked everything, the error is caused by
some really silly thing that you forgot to check. So now I've
really looked everywhere - or so I think. Is mapnik really using
the style.xml that I think it's using? Yes, doublechecked, and
the postgres log confirms it. Could I have forgotten tiles from
a previous run that prevented the generation of new tiles? No,
I was watching the script make them, but I rm -rf'ed tiles and
started over again anyway and then checked the file dates just
to be 200% pedantic. Am I really displaying my freshly created
tiles? Yes, I made a fresh map at a new location, Could my
browser cache be playing games with me although I emptied it?
Looking at the tiles with an image viewer says no.

> 1) Have you tried running mapnik query? To confirm it is including maritime
> boundaries -- I don't see how it could be.  

I hadn't, but now I have. Copy/pasted the query of a tile with
unwanted borders from the postgres log, dumped output to a file,
grepped for maritime, found none.

> 3) Is it possible your maritime border is being drawn by another layer
> query?

I checked the three shp files that I'm including and none of them
contain any country borders.

***

I wrote the above last night, then kept barking up all the wrong
trees all day today, until finally I did what I should have done
from the very beginning: I added TextSymbolizer: osm_id to the
admin border lines to find out where they come from. Turns out
there are two borders for each country.

I put the result at http://www.provocation.net/tmp/mb/maritimeborders.html
I'm adding the numbered lines to zoom level 7 and I might add
them to ZL8 too.

This doesn't really belong here any more, but please bear with
me since it's well worth documenting and the thread begun here.

Using Ireland as example, it is surrounded by rendered maritime
border -62273. That's a collection of rows that look like this:

osm_id   boundary         admin_level   tags
-62273 | administrative | 2           | "flag"=>"http://upload.wikimedia.org/wi
kipedia/commons/4/45/Flag_of_Ireland.svg", "name:af"=>"Ierland", "name:ak"=>"Aer
eland", "name:am"=>"አየርላንድ", "name:an"=>"Irlanda" <snipped>

The tags do not include maritime=yes and that's what's causing my
problem.

I already knew from osm that this very same border is made up of
several ways, all of which are properly tagged maritime=yes:

https://www.openstreetmap.org/way/129305263
https://www.openstreetmap.org/way/131493799
https://www.openstreetmap.org/way/144387894 etc

The negative osm_id in my database was created by osm2pgsql and
should be just the sign-inverted original osm_id. Indeed it is,
but the OSM original is a relation, not a way:

<relation id="62273" visible="true" version="284" changeset="26878562"
timestamp="2014-11-19T02:22:57Z" user="Matt1993" uid="1891499">

In OSM, all the ways that are tagged maritime=yes are members of
this relation. osm2pgsl fed the relation to postgres as a way,
which now lives in the database next to its own members. *That*
is what creates two sets of borders, one correctly tagged and
the other not. And that is why grepping for maritime in the
mapnik query output found nothing, when I was expecting either
that it would find something or that the maritime borders wouldn't
be rendered.

Remains to figure out how to fix this. Deleting the offending
ways from the database might leave all countries nameless. Just
adding a tag 'norender=>"borders"' is probably the preferred
quick n' dirty hack.

Z