Julison [EMAIL PROTECTED] writes:
In what situation would it be necessary use duplicate keys? If there's a
need, can we reach the same goal without using it? I think duplicated keys
can lead to database problems (e.g. performance) that can be avoid.
A highway can have multiple refs (A11 could
Am Donnerstag, den 09.10.2008, 22:48 +0100 schrieb Shaun McDonald:
However they will still be in the history. Which need to be
converted
too in the api change.
Changing the history is a questionable thing to do. A history should IMHO
accurately reflect what has been.
Sincerely,
Joachim
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Matthias Julius schreef:
Julison [EMAIL PROTECTED] writes:
In what situation would it be necessary use duplicate keys? If there's a
need, can we reach the same goal without using it? I think duplicated keys
can lead to database problems (e.g.
Stefan de Konink [EMAIL PROTECTED] writes:
- I assumed that editors like JOSM, and their behavior was consistent
and there is absolutely no useful use of duplicate keys.
Actually, the editors are pretty consistent in not supporting
duplicate keys, but that doesn't mean that this wouldn't be
In what situation would it be necessary use duplicate keys? If there's a
need, can we reach the same goal without using it? I think duplicated keys
can lead to database problems (e.g. performance) that can be avoid.
Julison.
2008/10/10 Matthias Julius [EMAIL PROTECTED]
Stefan de Konink [EMAIL
On Thu, Oct 9, 2008 at 2:58 AM, Stefan de Konink [EMAIL PROTECTED] wrote:
Allowed via the 0.5 API currently: Yes.
Supported by any of the editors: No (AFAIK)
On a hunch, don't expect the 0.6 API to support duplicates.
Then disable *ANY* edits with this borked editor: Potlatch 0.10c and
On Thursday 09 October 2008 16:06:39 Andy Allan wrote:
(I think Grant said this bit, it's lost its context)
Allowed via the 0.5 API currently: Yes.
Supported by any of the editors: No (AFAIK)
I could swear I explicitly read endorsement of duplicate keys on the
documentation somewhere, but
Stefan de Konink wrote:
Then disable *ANY* edits with this borked editor: Potlatch 0.10c and
revert back to a version that did not produce duplicates.
Er, hate to rain on your parade, but if you'd actually have taken
0.1us to look, you'd see that Potlatch 0.10c has already been
be driving the format of the database, not the other way around.
Cheers
Andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Hugh Barnes
Sent: 09 October 2008 7:35 AM
To: dev@openstreetmap.org
Subject: Re: [OSM-dev] way 7062297, is this new?
On Thursday
On Thu, Oct 09, 2008 at 04:34:37PM +1000, Hugh Barnes wrote:
Spurred on by this, I tried it in Merkaartor. The UI accepted my input and I
assumed all was good. I just remembered to follow this up and it appears the
data didn't make it. Possibly the last occurrence of the tag in the app was
On Thursday 09 October 2008 18:56:42 Andy Robinson (blackadder-lists) wrote:
Duplicate keys were perfectly valid
then and indeed I recall we discussed how we might use duplication for
tagging purposes. It was only the lack of support in the editors that
stopped duplication in its tracks.
OK,
especially for you, google invented 'mail goggles':
http://gmailblog.blogspot.com/2008/10/new-in-labs-stop-sending-mail-you-later.html
no seriously: stefan is a nice guy and he made a valid point here.
i am also really amazed this is possible. but imo we should blame the api,
not potlatch.
On Thu, Oct 9, 2008 at 2:31 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
If 0.6 is not supporting it, it should not be possible to enter the data
today. (imho)
lets do a 0.5.5 release with this fix in. hmm, we should include
referential integrity as well, since that can cause similar types of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Matt Amos schreef:
we're working on it and it'll be ready as soon as its ready. if you'd
like to help then that would be fantastic.
If you don't mind I'll implement a 0.6 api in my own server ;)
imho, the most likely place to look for the error
suggest you use
one of the workarounds suggested for your own work.
Cheers
Andy
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Stefan de Konink
Sent: 09 October 2008 2:59 AM
To: Grant Slater
Cc: OSM-Dev Openstreetmap
Subject: Re: [OSM-dev] way 7062297
On Thursday 09 October 2008 19:02:44 Andy Robinson (blackadder-lists) wrote:
Points noted Hugh but in reality it's probably easy enough to find
alternative solutions to these tagging questions.
+1
Since duplicate keys in
the current data have essentially been legacy data or input errors of
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Stefan de Konink schreef:
you'll notice that JMEditor, whatever that is, is responsible for
the node errors. and all the way errors are duplicates, so there is
never a conflict in reducing them. if you'd like to fix these then
that would be
Ian Dees [EMAIL PROTECTED] writes:
On Wed, Oct 8, 2008 at 9:35 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
No way! The database[1] uses indexing under the hood automatically. So
every created_by k or JOSM v is automatically indexed. This gives a
significant space reduction plus fast
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Matthias Julius schreef:
Or make it a normal index instead of a primary key. Then you can have
duplicates.
The database I am using does this under the hood already. The constraint
I have implemented was because:
- - I have an update algorithm
Hugh Barnes [EMAIL PROTECTED] writes:
I'd be curious to see if anyone else sees a need. I find delimited strings
inherently unsatisfactory to work with, so I also wonder if there are any
other workarounds that we could at least recommend?
Multiple values for a tag is certainly useful and
Hugh Barnes [mailto:[EMAIL PROTECTED] wrote:
Sent: 09 October 2008 1:08 PM
To: dev@openstreetmap.org
Cc: Andy Robinson (blackadder-lists)
Subject: Re: [OSM-dev] way 7062297, is this new?
On Thursday 09 October 2008 18:56:42 Andy Robinson (blackadder-lists)
wrote:
Duplicate keys were perfectly
Andy Robinson (blackadder-lists) wrote:
But then
again since it's been pointed out that only 35 current cases exist and I
exist_ed_
I have it on good authority that all those cases have been eradicated by
now.
--
Lennard
___
dev mailing list
On 9 Oct 2008, at 22:20, Ldp wrote:
Andy Robinson (blackadder-lists) wrote:
But then
again since it's been pointed out that only 35 current cases exist
and I
exist_ed_
I have it on good authority that all those cases have been
eradicated by
now.
However they will still be in the
Stefan de Konink wrote:
..
tag k=AND_nosr_r v=15457132/
tag k=AND:importance_level v=5/
tag k=AND_nosr_r v=15457132/
..
tag k=AND:importance_level v=5/
...
Could anyone *please* elaborate since when this is possible? (Look at
the duplicate keys.)
If this is /just allowed/ it fubars my
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Grant Slater schreef:
Stefan de Konink wrote:
..
tag k=AND_nosr_r v=15457132/
tag k=AND:importance_level v=5/
tag k=AND_nosr_r v=15457132/
..
tag k=AND:importance_level v=5/
...
Could anyone *please* elaborate since when this is possible?
On Wed, Oct 8, 2008 at 9:16 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
It is even my primary key {wayid, k}. If you can explain me how a
k='name' can ever have a duplicate that is meaningful, please enlighten me.
Why do you include the tag's key with the primary key? The only primary key
On Wed, Oct 8, 2008 at 9:27 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
I have a way table, that has a primary key {wayid}. The table way_tags
point to that wayid.
Do you ever do a lookup by tag key name? If not, then you don't need to
normalize the tags into their own table like that, just
On Wed, Oct 8, 2008 at 9:35 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
No way! The database[1] uses indexing under the hood automatically. So
every created_by k or JOSM v is automatically indexed. This gives a
significant space reduction plus fast lookup.
Next to that it is very easy
On Thu, Oct 9, 2008 at 1:44 PM, Ian Dees [EMAIL PROTECTED] wrote:
On Wed, Oct 8, 2008 at 9:35 PM, Stefan de Konink [EMAIL PROTECTED] wrote:
No way! The database[1] uses indexing under the hood automatically. So
every created_by k or JOSM v is automatically indexed. This gives a
significant
29 matches
Mail list logo
