On 28 March 2010 19:09, Jaak Laineste wrote:
> sample has total 52 fields: name and HTML descriptions in 3 languages,
> photos, opening hours, contacts (email,web,post, phones), organization
> details, tickets,access (wheelchair, public transport details), different
> flags etc. Perhaps it is not
On Sat, Mar 27, 2010 at 2:40 PM, Frederik Ramm wrote:
> Jaak Laineste wrote:
>> Is there a way to make maintenance
>> of only their specific data in OSM easy?
>
> I think we're having different pictures here. OSM is not a platform
> which you can use to host "your" data. The data ceases to become
Hi,
Jaak Laineste wrote:
> There could be quite good reasons to protect some of the data at least
> temporarily.
Let's look at them then.
> Very technical reason: to avoid accidental deletion of nodes
> during bulk import (which takes days sometimes).
Happened to me - but to be honest, only b
On 27 March 2010 10:28, Jaak Laineste wrote:
>
>
> I have a particular example: a friend just called me, and he is in board
> of
> national assiocation of museums. They have and maintain kind of official
> database of all museums in the country. They wanted to have them on web
> map,
> and I sugg
Hi,
Im just tagging on to this thread for the archives. As it was just sent to
the imports@ list, but not dev@ list,
It attempts to solve the ideas that jaak noted below.
http://lists.openstreetmap.org/pipermail/talk-gb/2010-March/005544.html
(I was going to respond last week on this thread) ...
At 2010-03-22 12:02, Nic Roets wrote:
>...
>Unfortunately it has already happened many times. Below is a list of
>the third party identifiers that I have found.
>...
>
>
>hdop
>sat
>pdop
>fix
>vdop
To pick a nit, these are likely not ids, but instead useful info provided
via GPS. I recognize:
hd
I've long considered that it would be good to have a system whereby anyone
modifying a specified subset of the database would be presented with a
message for them to read before comitting.
This would be implemented with a special key that all editing software would
be encouraged to support.
In th
On Tue, Mar 23, 2010 at 12:50 PM, Frederik Ramm wrote:
> Jaak Laineste wrote:
> > 1) my inserted data (tag, node, relation, way - any of them) can be
> defined
> > as private, nobody else can not even see it.
> > 2) my data is protected - you can see, but not modify
> > 3) my data has group priv
Hi,
Jaak Laineste wrote:
> Just for the
> future APIs I suggest to give to original importer (or just editor) some
> kind of priority over the others. Like possibility to lock/protect some
> parts of the data. It could be done in several levels:
> 1) my inserted data (tag, node, relation, way - a
On 22 March 2010 12:38, Andy Allan wrote:
> On Mon, Mar 22, 2010 at 7:12 PM, Ian Dees wrote:
>
> > Almost 100% of the time these are imported to allow for the possibility
> of
> > future updates to the existing imports.
>
> Except, as you point out, they can't be used in any way for "future
> up
Hi,
Andy Allan wrote:
> No, it's a distraction from the real problem, which is that merging
> datasets is fundamentally hard, and needs to be approached with
> sophistication and fuzzy location-based matching (e.g. feature church,
> near this point, name something close to "all saint(')s").
+1. I
On Mon, Mar 22, 2010 at 7:12 PM, Ian Dees wrote:
> Almost 100% of the time these are imported to allow for the possibility of
> future updates to the existing imports.
Except, as you point out, they can't be used in any way for "future
updates" since you've got no idea if the reference stays on
On Mon, Mar 22, 2010 at 2:02 PM, Nic Roets wrote:
> On Mon, Mar 22, 2010 at 6:18 PM, Tom Hughes wrote:
> > On 22/03/10 15:00, Nic Roets wrote:
> >
> >> One solution is to add your own tag to the OSM files you generate e.g.
> >> smartsoft_id=nnn. And publish the files for review somewhere. Then
>
13 matches
Mail list logo
