On Wed, Jan 28, 2009 at 01:54:57AM +0100, Frederik Ramm wrote:
> Simon Ward wrote:
> > Hash table, or associative array/hash/dictionary? Hash tables have
> > mechanisms to deal with collisions.
>
> A collision in a hash table is two keys sharing the same hash value, not
> two keys being identi
2009/1/28 D Tucny
> 2009/1/28
>
>> On Wed, 28 Jan 2009 00:07:20 +, Simon Ward wrote:
>> > [Moved to dev; followups to dev]
>> >
>> > On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
>> wrote:
>> >> > I think multiple keys with the same name should be allowed for a
>> >> > n
2009/1/28
> On Wed, 28 Jan 2009 00:07:20 +, Simon Ward wrote:
> > [Moved to dev; followups to dev]
> >
> > On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
> wrote:
> >> > I think multiple keys with the same name should be allowed for a
> >> > node/way/relation. AFAIK it's
On Wed, 28 Jan 2009 00:30:01 +, Tom Hughes wrote:
> In practice keys are unique because although the API has never enforced
> uniqueness pretty much every client does because all the clients use a
> hash table of some sort to store tags.
JOSM and Potlatch maybe but not all clients.
Osmosis
On Wed, 28 Jan 2009 00:07:20 +, Simon Ward wrote:
> [Moved to dev; followups to dev]
>
> On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason
wrote:
>> > I think multiple keys with the same name should be allowed for a
>> > node/way/relation. AFAIK it's only the editors that don
Richard Fairhurst wrote:
> Stefan de Konink wrote:
>> Richard Fairhurst wrote:
>>> In what way does Potlatch "screw up the uniqueness", please?
>> http://api.openstreetmap.org/api/0.5/way/24644162/history
>
> does not even begin to be an answer. It could be caused by the bleeding
> phase of the mo
Stefan de Konink wrote:
>Richard Fairhurst wrote:
>> In what way does Potlatch "screw up the uniqueness", please?
> http://api.openstreetmap.org/api/0.5/way/24644162/history
does not even begin to be an answer. It could be caused by the bleeding
phase of the moon for all that tells me. I was hopi
Stefan de Konink wrote:
>Richard Fairhurst wrote:
>> In what way does Potlatch "screw up the uniqueness", please?
> http://api.openstreetmap.org/api/0.5/way/24644162/history
does not even begin to be an answer. It could be caused by the bleeding
phase of the moon for all that tells me. I was hopi
Richard Fairhurst wrote:
> Stefan de Konink wrote:
>> Except for editors like Potlatch that use intermediate layers to
>> access the API and screw up the uniqueness.
>
> In what way does Potlatch "screw up the uniqueness", please?
http://api.openstreetmap.org/api/0.5/way/24644162/history
Stefa
Stefan de Konink wrote:
> Except for editors like Potlatch that use intermediate layers to
> access the API and screw up the uniqueness.
In what way does Potlatch "screw up the uniqueness", please?
Richard
--
View this message in context:
http://www.nabble.com/Re%3A--OSM-talk--Handling-of-tow
Hi,
Simon Ward wrote:
> Hash table, or associative array/hash/dictionary? Hash tables have
> mechanisms to deal with collisions.
A collision in a hash table is two keys sharing the same hash value, not
two keys being identical.
Bye
Frederik
--
Frederik Ramm ## eMail frede...@remote.org
Tom Hughes wrote:
> In practice keys are unique because although the API has never enforced
> uniqueness pretty much every client does because all the clients use a
> hash table of some sort to store tags.
Except for editors like Potlatch that use intermediate layers to access
the API and screw
On Wed, Jan 28, 2009 at 12:30:01AM +, Tom Hughes wrote:
> In practice keys are unique because although the API has never enforced
> uniqueness pretty much every client does because all the clients use a
> hash table of some sort to store tags.
Hash table, or associative array/hash/dictionary
On Wed, Jan 28, 2009 at 12:18 AM, Stefan de Konink wrote:
> Simon Ward wrote:
>>> I think that leaves us with an unoptimal situation where editors
>>> either have to shove things into the same key delimited by some token
>>> like ";" as is currently recommended but AFAIK not supported by any
>>> r
Simon Ward wrote:
> Ok, pulling up the wiki page on API 0.6[1] I see that the plan is “to
> create an unique index on the combination of object id and tag key”.
> Presumably this is mainly for performance. An index doesn’t have to be
> unique though—is this a limitation of MySQL or is there some
On Wed, Jan 28, 2009 at 01:18:53AM +0100, Stefan de Konink wrote:
> > Is using different keys (when they’re likely to be unknown to the
> > renderers) or multiple tags with the same key name any better supported
> > in the renderers?
>
> The most logical way of tagging is still using the xml names
On Wed, Jan 28, 2009 at 12:07:20AM +, I wrote:
> Presumably this is mainly for performance. An index doesn’t have to be
> unique though—is this a limitation of MySQL
To answer myself: It’s not a limitation of MySQL.
> or is there some other reason to enforce uniqueness?
Simon
--
A complex
Simon Ward wrote:
>> I think that leaves us with an unoptimal situation where editors
>> either have to shove things into the same key delimited by some token
>> like ";" as is currently recommended but AFAIK not supported by any
>> renderer (or any tool?), or to put what's logically the same data
[Moved to dev; followups to dev]
On Tue, Jan 27, 2009 at 10:58:25PM +, Ævar Arnfjörð Bjarmason wrote:
> > I think multiple keys with the same name should be allowed for a
> > node/way/relation. AFAIK it's only the editors that don't currently let
> > you do this.
>
> Yes, the API and data fo
There is also a proposal here [1] for a stroke-border attribute which
would allow this to be done is one style:
[1] http://trac.mapnik.org/ticket/51
Dane
On Jan 27, 2009, at 3:32 AM, Ed Loach wrote:
Ivo wrote:
minor-roads
minor-roads-casing
5 000
1 000
☡
([highway] = 'secondary'
Ivo wrote:
minor-roads
minor-roads-casing
5 000
1 000
☡
([highway] = 'secondary' or [highway] =
'secondary_link') and not ([tunnel]='yes' or [tunnel]='true')
CSS:
stroke: #a37b48 stroke-dasharra
Ivo,
Casing is the border of the road, whereas the fill is the colour in the centre.
You’ll see that these are two overlapping lines, with the casing slightly wider
than the fill, such that just either edge shows through once the fill is drawn
on top.
Cheers,
Gregory
From: dev-bo
On Tue, Jan 27, 2009 at 11:43:29AM +0100, Dirk Stöcker wrote:
> On Tue, 27 Jan 2009, Marko Mäkelä wrote:
>
> >Recently, I started contributing to OpenStreetMap. I would like to
> >contribute to JOSM as well. To start, I wanted to improve some Finnish
> >translations. However, I noticed a few pr
Hi,
The nicest way I know is using some xslt from here:
https://lists.berlios.de/pipermail/mapnik-users/2008-June/000986.html
This produces a neatly formatted page listing all the layers, styles
and
rules with min/max zooms and mouse-overs with details of css
parameters
etc.
I took a clo
24 matches
Mail list logo
