colliar wrote:
>
>You did replace a way with a way but not a node with a way !
Of course.
It should be obvious that the ID of a node cannot be transformed into
the ID of a way.
Using "replace geometry" on a existing node and a new way is the
easiest way to make the existing node part of the new w
On 11.05.2013 04:19, malenki wrote:
> colliar wrote:
>
>> Am 05.05.2013 05:26, schrieb malenki:
>>
>>> The tool "replace geometry" exists - at least for JOSM. It even works
>>> on "replacing" an old (existing) Node for a new way.
>>
>> Yes it is a nice tool but it only does include the node in the
colliar wrote:
>Am 05.05.2013 05:26, schrieb malenki:
>
>> The tool "replace geometry" exists - at least for JOSM. It even works
>> on "replacing" an old (existing) Node for a new way.
>
>Yes it is a nice tool but it only does include the node in the new way.
>
>E.g. you still have a new object re
> De : Mike
> I guess you are all both right and wrong on this matter and thus because
> you are loking from single angle only.
> [...]
> If object is split, one part preserves existing ID and other parts are
> considered as new objects with new ID's assigned.
Hi
I quite agree with Mike.
P
I guess you are all both right and wrong on this matter and thus because
you are loking from single angle only.
I recognize several different needs:
External link to coordinates
This is simply link to specific geographic coordinates. As it is not
necessarily that there is an object on this c
Am 07.05.2013 12:56, schrieb Stefan Keller:
> 2013/5/7 Peter Wendorff :
>> you would not delete the whole object and add a new object with the
>> building tag alone, right?
>
> I said that it's up to the mapper to decide - as its common in OSM.
> External services which link to this object through
2013/5/7 Peter Wendorff :
> you would not delete the whole object and add a new object with the
> building tag alone, right?
I said that it's up to the mapper to decide - as its common in OSM.
External services which link to this object through the permanent id
have to cope with this.
Yours, Stef
Say the supermarket downsizes and the other half of the building becomes
used by another company. We split the building, creating 1 new building,
glued to the original building. Now there is a 50% chance the existing
building outline continues as the supermarket and 50% it's the new company
continu
Unfortunately I'm too busy to investigate how much elements in OSM
change their meaning instead of deleting the old and creating the new
object.
In addition your "fooling the concept" is not correct. If a supermarket
is abandoned, and was tagged as a building + name + shop=supermarket,
you would n
I'm not proposing to add this as a new tag to OSM objects, but to use
these geoURL in external datasets instead of OSM IDs.
It is a way to keep a (fuzzy) link between datasets.
Fuzzyness seems mandatory at some level as I doubt it is possible to
have an exact match between data models that are co
2013/5/7 Peter Wendorff :
> Look what happens in OSM all the time: POIs are moved slightly to match
> aerial images - following your definition that should be another ID now
No, That's one of the nice properties of ids without coordinates!
To me it would remain the same - except when a tool or the
2013/5/7 Christian Quest :
> Linking to OSM objet ID looks like a bad idea because they are not stable.
Agreed.
> I've proposed something that can be summarized like some generic
> geoURL that could be used to describe something/somewhere in the form
> something@somewhere
Am I understanding you
Am 07.05.2013 09:58, schrieb Stefan Keller:
> Hi,
>
> You wrote:
>> - it's roughly in that bounding box (e.g. the city or a given part of
>
> A soon as you use the word "roughly" - the id approach is doomed to fail.
> According to OO and database technology an id is a well-defined
> surrogate wit
Hi,
You wrote:
> - it's roughly in that bounding box (e.g. the city or a given part of
A soon as you use the word "roughly" - the id approach is doomed to fail.
According to OO and database technology an id is a well-defined
surrogate with a well-defined data type.
Yours, Stefan
2013/5/7 Peter
Linking to OSM objet ID looks like a bad idea because they are not stable.
We had a recent long talk on talk-fr@ about permanent IDs that could
help linking external data to OSM, instead of multiplying ref:xxx in
OSM to link to external data.
I've proposed something that can be summarized like so
Am 07.05.2013 09:43, schrieb Stefan Keller:
> Hi,
>
> All use cases you describe are valid. It's up to the users of OSM
> permanent id to keep track of changing OSM ids - it's an offer of OSM.
> The only constraint I would propose is to avoid to delete and recreate
> a new id only because of a too
Hi,
All use cases you describe are valid. It's up to the users of OSM
permanent id to keep track of changing OSM ids - it's an offer of OSM.
The only constraint I would propose is to avoid to delete and recreate
a new id only because of a tool (like an editor) likes to do it like
this.
The concep
Am 07.05.2013 00:47, schrieb Tobias Knerr:
> Am 06.05.2013 23:55, schrieb Peter Wendorff:
>> Am 06.05.2013 23:07, schrieb andrzej zaborowski:
>>> If you're not adding those historical entities to OSM (or a similar
>>> database like that historical osm once discussed) then there's no
>>> issue with
Hi.
Do you have any idea how this permanent ID could look like?
You dislike the overpass-approach (and yes, it's far from perfect).
What is your idea how a stable permanent ID to an object may be achieved?
Let's use a shop as an example (and wikidata as the foreign database as
an example, too).
Am 06.05.2013 23:55, schrieb Peter Wendorff:
> Am 06.05.2013 23:07, schrieb andrzej zaborowski:
>> If you're not adding those historical entities to OSM (or a similar
>> database like that historical osm once discussed) then there's no
>> issue with linking to Wikidata because there's nothing to be
Hi,
I also think that linking from an OSM object to a growing no. of
external databases (incl. Wikipedia/Wikidata) is not a good idea. And
I respect the wish of the OSM maintainers to change the OSM id in the
future. But the overpass-permanent-osm-id is no solution neither,
primo because a set of
Am 06.05.2013 23:07, schrieb andrzej zaborowski:
> Hi,
>
> On 6 May 2013 21:20, Peter Wendorff wrote:
>> Am 06.05.2013 20:26, schrieb Tobias Knerr:
>>> On 06.05.2013 18:54, Peter Wendorff wrote:
>>>
>>> [...]
Let's see this example: A building that was a merchants kontor a few
hundret y
Hi,
On 6 May 2013 21:20, Peter Wendorff wrote:
> Am 06.05.2013 20:26, schrieb Tobias Knerr:
>> On 06.05.2013 18:54, Peter Wendorff wrote:
>>
>> [...]
>>> Let's see this example: A building that was a merchants kontor a few
>>> hundret years ago, and now contains a museum and a restaurant, while i
Am 06.05.2013 20:26, schrieb Tobias Knerr:
> On 06.05.2013 18:54, Peter Wendorff wrote:
>
> [...]
>> Let's see this example: A building that was a merchants kontor a few
>> hundret years ago, and now contains a museum and a restaurant, while in
>> between it was - let's say - a hospital).
>
> Tha
On 06.05.2013 20:36, Eugene Alvin Villar wrote:
> For those who are not on the tagging mailing list, the wikidata=* tag
> has been proposed[1], and discussed on the tagging mailing list starting
> late February 2013[2]. Based on my assessment of the discussion, there
> doesn't seem to be a clamor t
On Tue, May 7, 2013 at 2:26 AM, Tobias Knerr wrote:
> On 06.05.2013 18:54, Peter Wendorff wrote:
> > Do they have something like a persistent ID in wikidata, yet?
>
> I think the Wikidata page title - something like Q35525 - is intended to
> be rather stable. Of course there are sometimes problem
On 06.05.2013 18:54, Peter Wendorff wrote:
> Do they have something like a persistent ID in wikidata, yet?
I think the Wikidata page title - something like Q35525 - is intended to
be rather stable. Of course there are sometimes problems, such as
duplicates or interwiki conflicts, that make it nece
Do they have something like a persistent ID in wikidata, yet?
Do you want to add dozens of wikidata-tags (or a comma separated value
or something like that), if more than one wikidata-element matches the
osm element.
Let's see this example: A building that was a merchants kontor a few
hundret years
Hello Andreas,
It seems in principle possible to support anchor-links but it was not in
our focus, because our frontend had only one map per article. (You can
believe me the sytem was complex enough ;-)). I will talk about this
topic with my co-creator and the developer of WikiMiniAtlas.
It
Am 05.05.2013 05:26, schrieb malenki:
> On 04.05.2013 15:24, Paul Norman wrote:
>
>> When I get new imagery for the area and re-trace the
>> building depending on what is easiest I may end up creating a new way.
>
> The tool "replace geometry" exists - at least for JOSM. It even works
> on "repl
I made a wikidata tag proposal:
http://wiki.openstreetmap.org/wiki/Wikidata
I think osm --> wikidata is much better than wikidata --> osm. At least
while we don't have a solution for persistent ID's.
Janko
___
talk mailing list
talk@openstreetmap.org
h
On 05.05.13 14:55, Kolossos wrote:
> I don't like to support different reference systems in WIWOSM.
I see the point. But WIWOSM seems not to work with anchor-links:
Neither
http://toolserver.org/~kolossos/openlayers/kml-on-ol-json3.php?lang=de&title=Liste%20der%20denkmalgesch%C3%BCtzten%20Objekte
[Quoting repaired on an (as it seems) accidential PM]
yve...@gmail.com wrote on Sun, 05 May 2013 08:53:04:
> malenki wrote
>>
>>On 04.05.2013 15:24, Paul Norman wrote:
>>
>>> When I get new imagery for the area and re-trace the
>>> building depending on what is easiest I may end up creating a new
Hello Andreas,
to c)
I don't like to support different reference systems in WIWOSM. Each
country has it's own for monuments and than somebody starts with
vulcanos or brigdes We would have to update WIWOSM each week without
the generic system we have now.
Greetings Tim
Am 05.05.2013 11:
Hi guys,
I am most likely the one who started the whole "issue" of adding relation
IDs to Wikipedia at all - I created the Wikipedia templates and inserted
several tenths of relation IDs to specific articles... and you know why?
Because at the time I did that there was no WIWOSM (or any other usab
Tim,
There are different problems, let's keep them separate (vielleicht reden wir
auch - Englisch - aneinander vorbei... ;)
a) There is a problem in the code of osm.org how it links wikipedia articles.
You can't do a link like this:
$PATH#anchor?uselang=en
This is bad URL syntax. You (os
Hello Andreas,
I hope Wikidata part 3 solve the problem with the list, so that an
object would be one Wikidata entry and can be a member in different
lists but can also have an own article.
A map with objects in the example article is here:[1]
I have no influence on the way how
http://www.ope
Tim,
There are problems with WIWOSM that aren't solved at all...
Example: Historic monuments in Austria. They are all covered in Wikipedia, but
mostly only in Lists. And they do have a distinguishable objectID, but I can't
really state this in OSM.
For instance:
http://www.openstreetmap.org/bro
On 04.05.2013 15:24, Paul Norman wrote:
> When I get new imagery for the area and re-trace the
> building depending on what is easiest I may end up creating a new way.
The tool "replace geometry" exists - at least for JOSM. It even works
on "replacing" an old (existing) Node for a new way.
___
> From: Mike [mailto:mike.cuttl...@gmail.com]
> Sent: Saturday, May 04, 2013 1:36 PM
> To: talk@openstreetmap.org
> Subject: Re: [OSM-talk] OSM relation ID property in Wikidata
>
> > I am however concerned that
> > if more people simply assume that the status quo is t
> I am however concerned that
> if more people simply assume that the status quo is there to stay ("IDs
> are stable enough"), this will put pressure on *us* and limit our
> flexibility in the future.
But, what is the point if ID's are not stable?
How can we externally link to the data and make
.@gmail.com]
Sent: Friday, May 03, 2013 2:08 PM
To: Frederik Ramm
Cc: OpenStreetMap
Subject: Re: [OSM-talk] OSM relation ID property in Wikidata
I am less concerned about the Wikidata side - if they make a bad
judgement then it is their mess to clean up. I am however concerned
that if more people
On 4 May 2013, at 10:47, Andrew Gray wrote:
> On 4 May 2013 00:49, Claus Stadler wrote:
>> Hi,
>>
>> Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
>> Wikipedia referring to database identifiers? (The answer is a clear 'yes'
>> from my side.)
>> In fact there are the (w
Hi,
>> Wikidata entities are (with a few caveats) static and
language-independent (eg https://www.wikidata.org/wiki/Q3183), and could
potentially be useful here
I totally agree, so tagging OSM entities with Wikidata IDs (where
applicable) might improve the stability even beyond that of using
On 4 May 2013 00:49, Claus Stadler wrote:
> Hi,
>
> Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
> Wikipedia referring to database identifiers? (The answer is a clear 'yes'
> from my side.)
> In fact there are the (wikipedia, *) tags - but not sure how good the
> quality
Jason Remillard wrote:
However, given what exists today shouldn't Wikipedia be using the
overpass API for referencing OSM?
I'd also say so: There already is a "Permanent ID" [1] service.
http://overpass-api.de/api/interpreter?data=[out:custom];rel[boundary=administrative][admin_level=6][name
Am Samstag, 4. Mai 2013, 02:26:08 schrieb Claus Stadler:
> >> Isn't this thread about pointing from outside to osm?
>
> Yes, so the simple suggestion is for OSM to extend the API to expose the
> wiki tags; something like
>
> Something along the lines of:
> http://www.openstreetmap.org/api/0.6/wi
>> Isn't this thread about pointing from outside to osm?
Yes, so the simple suggestion is for OSM to extend the API to expose the
wiki tags; something like
Something along the lines of:
http://www.openstreetmap.org/api/0.6/wiki/{lang}/{article}
And this would return the corresponding object(s)
2013/5/4 Claus Stadler
> Hi,
>
> Shouldn't OSM use Wikipedia URLs as UUIDs where applicable rather than
> Wikipedia referring to database identifiers? (The answer is a clear 'yes'
> from my side.)
> In fact there are the (wikipedia, *) tags - but not sure how good the
> quality is - what can be s
't Wikipedia be using the overpass API for
referencing OSM?
Thanks
Jason.
On Fri, May 3, 2013 at 6:46 PM, Paul Norman wrote:
From: andrzej zaborowski [mailto:balr...@gmail.com]
Sent: Friday, May 03, 2013 2:08 PM
To: Frederik Ramm
Cc: OpenStreetMap
Subject: Re: [OSM-talk] OSM relation ID propert
t;> From: andrzej zaborowski [mailto:balr...@gmail.com]
>> Sent: Friday, May 03, 2013 2:08 PM
>> To: Frederik Ramm
>> Cc: OpenStreetMap
>> Subject: Re: [OSM-talk] OSM relation ID property in Wikidata
>>
>> > I am less concerned about the Wikidata side - if th
> From: andrzej zaborowski [mailto:balr...@gmail.com]
> Sent: Friday, May 03, 2013 2:08 PM
> To: Frederik Ramm
> Cc: OpenStreetMap
> Subject: Re: [OSM-talk] OSM relation ID property in Wikidata
>
> > I am less concerned about the Wikidata side - if they make a bad
> &
On 3 May 2013 23:22, Frederik Ramm wrote:
> * some objects whose ID had not changed and who had been created by someone
> who rejected the license were nonetheless kept if it could be shown that
> they had been changed in a major way since;
>
> * some objects that had been freshly created by peopl
Am 03.05.2013 23:08, schrieb andrzej zaborowski:
On 3 May 2013 22:58, Frederik Ramm wrote:
On 03.05.2013 22:12, Eugene Alvin Villar wrote:
The consensus was that--at least for place relations which are the
target of the said property--OSM relation IDs are stable enough and any
changes in IDs c
Hi,
On 03.05.2013 23:18, andrzej zaborowski wrote:
I don't understand -- wasn't the entire process based on the
assumption that intellectual property persists as long as the object
ID persists?
No, that is a misconception. During the license change we deviated from
that idea in both direction
On 3 May 2013 23:14, Frederik Ramm wrote:
> On 03.05.2013 23:08, andrzej zaborowski wrote:
>> The OSMF has sent a pretty strong message saying that object IDs are
>> stable enough to base impactful legal decisions on them.
>
> The OSMF has never sent messages saying that object IDs are stable or e
On Fri, May 03, 2013 at 11:08:01PM +0200, andrzej zaborowski wrote:
> On 3 May 2013 22:58, Frederik Ramm wrote:
> > On 03.05.2013 22:12, Eugene Alvin Villar wrote:
> >> The consensus was that--at least for place relations which are the
> >> target of the said property--OSM relation IDs are stable
Hi,
On 03.05.2013 23:08, andrzej zaborowski wrote:
The OSMF has sent a pretty strong message saying that object IDs are
stable enough to base impactful legal decisions on them.
The OSMF has never sent messages saying that object IDs are stable or
even "stable enough" for anything; if you inte
On 3 May 2013 22:58, Frederik Ramm wrote:
> On 03.05.2013 22:12, Eugene Alvin Villar wrote:
>> The consensus was that--at least for place relations which are the
>> target of the said property--OSM relation IDs are stable enough and any
>> changes in IDs can be easily rectified. Wikidata is a wiki
Hi,
On 03.05.2013 22:12, Eugene Alvin Villar wrote:
The consensus was that--at least for place relations which are the
target of the said property--OSM relation IDs are stable enough and any
changes in IDs can be easily rectified. Wikidata is a wiki after all.
I am less concerned about the Wik
On Sat, May 4, 2013 at 3:33 AM, Frederik Ramm wrote:
> On 03.05.2013 18:15, Svavar Kjarrval wrote:
>
>> Just wanted to notify those who didn't know: There is now a property
>> (P402) in use in Wikidata to link the corresponding entry to a relation
>> ID in OSM.
>>
>
> This is a very bad idea and
Hi,
On 03.05.2013 18:15, Svavar Kjarrval wrote:
Just wanted to notify those who didn't know: There is now a property
(P402) in use in Wikidata to link the corresponding entry to a relation
ID in OSM.
This is a very bad idea and should not be used.
Bye
Frederik
--
Frederik Ramm ## eMail fre
62 matches
Mail list logo
