Philip Barnes wrote:
I would prefer to keep the source tag with the object. Within a changeset I
will often have some roads where source is GPS, have traced some buildings from
bing, and added a few pub/shop names where source is survey
I did put my hand up for a tag which is automatically
We don't have to choose between the 2 solutions (source on objects vs. source
on change set).
It's possible to use a fall back system, something like :
For display :
If no source is available on an object, show the source of the last change set
(if available)
For editing :
If no source is set
On Sep 28, 2012, at 1:56 PM, Olivier Croquette wrote:
For display :
If no source is available on an object, show the source of the last change
set (if available)
Actually that should read: show the sources of all change sets that created or
modified the object.
The whole thing would need a
The tag 'source' on the changeset has some pros and cons:
Pros:
- size in database
- works only if the changeset comes from a single source
Cons:
- impossible to modify after changeset is closed
- attribution lost in data extracts, planet (separate file for changesets)
- doesn't allow more than
Pieren wrote:
- attribution lost in data extracts, planet (separate file for changesets)
ACTUALLY that is probably the killer?
Local working with truncated extracts SHOULD still report this type of data?
--
Lester Caine - G8HFL
-
Contact -
2012/9/28 Lester Caine les...@lsces.co.uk:
I did put my hand up for a tag which is automatically applied for those of
us who forget it ;) If I have a background layer up it automatically adds
that tag to each object. If I'm selecting stuff from another source then
that gets added. ALL of this
Lester Caine wrote:
I did put my hand up for a tag which is automatically applied for those of
us who forget it ;) If I have a background layer up it automatically adds
that tag to each object.
In Potlatch you can simply press 'B' (for 'Background') to add the source=
tag for the current
2012/9/28 Lester Caine les...@lsces.co.uk:
Pieren wrote:
- attribution lost in data extracts, planet (separate file for changesets)
ACTUALLY that is probably the killer?
Local working with truncated extracts SHOULD still report this type of data?
come on, I think you are overexxagerating
2012/9/28 Pieren pier...@gmail.com:
The tag 'source' on elements:
Pros:
- support multiple sources during edit session
- attribution present in planet, extracts
- can be modified at any time
- retrieve one element history is easy (one API call)
Cons:
- size in database
- works fine only
Martin Koppenhoefer wrote:
It mostly boils down to the simple question: does the mapper have
local knowledge or doesn't he. Did he recently survey the area?
Reviewing my own 'processing', even where I have local knowledge I know I should
be adding tags when I'm tracing, but when I'm in the flow
2012/9/28 Lester Caine les...@lsces.co.uk:
I have to change manually, but the DATA certainly is important, and tags
like 'start_date' should be populated by default!
How would the editor (program) know about the start_date? What are
you using this tag for?
cheers,
Martin
Martin Koppenhoefer wrote:
I am not advocating to act accordingly, but saying that in every data
extract there must be full history (that is also attribution, to see
who edited the stuff), or changeset information, or source-tags , or a
source-tag on every single object might not be necessary.
2012/9/28 Lester Caine les...@lsces.co.uk:
Full history comes from the main database ... I was just advocating 'source'
which adds to the information when one is looking at something and saying
That is wrong! you may know straight away that it is a candidate to
update.
yes, but often when
On 28 September 2012 15:13, Martin Koppenhoefer dieterdre...@gmail.com wrote:
yes, but often when something is wrong, the source-tag is as well ;-).
I have seen lots of source=PSG (coastline) where the data obviously
was far too detailed to be from PSG, it is because people hardly
remove
Martin Koppenhoefer wrote:
I have to change manually, but the DATA certainly is important, and tags
like 'start_date' should be populated by default!
How would the editor (program) know about the start_date? What are
you using this tag for?
Eventually a corrected date can be added ... we
The only real problem I see mentioned above is the overall size of the
database. It seems to me that we are somehow confusing problems caused by
the data itself with problems caused by its storage in the database.
Couldn't we simply work on a scheme that would normalize the database, so
that we'd
The tag source=survey hides the fact that those coordinates were derived from
the signal provided by a particular infrastructure: the US satellites. Maybe
those ways derived from GPS tracks should be tagged source=NASA or
source=Pentagon, instead of source=survey, which does not cite the true
Why not go all the way and say source=cesium? In all seriousness, though,
what's wrong with source=GPS as an alternative? Survey, to me, implies a
crew out with tripods and such.
Karl
On Tue, May 6, 2008 at 12:32 PM, Juan Lucas Dominguez Rubio
[EMAIL PROTECTED] wrote:
The tag source=survey
Karl Newman wrote:
Sent: 06 May 2008 8:58 PM
To: Juan Lucas Dominguez Rubio
Cc: talk@openstreetmap.org
Subject: Re: [OSM-talk] [tagging] Against source=survey
Why not go all the way and say source=cesium? In all seriousness, though,
what's wrong with source=GPS as an alternative? Survey, to me
19 matches
Mail list logo
