[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Maposmatic-dev] [PATCH] Make the computation of the city contours m
Re: [Maposmatic-dev] [PATCH] Make the computation of the city contours more robust
Fri, 11 Sep 2009 20:01:36 +0200
Thunderbird 126.96.36.199 (X11/20090817)
-----BEGIN PGP SIGNED MESSAGE-----
This code parsed the result of a postgis query in order to determine the
"contour" of a city (ie. the area we are greying on the map), making
this grey area larger so that it would go outside of the paper (ie.
beyond the city bbox used to render).
The original code was expecting that the db query would always result in
a 1x1 table whose contents would be a POLYGON((outside),(inside)) wkt.
Unfortunately, the db can reply None (or [None] ?) sometimes, and in
that case the code would crash. I didn't dig further into observing why
we can determine the city bbox and not its contour.
Anyway, we then needed to parse this "outside" string to derive a larger
outside contour in order for the grey area to cover the whole paper
correctly (ie. go beyond the rendering limits). For that, the original
code would make the assumption that the "outside" string above would be
a simple wkt square, ie. a bbox... which was the case in all our tests,
but is not always the case. Sometimes, that area had 6 coords, maybe
more. So the regex I used to retrieve the min/max corners of the area
was simply not matching the query result. The best fix would have been
to use the right query to enlarge the contour directly from sql. But I
chose the basic path: derive the bbox by hand from the points we have,
and recreate the larger contour wkt.
David Decotigny -- http://david.decotigny.fr
Fingerprint: 54A6 7EC5 868D 98C8 8C8C 1BD1 95DE EF86 EB15 AC21
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----