Matt Amos wrote:
> if the object is new then the version number won't help - a new object
> will be created from the placeholder ID in each time.
That's true in theory, but in practice, the freaking-out usually
happens on the "deleting unshared nodes" bit, which doesn't apply in
the case of a
Matt Amos wrote:
> On Fri, Apr 10, 2009 at 5:39 PM, Frederik Ramm wrote:
>> Matt Amos wrote:
>>> if the object is new then the version number won't help - a new object
>>> will be created from the placeholder ID in each time.
>> Right. What Richard meant was probably that the new server with all t
On Fri, Apr 10, 2009 at 5:39 PM, Frederik Ramm wrote:
> Matt Amos wrote:
>>
>> if the object is new then the version number won't help - a new object
>> will be created from the placeholder ID in each time.
>
> Right. What Richard meant was probably that the new server with all those
> blinkenligh
Hi,
Matt Amos wrote:
> if the object is new then the version number won't help - a new object
> will be created from the placeholder ID in each time.
Right. What Richard meant was probably that the new server with all
those blinkenlights and Postgres goodnes will be so blindingly fast that
thos
On Fri, Apr 10, 2009 at 4:41 PM, Richard Fairhurst wrote:
> Thomas Wood wrote:
>
>> Are you sure API0.6 will solve this situation? In this case all the
>> ways share the same two nodes and are exactly the same tagging. 0.6
>> does not aim to solve this issue afaik.
>
> AIUI the versioning will sol
Thomas Wood wrote:
> Are you sure API0.6 will solve this situation? In this case all the
> ways share the same two nodes and are exactly the same tagging. 0.6
> does not aim to solve this issue afaik.
AIUI the versioning will solve it. This looks awfully like the usual
slow-server situation to
2009/4/10 Richard Fairhurst :
>
> Kenn Sebesta wrote:
>> What can be done to catch and eliminate all these duplicate ways?
>
> API 0.6.
Are you sure API0.6 will solve this situation? In this case all the
ways share the same two nodes and are exactly the same tagging. 0.6
does not aim to solve this
Kenn Sebesta wrote:
> What can be done to catch and eliminate all these duplicate ways?
API 0.6.
cheers
Richard
--
View this message in context:
http://www.nabble.com/Duplicates-in-planet.osm-tp22985194p22988599.html
Sent from the OpenStreetMap - Dev mailing list archive at Nabble.com.
_
Kenn Sebesta wrote:
> Two questions:
For people start wondering; this user is not a clone of me!
Stefan
___
dev mailing list
dev@openstreetmap.org
http://lists.openstreetmap.org/listinfo/dev
While processing osm files, I'm finding lots of duplicates. For instance,
25704836
25704850
25705008
25705398
25705403
25705465
25705466
25705467
25705474
25705478
25705480
25705481
25705482
25705649
25705655
25705656
25705657
25705659
25705660
25705668
25705674
25705683
all seem to be the same (
10 matches
Mail list logo
