Richard Fairhurst wrote:
Don't bother, I hope to be committing the fix this evening.
It's committed and live now - will be interested to hear if it fixes the
issue for Linux FP users.
cheers
Richard
--
View this message in context:
2009/7/16 Frederik Ramm frede...@remote.org
Hi,
Shaun McDonald wrote:
Yes you can do it, though I don't have a good reason for doing such a
thing.
I don't have an idea where one would add a relation as a member to itself,
but circular references could e.g. happen if you were to create a
2009/7/16 Matt Amos zerebub...@gmail.com
On Thu, Jul 16, 2009 at 10:41 AM, Chris Browetc...@semperpax.com wrote:
2009/7/16 Frederik Ramm frede...@remote.org
Chris Browet wrote:
I'd be curious to know how the api calculates the bounding box of such
a
relation
On 16/07/09 11:55, Richard Fairhurst wrote:
Roland Olbricht wrote:
The letters Ä, Ö, Ü, ß don't work at all.
When you say don't work at all, what happens? Do they vanish, or do the
wrong characters stay around, or...?
Your test app says, for Ä:
Flash stores: c3 20 1e
Server received: C3 83
Tom Hughes wrote:
Your test app says, for Ä:
Flash stores: c3 20 1e
Server received: C3 83 E2 80 9E
Now Ä is 0xc4 in 8859-1 which encodes to UTF-8 as 0xc3 0x84 so
something is going wrong at the first stage still.
Right.
0x201E is Unicode for „ (double low-9 quotation mark).
„ is 0x84
Steve Hosgood wrote:
I'm getting better results. The only unicode characters needed for
Welsh are the vowels with circumflexes.
I've tested all those that occur (â, ô, w^, y^) and they all seem ok.
Cursor works OK, deleting and backspacing seem right too.
Thanks, Richard.
I do notice a
Hi Y'all,
First, does anyone know the ongoing status of the coastline error
checker? The error check appears not to have run on newer data than
May, and the wiki page indicates no contact since June. Does anyone
know either what the status of the error checker is or who to contact
about it?
Ben Supnik wrote:
First, does anyone know the ongoing status of the coastline error
checker? The error check appears not to have run on newer data than
May, and the wiki page indicates no contact since June. Does anyone
know either what the status of the error checker is or who to
The OSM protocol specifies that it accepts UTF-8 data, but in reality
it only accepts the subset of UTF-8 that the XML parser being used
doesn't barf on, see:
http://lists.openstreetmap.org/pipermail/dev/2009-July/016165.html
This issue surfaces e.g. here:
Hi,
Lennard wrote:
Second, a technical question: from what I read, Mapnik does not yet
support multipolygons.
Sure it does, just not every iteration of the 'advanced multipolygon'
that's described on the wiki page. A basic 'area with holes in it' works
just fine.
Has the bug where
Hi Lennard,
Lennard wrote:
The maintainer has been contacted weeks ago, but the server it ran on
(hypercube) was then still down. I don't know the current status, and
whether he has looked into it.
Sure it does, just not every iteration of the 'advanced multipolygon'
that's described on
On Thu, Jul 16, 2009 at 7:07 PM, Ævar Arnfjörð
Bjarmasonava...@gmail.com wrote:
The OSM protocol specifies that it accepts UTF-8 data, but in reality
it only accepts the subset of UTF-8 that the XML parser being used
doesn't barf on, see:
Frederik Ramm wrote:
Has the bug where osm2pgsql would break these in --slim mode (when
adding updates) been fixed?
I believe some of the issues have been fixed a little while ago, but
I'll leave it to the osm2pgsql maintainers to give a definitive answer.
--
Lennard
2009/7/16 Chris Browet c...@semperpax.com:
2009/7/16 Frederik Ramm frede...@remote.org
Chris Browet wrote:
I'd be curious to know how the api calculates the bounding box of such a
relation
http://wiki.openstreetmap.org/wiki/OSM_Protocol_Version_0.6#Bounding_box_computation
assuming the api
In article 7ec79eed0907160140t2c1b9ffdmc64c27d7aca67...@mail.gmail.com
c...@semperpax.com writes:
I'd be curious to know how the api calculates the bounding box of such a
relation, assuming the api definition is the smallest bbox containg all
children bbox'es.
Trapi handles this by keeping a hash
2009/7/15 Mikel Maron mikel_ma...@yahoo.com:
From discussion about linkedgeodata.org/ on geowanking...
From: Sean Gillies sean.gill...@gmail.com
To: geowank...@geowanking.org
I'm skeptical about RDF too, but the linked geodata folks are adding some
extra value (at least for a particular
Hi list,
in Taiwan we have the situation, that street names may be too long to be
rendered on the map. In addition, we'd like to keep the map bilingual
(Chinese, Romanized/English), which makes the names rendered on the map
even longer. How can we give the renderer some hints how to abbreviate
I've actually been thinking of suggesting an :abbr suffix key to all
name-accepting tags (name, name:en, name:fr, alt_name, int_name, etc.) and
the values are a semicolon-separated list of abbreviations. This is
backwards compatible since existing tools can still use the base name tags
and ignore
On Fri, Jul 17, 2009 at 5:33 AM, Eugene Alvin Villarsea...@gmail.com wrote:
I've actually been thinking of suggesting an :abbr suffix key to all
name-accepting tags (name, name:en, name:fr, alt_name, int_name, etc.) and
the values are a semicolon-separated list of abbreviations. This is
Hi,
Frederik Ramm wrote:
I have committed a new and rather experimental walking papers plugin.
Mike Migurski has kindly added some parameters to the scan.php page so
that the plugin should now be able to detect the range correctly. It is
still a rough first draft and I'm sure many things can
20 matches
Mail list logo
