Hi,
Am Tue, 02 Aug 2011 11:31:03 +0200
schrieb Frederik Ramm frede...@remote.org:
The great thing about such a server would be that the server could
indeed *always* know which links are still working and which are
broken, and broken links could even be automatically highlighted on
something
Am Tue, 2 Aug 2011 09:21:49 -0700 (PDT)
schrieb Ian ian.d...@gmail.com:
On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote:
Now if this node (point on a map) is replaced with another one by a
fellow mapper (for whatever reason), I think it would be a progress
if ID
Hi,
Steve Bennett wrote:
If your definition of work is guaranteed to work under all
circumstances no matter what, then sure. But if it's continue to
function subject to a slow rate of linkrot
[...]
It is even conceivable
that, for whatever reason, IDs are changed on a grand scale - for
Andrzej,
andrzej zaborowski wrote:
Or create an OSM relation containing just the thing you want to link
to and reference the relation's Id the editors already support
warning when somethign bad happens to a relation member.
Under no circumstances should we burden the mapper with keeping
The great thing about such a server would be that the server could indeed
*always* know which links are still working and which are broken, and broken
links could even be automatically highlighted on something like
OpenStreetBugs so anyone who is interested could hunt them down and fix
them.
I'm not sure I understand why having the ability to link to external
data through some sort of ID is such a bad thing. This is common in
many APIs and datasets. It is an opportunity to mix data in new ways
as well.
Frederik also this seems odd to me I'm not a big fan of UUIDs
because, again,
Hi,
Kate Chapman wrote:
I'm not sure I understand why having the ability to link to external
data through some sort of ID is such a bad thing.
This is about external data linking to us, not vice versa.
This is common in
many APIs and datasets. It is an opportunity to mix data in new ways
Frederik Ramm wrote:
Which brings me back to something I mentioned earlier - I would like
to have some kind of link server where you can go and say I
want a permanent link to this OSM object, then the server says
ok, I have investigated the object you mentioned and I'd say I
make the
On Tue, Aug 2, 2011 at 7:31 PM, Frederik Ramm frede...@remote.org wrote:
And to Steve Bennett (people need a solution now, not vapourware) -
sometimes settling for a half-baked solution too early has the risk of
entrenching half-bakedness and never getting around to implement a good
solution.
Kate Chapman wrote:
Why aquiesce to use tags at all, making
data more consistent just burdens *our* data with stuff other people
want to do with it.
It is impossible to create a map that displays buildings if no one adds
buildings to the database. Adding buildings requires effort, but it is
On 02/08/2011 11:08, Frederik Ramm wrote:
Well then let them think of a solution. Using our internal IDs to link
to is a vapourvare solution just the same. Anyone who uses them must
be aware that they might change at any time, even wholesale.
Exactly.
OSM does not cause buildings to be
Hi,
Am Mon, 01 Aug 2011 09:21:44 +0200
schrieb Frederik Ramm frede...@remote.org:
That was me. There are a number of other reasons why IDs could
break. One is the expansion of POI nodes into buildings that Toby
mentioned. Another is the splitting of ways (old ID would then point
to only
Hi,
On 08/02/11 15:21, Gregor Horvath wrote:
It is a logically inaccurate to delete an ID in such cases.
What you actually logically do is replacing an ID, or creating an alias.
The problem is there is no semantic in OSM data to express such a move
operation. Deleting is the wrong one. Deleting
Gregor Horvath gre...@ediwo.com wrote:
Hi,
Am Mon, 01 Aug 2011 09:21:44 +0200
schrieb Frederik Ramm frede...@remote.org:
That was me. There are a number of other reasons why IDs could
break. One is the expansion of POI nodes into buildings that Toby
mentioned. Another is the
Am Tue, 02 Aug 2011 15:43:54 +0200
schrieb Frederik Ramm frede...@remote.org:
Hi,
On 08/02/11 15:21, Gregor Horvath wrote:
It is a logically inaccurate to delete an ID in such cases.
What you actually logically do is replacing an ID, or creating an
alias. The problem is there is no
On Tue, Aug 2, 2011 at 6:01 PM, Frederik Ramm frede...@remote.org wrote:
Hi,
Kate Chapman wrote:
I'm not sure I understand why having the ability to link to external
data through some sort of ID is such a bad thing.
This is about external data linking to us, not vice versa.
This is
Hi,
On 08/02/11 16:06, Gregor Horvath wrote:
OSM provides uri's to ID's which are linked to names of
physical objects. Example:
http://www.openstreetmap.org/browse/node/1381574156
IN HTTP world URI's should be stable
Well maybe then we should stop providing URIs if this gives people the
Gregor Horvath wrote:
OSM provides uri's to ID's which are linked to names of
physical objects. Example:
http://www.openstreetmap.org/browse/node/1381574156
No. It doesn't.
OSM does not provide URIs to anyone. OSM has an _editing_ API. It's here
to facilitate edits to the end product, which
2011/8/2 Gregor Horvath gre...@ediwo.com:
OSM provides uri's to ID's which are linked to names of
physical objects. Example:
http://www.openstreetmap.org/browse/node/1381574156
But these objects often make no sense in the real world!
In the real world, there are things like streets, pubs,
Hi,
Am Tue, 02 Aug 2011 16:32:29 +0200
schrieb Frederik Ramm frede...@remote.org:
I think you are again making the mistake of mixing various layers of
meaning. If someone deletes an object in OSM to trace it anew, from
better imagery for example, then he is creating a new model, and the
Am Tue, 2 Aug 2011 16:55:20 +0200
schrieb Ture Pålsson t...@lysator.liu.se:
2011/8/2 Gregor Horvath gre...@ediwo.com:
OSM provides uri's to ID's which are linked to names of
physical objects. Example:
http://www.openstreetmap.org/browse/node/1381574156
But these objects often make
For what it's worth Flickr often had a similar conversation with the
Y!Geo / WOE kids, especially in the early days when we were just getting
to know one another.
The short version is that we were simply not going to use their IDs if
they couldn't guarantee that they has some measure of
On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote:
Now if this node (point on a map) is replaced with another one by a
fellow mapper (for whatever reason), I think it would be a progress if
ID 1381574156 points to the new node instead of vanishing.
Who or what decides that
straup str...@gmail.com wrote:
I'm not going to pretend to understand the guts of the OSM code well
enough to suggest that supersedes/superseded_by would be easy to
implement or not but it's always seemed like a useful approach to me.
This supersedes / is superseded by approach would work,
2011/8/2 Ian ian.d...@gmail.com:
On Tuesday, August 2, 2011 10:14:13 AM UTC-5, Gregor Horvath wrote:
Now if this node (point on a map) is replaced with another one by a
fellow mapper (for whatever reason), I think it would be a progress if
ID 1381574156 points to the new node instead of
On Wed, Aug 3, 2011 at 12:32 AM, Frederik Ramm frede...@remote.org wrote:
I think you are again making the mistake of mixing various layers of
meaning. If someone deletes an object in OSM to trace it anew, from better
imagery for example, then he is creating a new model, and the old model
Hi,
Steve Bennett wrote:
3) Why people intentionally destroy ids, and whether there are better
ways of achieving their goals?
(I seem to recall someone explaining that sometimes objects are
deleted and recreated in order to discard the change history,
particularly for large relations.)
That
Hi,
Thank you for your response.
I believe Richard F has made comments in the past that we shouldn't
do this
Well, I don't know about the discussion yet, maybe you could give me a
hint for which subject to search for?
I just want to mention, that for Wikipedia there exists an analysis
On Mon, 01 Aug 2011 09:21:44 +0200, Frederik Ramm wrote:
(Two or three people have also started tagging OSM objects with UUID
tags but I don't think that that's anything more than database bloat.
I think that about 99.9% of UUID tags in the database come from a
building import where somebody
I've got a wiki that links certain localities to the OSM map. I
use the
addr: fields for that. They are unique (at least for my purpose),
but
this also does not guarantee 100% continuity.
I did a map once with links to local pubs. I found storing their
latitude and longitude was good enough
On Mon, 1 Aug 2011 09:29:41 +0100, Ed Loach wrote:
I've got a wiki that links certain localities to the OSM map. I
use the
addr: fields for that. They are unique (at least for my purpose),
but
this also does not guarantee 100% continuity.
I did a map once with links to local pubs. I found
The stable ID question to me comes down to philosophy: It would be nice
if the world was stable but it's not.
Asking for stable IDs is like asking for the world not to change. But it
does, continuously. Any road changes over time in name, surface,
connectivity and it's other attributes.
For what it's worth we were aware that IDs were technically considered
unstable when we started down the OSM machine tags extras road, at Flickr.
It seemed like a reasonable potential gotcha given that most of the IDs
are stable most of the time and the risks were outweighed by the
benefits
On Mon, Aug 1, 2011 at 7:19 PM, straup str...@gmail.com wrote:
For what it's worth we were aware that IDs were technically considered
unstable when we started down the OSM machine tags extras road, at Flickr.
Do you have an idea of how often OSM machine tags are added to items
in Flickr, and
On 8/1/2011 7:40 PM, Richard Weait wrote:
It's pretty cool. I should use those tags more often.
Here's an example of FLickr tags VS new map data after +1.5 years.
Granted, there are only about a dozen underlying POIs where the shop /
restaurant has been replaced, but it's largely correct
I don't, no. I do still see people adding osm:* tags to their photos
though, via the RSS feeds, but realistically I don't expect its gotten
much traction.
Like the blog post said it's still pretty a dorky feature and that
means it really needs some love and tools and examples to help people
On Mon, Aug 1, 2011 at 5:21 PM, Frederik Ramm frede...@remote.org wrote:
Relying on numeric IDs is never going to work, and there is no way how this
could be made to work in the future. IDs are OSM internal identifiers and if
you use them for anything external then you're lost.
If your
On 1 August 2011 09:52, Maarten Deen md...@xs4all.nl wrote:
On Mon, 01 Aug 2011 09:21:44 +0200, Frederik Ramm wrote:
(Two or three people have also started tagging OSM objects with UUID
tags but I don't think that that's anything more than database bloat.
I think that about 99.9% of UUID tags
Hi,
Is anyone aware of
1) any analysis/research about the stability of OSM ids?
2) any tool(s) that attempts to figure out whether
a) the meaning of an entity (node, way, relation) changed between
two versions (e.g. using the id of pub and marking it as a cafe).
b) a new id is the same
3) Why people intentionally destroy ids, and whether there are better
ways of achieving their goals?
(I seem to recall someone explaining that sometimes objects are
deleted and recreated in order to discard the change history,
particularly for large relations.)
It would definitely be valuable to
On Sun, Jul 31, 2011 at 8:39 PM, Steve Bennett stevag...@gmail.com wrote:
It would definitely be valuable to have the identifiers be more
persistent. I've been linking to some from Wikipedia:
http://en.wikipedia.org/wiki/O%27Keefe_Rail_Trail . I believe Richard
F has made comments in the past
41 matches
Mail list logo
