Re: [OSM-talk] OSM needs a measure for completeness

[Martin Trautmann]

graham wrote:
> 80n wrote:
> 
>> In a sense I'm already doing this.  The very last thing I do when I've
>> completed an area is to add landuse=residential (only where appropriate,
>> of course).  I could easily add complete=level-n to this landuse boundary.
>>
> 
> Surely completeness is relative to purpose? I have areas where all roads
> between settlements are filled in but not the settlements, other urban
> areas where all roads are filled in and named, others where all roads
> and footpaths are complete. 

I feel that completeness of settlements can not be achieved as long as 
roads are incomplete. Thus first level should be completeness of the 
road net. Most important next for me is appropriate tags for routing, 
such as speed limits or "bicycle=yes".

- Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] I've removed historic=icon from map features

[Tony Bowden]

Robin Paulson wrote:
>> http://de.wikipedia.org/wiki/Bildstock
> of course, i remember seeing these in austria now. yes, they are quite
> prominent aren't they and maybe map-worthy after all - would you be
> willing to put a proposal up on the wiki? unfortunately, i can't speak
> german or i'd do it

Why does it need a proposal? It was already on Map Features until a 
unilateral decision to remove it. Now that it's been explained what it 
is, why not just put it back and document it?

Tony

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders (was: administrative boundaries and is_in)

[Robin Paulson]

On 12/01/2008, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 11:32 AM, Igor Brejc <[EMAIL PROTECTED]> wrote:
> > That would be an interesting thing to implement. It would involve
> > creating a union of circles (with radius of 12 NM) and then determining
> > the border of that union. If only I had the time... :)
>
> I thin you'd approach it from the other way. Take a 12nm circle and
> push it against the coastline so it touches at a point. Then "roll" it
> along with the centre tracing a line, forming either an arc where it
> rotates around a point, or a straight line as it slides along an edge.

well, there are two elements to consider:
ways, and points.
ways are easy: as they are drawn a certain direction always (water on
left, is that it?), we just create a set of ways that are 12 nautical
miles to the left of each way.
for points, yes, as igor says it's best to create a circle around each
point, of 12 nautical miles radius.
there must be some (CAD?) library for taking three inputs (two
straight lines, a circle), and working out the necessary start and end
point of the three items, so they form a continuous, smooth (i.e.
tangential) line. then repeat for all point/line combinations

i'll start a wiki page. anyone here have any experience with drawing
libraries? i'm sure we can do this by re-using something that's
already there

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] RFC: Import of OpenGeoDB to OSM

[Martin Trautmann]

Frederik Ramm wrote:

> As to where their data comes from - we don't really know 


Most of it was based on NIMA data, with 1/10 minute precision

Much data has been added since.

I don't know how this data should be added best.

When you import everything, you will have lots of duplicate places.

My recommended approach and current work is to add the best reference, 
which is the location id of the currend way or node.

Take e.g. the road I live in:
http://www.openstreetmap.org/?lat=48.0255&lon=7.8644&zoom=12

It's within Freiburg, Baden-Württemberg, Germany

The town district is named Zähringen (about 1000 years old). Its loc id 
in opengeodb is 81730:

http://fa-technik.adfc.de/code/opengeodb.pl?locid=81730;c=D

There's not much info about this district, thus it may share its data 
with its parent Freiburg through its "part of" relation:
http://fa-technik.adfc.de/code/opengeodb.pl?locid=16633;c=D

base data is e.g. its abbreviation (car plates), inhabitants, postal 
code, telephone prefix, area,while there may be added extra data such as 
height, different names in other languages etc.

Svens approach is to move most of the data to OSM. Personally, I'd 
prefer to take only a subset for reference, while most of the roads 
should have a loc_id tag about the district where they belong to.

- Martin

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Robin Paulson]

On 13/01/2008, 80n <[EMAIL PROTECTED]> wrote:
> On Jan 12, 2008 2:10 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
> > Let's say I'm looking at a satellite image and I see a body of water.
> > Is it a lake/reservoir/dam/blah? I don't know. Yet the proposed scheme
> > forces me to choose one with a 2/3 chance of being wrong. Maybe its a
> > type that has no translation in English, then I'm really SOL.
> >
> > I suppose what I'm contesting is the statement that natural=water is
> > deprecated. It covers all the impoartant properties needed for 99% of
> > users. If somebody cares about details they can add them but I object
> > to me being forced to care.
> >
>
> I totally agree with this sentiment.
>
> It should be possible to be vague about something when tagging it.  There
> are several vague tags that I really like and use frequently (natural=water,
> natural=grass being my two favorites) that allow you to describe what you
> see without having to worry about whether it's a lake a pond or a reservoir,
> or a park a green or a common.  In many cases there's no way of knowing or
> finding out, so these vague tags are very useful.

well, yes and no. if you want to be vague, there's no reason why we
can't have a waterway=water tag. that way if the mapper doesn't know
what *exact* type of water it is, they can still tag it under the
water scheme, but not have to know anymore.

at present, if they don't know what type of water it is, they have to
tag it under a separate hierarchical tree, using a tag (natural) which
overlaps with the water tag.

the point i'm trying to get across, is that all water features, be
they linear (rivers, canals, stream) or areas (lakes, reservoirs) or
whatever would benefit from being under _one_ top-level tag, for
consistency.

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] I've removed historic=icon from map features

[Robin Paulson]

On 12/01/2008, Marc Schütz <[EMAIL PROTECTED]> wrote:
> > After - I think - three questions over the last months about
> > historic=icon on this list - with no real response - I just removed it
> >
> > >from the map features page.
> >
> > If some one comes up with a good explanation what this is we might put
> > it back later, but in the meantime this was only confusing ...
> >
>
> It seems I'm a bit late in this discussion, but could it be something like
> this:
>
> http://de.wikipedia.org/wiki/Bildstock

of course, i remember seeing these in austria now. yes, they are quite
prominent aren't they and maybe map-worthy after all - would you be
willing to put a proposal up on the wiki? unfortunately, i can't speak
german or i'd do it

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders

[Robin Paulson]

On 13/01/2008, Lukasz Stelmach <[EMAIL PROTECTED]> wrote:
> > according to wp, it was the range of a cannon in 14th c or something
>
> XIV c. ships would draw rather then carried a cannon that could
> shoot as far as 22.2 km. It must be something different.

i should say, i'm no expert on this, but the article i was talking
about mentioned land cannons, which probably had none of the weight
constraints that ship-based cannons did.
anyway, i digress

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Bruce Cowan]

On Sat, 2008-01-12 at 19:08 +, graham wrote:
> Surely completeness is relative to purpose? I have areas where all roads
> between settlements are filled in but not the settlements, other urban
> areas where all roads are filled in and named, others where all roads
> and footpaths are complete. I haven't yet done any areas which have
> complete traffic lights, pedestrian crossings, turn restrictions, bus
> routes, administrative boundaries, or navigational information for
> waterways. The possible purposes are pretty orthogonal - rather than a
> set of numbered completeness, you'd need to allow multiple
> 'complete_for=purpose' tags. And if you attach that to landuse
> boundaries, what do you do in large urban areas where it's all residential?

I had a few roads which I considered "complete", but revisiting them a
few months ago, I noticed they were of fairly low quality (node density
wise). This could apply to any area.

As a sideline, I wonder if wrong GPS traces will become a problem. In
this scenario, imagine a road changing position (like the A8 in Port
Glasgow [0]). The old GPS traces will still have the old position, so
the majority (to start with) of traces are in the old place.

[0]
http://www.openstreetmap.org/?lat=55.937&lon=-4.697&zoom=16&layers=B0FT
-- 
Bruce Cowan <[EMAIL PROTECTED]>


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Betr.: Re: OSM needs a measure for completeness

[David James]

On Sun, January 13, 2008 12:09 am, ndm wrote:
> A primary route (in the UK) would be assumed to have a 112 kph speed
> limit?

I'm nitpicking, I know, but that would be a bad assumption, primary routes
certainly have speed limits of 30, 40, 50, 60, and 70 mph. I'd not be
surprised if one could find bits with a 20 mph speed limit.

I travelled over several tens of miles of "highway=trunk" and
"highway=primary" (in OSM's UK convention) in North and East Yorkshire on
Saturday, and none of the parts I travelled over had a speed limit of 70
mph (= 112 kph).

>
> Neil
>
>
>
> ___
> talk mailing list talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
>


-- 
David James
Telephone (home) 01262 606420,
(mobile) 07803 927813


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] RFC - postal addresses (relations)

[Claus Färber]

Hallo,

I've written a proposal for postal addresses:

http://wiki.openstreetmap.org/index.php/Relations/Proposed/Postal_Addresses

It covers more than house numbers, i.e. it includes streets, postal 
codes, etc., even countries).

However, the proposal does not allow putting some house numbers on a map 
and having the rest be interpolated); this should, IMO, be handled 
differently (and discussed at 
http://wiki.openstreetmap.org/index.php/Proposed_features/House_numbers).

Due to the nature of postal addresses, the proposal overlaps with the 
tagging of geographic areas, such as countries, regions, etc.

Claus


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Betr.: Re: OSM needs a measure for completeness

[ndm]

mallok   aragorn.de> writes:

> Marking a place as complete is one discussion. I have been "wasting" thoughts
on regular verification. How
> do we make sure that  we always stay informed about changes over time, sort of
regular reviews?

I think what would be useful is to have a tool / filter to be able to extract
elements from a map that are subject to a particular set of criteria, either
tags (or other implicit restrictions). Then those that are interested can easily
verify that an area meets their definition of completeness. The output would
either be a new map, or a list?

For example:
Recover all street names (as a list)
Recover all primary routes
Recover all elements that are accessible by an hgv, car, pedestrian, etc.
Recover all routes with a given speed limit
Recover all pharmacies

Note: there may be implicit restrictions that could be "assumed" -- e.g. a car
park is accessible by default to cars and pedestrians, but not hgv's?
A residential road is assumed ok for pedestrians, whereas a primary road is not?
An unsurfaced road is assumed to be access only for hgv's?
A primary route (in the UK) would be assumed to have a 112 kph speed limit?

Neil


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Betr.: Re: OSM needs a measure for completeness

[Gregory]

On 12/01/2008, mallok <[EMAIL PROTECTED]> wrote:
>
> Marking a place as complete is one discussion. I have been "wasting"
> thoughts on regular verification. How do we make sure that  we always stay
> informed about changes over time, sort of regular reviews?
>
> mallok
>

By using the data we are validating it.
And in promoting OSM I often respond to "how do I know it's right", well if
you use it and others do then you can spot any mistake. I guess it's just
like wikipedia with that.

Near home, I've even corrected something someone else did (the road name
changed a few months after it was first named) because I was trying out
using OSM maps on my phone.


-- 
Gregory
[EMAIL PROTECTED]
http://www.livingwithdragons.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders

[Lukasz Stelmach]

Robin Paulson wrote:

On 12/01/2008, Igor Brejc <[EMAIL PROTECTED]> wrote:

Just as a curiosity: 12 NM was chosen because it it the farthest point a
person can see from the shore (due to Earth's roundness). Or something
like that :)


according to wp, it was the range of a cannon in 14th c or something


XIV c. ships would draw rather then carried a cannon that could 
shoot as far as 22.2 km. It must be something different.


--
Było mi bardzo miło.   Czwarta pospolita klęska, [...]
>Łukasz< Już nie katolicka lecz złodziejska.  (c)PP



--
Sprawdz, ktore komorki sa najmodniejsze!
Kliknij >>> http://link.interia.pl/f1cd4
begin:vcard
fn;quoted-printable:=C5=81ukasz Stelmach
n;quoted-printable:Stelmach;=C5=81ukasz
email;internet:[EMAIL PROTECTED]
x-mozilla-html:FALSE
version:2.1
end:vcard

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders (was: administrative boundaries and is_in)

[Robin Paulson]

On 12/01/2008, Igor Brejc <[EMAIL PROTECTED]> wrote:
> Just as a curiosity: 12 NM was chosen because it it the farthest point a
> person can see from the shore (due to Earth's roundness). Or something
> like that :)

according to wp, it was the range of a cannon in 14th c or something

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Mark Williams]

Robert (Jamie) Munro wrote:
[]
> Rather than creating special ways, just to show completeness, why not
> mark the ways that are already there with weather or not they are
> completely connected. I.e. I know that all the roads and footpaths that
> connect to my road are on the map, so I could put a tag on the road
> saying complete_connected=roads,footpaths or something. We could then
> make a map with all the roads that are marked as not completed coloured.
> 
> Also, if we could make a tag for a road that you have seen one end of
> but haven't mapped down, that would be useful. Some people use 3
> unconnected nodes as a sort of ... symbol on the map, but this doesn't
> work very well. A short way that was tagged specially would indicate to
> people that that area needed surveying because the roads weren't
> complete. If a road had these for all the roads joining it, I would mark
> it as complete in the scheme above.
> 
> Robert (Jamie) Munro

Isn't that FIXME?

Validator picks this up especially (in JOSM) & highlights it.

I initially thought this was bad, but have just added it to all un-named
roads in 'my' area because an un-named road on my GPS looks, well, like
any other, but this tag shows up in my editor, on my GPS while I'm out -
and denotes a particular level of completeness. I have also used
note:TODO to mark a path end I'm not going down yet, because I can
search on it - but have swapped them for FIXME now.


The above 'Three Dots' would tend to pick up in Validator too, but with
a tempting 'Fix' button to unmark them ;)

Obviously this only applies to marking incompleteness, which is (as
previously observed) relatively simple... I think if all this gets to
proposals, I'd go for an 'incompleteness' markup which could include
things the mapper knows he hasn't done, + anything a script spots isn't
done, + any casual visitors observed needs, etc - any time an important
new feature comes up, it _could_ get added globally & removed progressively?

A 'complete' markup will go obsolete every time a vote gets approved &
can't cope with things we hadn't thought of at the time, and it's all
very well saying it's only for given parts but just look at highway
tagging for example - bus_guideway, turning_circle are in progress, and
will promptly render many 'streets complete' tags wrong if approved.

Mark


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Robert (Jamie) Munro]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Chris Morley wrote:
| David Earl wrote:
|  > I've said before and I'll say again: we need a way of
|  > asserting "this area is complete" (for one or more
|  > definitions of completeness).
|
| Andy Robinson (blackadder) wrote:
|  > The only way that we are going to individually or
|  > collectively state the completeness of a specific area
|  > is to carry out a verification process. It doesn't have
|  > to be done by third parties or even different contributors
|  > but it does need to be done by someone.
|  > We need a simple tag to display verification, perhaps
|  > the username and a date, say verification=blackadder_20080111
|  > or similar.
|
| Martin Trautmann wrote:
|  > Is OSM that far that we need verification and quality ensurance?
|  > We are still far from completeness, which might be a primary goal.
|
| I have started a new thread with a measure for completeness in the title
| because this is an important topic for OSM. But the response to the
| recent posts quoted above, and my raising of it last July, has been only
| luke-warm.

Rather than creating special ways, just to show completeness, why not
mark the ways that are already there with weather or not they are
completely connected. I.e. I know that all the roads and footpaths that
connect to my road are on the map, so I could put a tag on the road
saying complete_connected=roads,footpaths or something. We could then
make a map with all the roads that are marked as not completed coloured.

Also, if we could make a tag for a road that you have seen one end of
but haven't mapped down, that would be useful. Some people use 3
unconnected nodes as a sort of ... symbol on the map, but this doesn't
work very well. A short way that was tagged specially would indicate to
people that that area needed surveying because the roads weren't
complete. If a road had these for all the roads joining it, I would mark
it as complete in the scheme above.

Robert (Jamie) Munro
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.6 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHiR9Lz+aYVHdncI0RAi1UAKCpO0t8ItrMQL3n8ZSAr6nlpaJcDACgjdVb
gBtFlc6IFQUKOHOrszPSC3Q=
=isju
-END PGP SIGNATURE-

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Betr.: Re: OSM needs a measure for co mpleteness

[mallok]

Marking a place as complete is one discussion. I have been "wasting" thoughts 
on regular verification. How do we make sure that  we always stay informed 
about changes over time, sort of regular reviews?

mallok
-Ursprüngliche Nachricht-
Von: graham <[EMAIL PROTECTED]>
Datum: 12/01/08 20:08
An: talk@openstreetmap.org
Betreff: Re: [OSM-talk] OSM needs a measure for completeness

80n wrote:

> 
> In a sense I'm already doing this.  The very last thing I do when I've
> completed an area is to add landuse=residential (only where appropriate,
> of course).  I could easily add complete=level-n to this landuse boundary.
> 

Surely completeness is relative to purpose? I have areas where all roads
between settlements are filled in but not the settlements, other urban
areas where all roads are filled in and named, others where all roads
and footpaths are complete. I haven't yet done any areas which have
complete traffic lights, pedestrian crossings, turn restrictions, bus
routes, administrative boundaries, or navigational information for
waterways. The possible purposes are pretty orthogonal - rather than a
set of numbered completeness, you'd need to allow multiple
'complete_for=purpose' tags. And if you attach that to landuse
boundaries, what do you do in large urban areas where it's all residential?

Graham

> 80n
> 
> 
>  
> 
> 
> Chris
> 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> 
> 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


___



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Tom Higgy]

Chris Morley wrote:
> OSM really needs a measure for local completeness to demonstrate its 
> progress externally. I hope enough people can be roused to discuss, and 
> hopefully agree, the principles, before deciding on an implementation.

Would it make any sense at all to consider it from the other angle, as 
in a measure of incompleteness, as well as completeness. That is make it 
easy for people to say 'there is a road missing here' or 'that's 
actually called hol demi close'? Then you verify these measures of in 
accuracy and the area is complete again.

I think it could work if there were enough people marking errors in a 
particular area, and would make it easier for those without the kit 
(i.e. GPS or aerial imagery) to get involved.

At the same time, of course, it would help to be able to say a 
particular user has verified this area to be complete at this particular 
point in time (changes happen, if you don't know when the area was 
marked complete you won't know a past development actually applies).
-- 
Cheers,

Tom
- www.bandnet.org

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies

[Ulf Lamping]

Andy Robinson (blackadder) schrieb:
> While we are talking about tags I want to thank all those who take the time
> and effort to put up proposals and make comments on them. The process is
> very useful in seeing what users need and wish to tag. Personally though I
> feel the process is more complicated than it need be, so I have some ideas
> to simplify it without loosing the ability to propose and comment. I also
> believe that we can learn a lot form the tags that are in the database
> already. Not all tags need to a proposal/comment process if they are logical
> and users simply get on an use them.
>   
Unfortunately, because the proposer thinks it's a logical thing doesn't 
mean it's in fact a pretty good idea - if you take a look at the 
proposed features page, there are lot's and lot's of proposals lying 
around for quite a while that seemed like a good idea first (at least 
the author was motivated enough to write a wiki page about it) - so I 
guess about 2/3 of the proposals started gets *not approved*!

The classical problem is that a mapper tags a thing that he's very 
interested in (e.g. 
http://wiki.openstreetmap.org/index.php/Proposed_features/Red_Cross), so 
he tags it with a specialised tag. With some more thinking a much better 
tag could be invented that fit's very well into a lot more cases. 
Otherwise we can easily get into "tag fragmentation" with a lot of very 
special tags being similiar but not identical to each other.

About your "tags from the database". What I would really like to see is 
something like the tagwatch page and getting the results on a weekly 
basis. Or a really cool thing would be some automated way to get: "the 
top hundred tags not already in the map features".
> As many of you know I'm not fond of the voting process. I see why some feel
> it's important but I'll always maintain that 6 votes of approval for a tag
> is not a quorum of 2,000+ editors 
Well, if 6 voters - who care a bit about the topic - says yes (and noone 
says no), it gives you a good idea that this porposal makes sense. Not 
to say that about 1900 of the 2000 editors will simply never do anything 
about voting (maybe they're not even registered to the mailing list!) ;-)
> so we should never blindly assume that an
> "approved" tag is the best way of doing things.
>   
Yes, I'm even pretty sure about this, but what's the alternative?
> I'm also not in favour of "deprecating" tags, apart from this being wholly
> the wrong word in the first place (obsolete is better) because this implies
> that there was something wrong with the original tagging. The obsolete tags
> are still just as valid as information so let's not blindly disapprove of
> them by using the word "deprecate".
>   
This is nitpicking. Call it "obsolete" or whatever - I don't really care 
unless the name makes sense (and I guess most others also don't care).  
Let's call them obsolete from now on - please just go on and change the 
page name ...

Important to me is that by reading the map features page you get a good 
feeling how to tag things. This obviously means that inconsistencies and 
duplicates needs to be avoided - as this makes understanding a lot more 
difficult than it already is ...

Regards, ULFL

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Tom Evans]

graham wrote:
> Surely completeness is relative to purpose? 

Sort of - I think you need definitions in terms of content rather than purpose, 
just for clarity.  But they could obviously be aimed at a purpose.

When I said 'multiple' definitions I definitely had in mind separately defined 
levels like Chris said below.  There might be a rough ordering, but nothing 
like 
a 1-5 scale.  If, in the future, somebody wants to add field boundaries, and 
somebody else thinks marking all the shops is more important, we don't want 
to argue over which goes in level 6!

Chris Morley wrote:

> They would be tagged with one (or possibly more) definitions of 
> completeness like "major roads", "public roads", "public paths", which 
> would be defined on a wiki page.



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] RFC: Import of OpenGeoDB to OSM

[Frederik Ramm]

Hi,

> I was going to ask the same thing... googling pops up a german wikipedia 
> link...  Frederik mind helping?

The matter had been discussed on talk-de; they call themselves a
"free" database and have their data listed as "Public Domain" on
Sourceforge so at least from their point of view incorporation into
OSM should not pose a problem. (They used to be LGPL but removed that
around 2006.)

As to where their data comes from - we don't really know but the bulk
of the data has been around since 2003 and that's definitely
pre-Google Maps. The main author, Thomas Mack, claims to have compiled
the bulk from various free sources which he explicitly checked for
"PD-ability", and says he sometimes used commercial maps to
cross-check individual data items but never copied from them.

So I'd say the data is clean, or at least clean enough ;-)

Readers of German might want to check this posting by Thomas Mack in
which he responds to a question by Joerg Ostertag (who would have
thought of that!) and says something about the sources:

http://lists.phpbar.de/pipermail/opengeodb/2006-September/003552.html

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[graham]

80n wrote:

> 
> In a sense I'm already doing this.  The very last thing I do when I've
> completed an area is to add landuse=residential (only where appropriate,
> of course).  I could easily add complete=level-n to this landuse boundary.
> 

Surely completeness is relative to purpose? I have areas where all roads
between settlements are filled in but not the settlements, other urban
areas where all roads are filled in and named, others where all roads
and footpaths are complete. I haven't yet done any areas which have
complete traffic lights, pedestrian crossings, turn restrictions, bus
routes, administrative boundaries, or navigational information for
waterways. The possible purposes are pretty orthogonal - rather than a
set of numbered completeness, you'd need to allow multiple
'complete_for=purpose' tags. And if you attach that to landuse
boundaries, what do you do in large urban areas where it's all residential?

Graham

> 80n
> 
> 
>  
> 
> 
> Chris
> 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org 
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
> 
> 
> 
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] RFC: Import of OpenGeoDB to OSM

[Stephen Coast]

On 12 Jan 2008, at 18:43, J.D. Schmidt wrote:

> Sven Anders skrev:
>> The OpenGeoDB Project has data about (many places of
>> *Germany,
>> *Belgium,
>> *Liechtenstein,
>> * Austria and
>> *Switzerland.
>>
>> There are 45873 places in this database.
>>
>>
>> You can find there data of:
>> * postal codes
>> * license plate codes
>> * community identification numbers
>> and some more.
>>
>> I have writen a small tool, which can import all of the data to OSM.
>> I would like to start the import in one week, if there is no veto.
>>
>> More Informatione about the import you can find one the Wiki-Page:
>>
>> http://wiki.openstreetmap.org/index.php/User:OpenGeoDB
>>
>> I`m not a native English speaker, so please correct the field names  
>> and  give
>> comments to the Wiki Page
>>
>>
>> Thank you
>>
>> Sven Anders
>>
>
> You have ofcourse checked that whatever license used for the data in  
> the
> OpenGeoDB doesn't taint the OSM license in any way ?

I was going to ask the same thing... googling pops up a german  
wikipedia link...  Frederik mind helping?

>
>
> Dutch
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>

have fun,

SteveC | [EMAIL PROTECTED] | http://www.asklater.com/steve/



___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Dair Grant]

Frederik Ramm wrote:

>>There are places in OSM where there is no data; these are
>>obviously incomplete.
>
>How would you know ;-) there are places which are complete with
>nothing on them!

Good point! Which makes it all the more important to have a 
mechanism for marking it as such, if only to reduce the number 
of people who make pointless trips to the middle of nowhere to 
confirm there's nothing there...


-dair (although given enough pointless trips, you would create a 
de-facto footpath - problem solved! ;-)
___
[EMAIL PROTECTED]  http://www.refnum.com/


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] RFC: Import of OpenGeoDB to OSM

[J.D. Schmidt]

Sven Anders skrev:
> The OpenGeoDB Project has data about (many places of 
> *Germany, 
> *Belgium,
> *Liechtenstein,
> * Austria and 
> *Switzerland. 
> 
> There are 45873 places in this database.
> 
> 
> You can find there data of:
> * postal codes
> * license plate codes
> * community identification numbers
> and some more.
> 
> I have writen a small tool, which can import all of the data to OSM.
> I would like to start the import in one week, if there is no veto.
> 
> More Informatione about the import you can find one the Wiki-Page: 
> 
> http://wiki.openstreetmap.org/index.php/User:OpenGeoDB
> 
> I`m not a native English speaker, so please correct the field names and  give 
> comments to the Wiki Page
> 
> 
> Thank you
> 
> Sven Anders
> 

You have ofcourse checked that whatever license used for the data in the 
OpenGeoDB doesn't taint the OSM license in any way ?

Dutch

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies

[Andy Robinson (blackadder)]

Dair Grant wrote:
>Sent: 12 January 2008 4:10 PM
>To: talk@openstreetmap.org
>Subject: Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)
>
>Frederik Ramm wrote:
>
>>I'm not saying that "natural=water" should be deprecated. I'm just
>>saying that if someone wants to introduce a tagging for lakes or
>>other *special* kinds of water, then there is no technical
>>requirement to tag everything that is tagged with the new lake tag
>>(say, water=lake) as natural=water *also*, because the fact that
>>"water=lake implies natural=water" could be stored externally.
>
>There is definitely benefit in being able to say "X is a kind of Y".
>
>Any client software using OSM has its own internal model (roads
>can be drawn in one of 7 styles, say) and has to map OSM's tags
>to that model to use it.
>
>At present that means a big list of explicit tag matches, and
>anything unrecognised just has to be discarded.
>
>
>Another approach would be to have a "conforms to" page, like Map
>Features, which describes how tags related to each other.
>
>Software might not know what a reservoir or a dam were, but if
>it can fetch some rules that teach it what they're similar to
>(say a general body of water) then it can do something sensible
>with them.
>
>
>>Obviously the option of vague tagging must remain, otherwise the
>>lake tag would have to go once the biologists start differentiating
>>between various types of lakes, and in the end we'd end up with a
>>system where nobody can tag anything unless he's one of the world's
>>three experts.
>
>In the above case the software wouldn't have to care about what
>kind of sub-types of lake people wanted to define - if they all
>conformed to "it's a lake" then they can be processed as such.
>
>I've been careful to say "conforms to" rather than hierarchy
>here, since I think that might be the bridge between
>pre-defining every tag for mappers (bad) vs every client having
>to hard-wire a list of stuff they understand and ignoring the
>rest (also bad).
>
>The idea of conformance is that things conform to properties of
>something less specific than them - this is a "like a"
>relationship, not an "is a", so things can have multiple ancestors.
>
>
>We kind of have this today, where something might be tagged with
>multiple tags to indicate different aspects of its nature.
>
>That helps people capture things as they are on the ground, but
>building the inverse would make it easier to actually do things
>with the data.
>
>
>I'm not sure what the best way to see if this is feasible would
>be; perhaps just sifting through the tags in planet to see what
>values people actually use.
>
>My guess is that people often use the tags supported by the
>renderers, both because they're common things in reality but
>also because making something appear on screen is more
>fulfilling than capturing lots of data nobody ever sees.
>
>A conforms-to system would allow renderers to use the small
>hierarchy of tags that they have rules for, but also allow
>people to tag things however they liked (provided their tags
>relate to something else, they don't need to adjust their
>tagging to match a renderer).
>
>On the subject of tagging, was there any more development on the
>STAGS idea from SOTM?
>
>


Well, yes. There has. But actually not quite in the direction that I was
taking STAGS.

I spend a lot of time observing and reading the discussions on tagging to
see what the different opinions are and the sort of tags that come up for
discussion. From it all I've learnt a number of useful things:

Tags definitely work best when they are not in a regimented format. There
are some users of course that would rather be using an OSM "Standard" for
tags. There are also those who prefer to create the tags on the fly just
using logic. If we spend time creating an all encompassing "standard" only a
small percentage of the potential OSM user base will be at all interested in
using it, partly because it's too dictatorial and partly because its making
the process over complicated and therefore removes the fun. Also by the time
we have agreed one the world will have moved on. Standards wanking is not
the OSM way of getting things done.

However, if we have no tagging "guidance" (ie there was no Map Features for
instance) then users are unsure of where to start or indeed how to tag at
all. The very concept of a key/value pair to non programmers can't always be
assumed.

We can and have pre-seeded tags into the editors and this seems to work ok
for the basics.

What I've been observing is that there is a real benefit of encouraging the
use of a core set of keys. We do this now to a large extent with the Map
Features root keys (highway, waterway etc). It's interesting to see that
since I put the original Map Features out there has not been a big push for
more "root" keys and the majority (but not all) of the new proposals are for
new values or keys that logically form a subkey.

I've also seen that the proposals for new tags are not always l

Re: [OSM-talk] OSM needs a measure for completeness

[Frederik Ramm]

Hi,

> There are places in OSM where there is no data; these are 
> obviously incomplete.

How would you know ;-) there are places which are complete with
nothing on them!

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Frederik Ramm]

Hi,

> OSM really needs a measure for local completeness to demonstrate its 
> progress externally. I hope enough people can be roused to discuss, and 
> hopefully agree, the principles, before deciding on an implementation.

I'm all for it but I would really try to deduce this completeness from
external sources.

For example:

* Get statistics about paved roads in certain administrative areas,
  compare with OSM paved roads, arrive at a percentage of
  completeness.

* Get population statistics and a good estimate for length of roads
  or ways per capita in the type of area you're looking at; use that
  to compute how many miles of road you should have and compare to 
  OSM.

* Get number of named roads for certain areas (even if the full lists
  might be legally problematic, it should be possible to call someone
  in the city administration and ask them for the *number* of roads 
  at least!) and compare with OSM data.

And so on. This will of course never be accurate but could help to
draw coloured maps that give us an estimate of how good we're doing.

Self-assessed detail complenetess ("Personally went to this quarter
and verified every road") is something that I see further down the
road, and that will probably require some technical infrastructure.
Whereever possible I'd like to try and have this completeness assessed
by people *other* than those who did the mapping; maybe through a web
interface where casual visitors can check their area of residence and
rubber-stamp it (or note down complaints).

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Freek]

On Saturday 12 January 2008, Tom Evans wrote:
> David Earl wrote:
>  > I've said before and I'll say again: we need a way of
>  > asserting "this area is complete" (for one or more
>  > definitions of completeness).
>
> Chris Morley wrote:
> > A possible detailed approach is as follows. A completeness boundary
> > would be modelled on coastline: it would enclose an area, but would
> > consist of many (ordinary) ways, with the completed area on the right.
> > They would be tagged with one (or possibly more) definitions of
> > completeness like "major roads", "public roads", "public paths", which
> > would be defined on a wiki page. Boundary ways would be moved or added
> > on a day-to-day basis by anybody with local knowledge. An area might
> > even have holes in it.  Somebody would provide an overview map showing
> > completed areas, and its animation would feature in most presentations
> > on OSM.
>
> I like the idea, 

Me too.

> but agree it definitely needs the multiple (documented) 
> definitions of completeness. 

Apart from some linear scale (e.g. 1-5 as suggested), I think we might also 
need some more specific approach for the areas covered by the AND and TIGER 
imports. Both will perhaps score 5 on the completeness scale for roads, but 
for example AND imported data needs some work to get it "up to standard" [1]. 
Also, most tracks and cycleways are not present. It would be nice to be able 
to say that for some area that (e.g.)
- road data is from AND and partially verified;
- major tracks and unsurfaced roads are added;
- cycleways are complete;
- amenities are not added.

On the other hand, to be able to more easily render a nice map (overlay?) of 
completeness, it might be better to re-define the linear scale for these 
areas... (Which, I know, is perhaps not very nice.)

[1] http://wiki.openstreetmap.org/index.php/AND-NL:_Todo
Dutch todo list regarding data imported from AND. For example all ways not 
accessible by cars are tagged as highway=pedestrian. On a case-by-case basis 
this needs to be changed to e.g. footway, cycleway or left pedestrian.

-- 
Freek

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Tom Evans]

David Earl wrote:
 > I've said before and I'll say again: we need a way of
 > asserting "this area is complete" (for one or more
 > definitions of completeness).

Chris Morley wrote:
> A possible detailed approach is as follows. A completeness boundary 
> would be modelled on coastline: it would enclose an area, but would 
> consist of many (ordinary) ways, with the completed area on the right. 
> They would be tagged with one (or possibly more) definitions of 
> completeness like "major roads", "public roads", "public paths", which 
> would be defined on a wiki page. Boundary ways would be moved or added 
> on a day-to-day basis by anybody with local knowledge. An area might 
> even have holes in it.  Somebody would provide an overview map showing 
> completed areas, and its animation would feature in most presentations 
> on OSM.

I like the idea, but agree it definitely needs the multiple (documented) 
definitions of completeness.  I'd personally like to reach an annotated map 
of all the footpaths to say what they're like, but this is silly  without 
getting 
the road coverage in an area first.

Also agree this should be be done before 'verification'.  But maybe the 
annotation for that could piggyback on the same system once it's tested 
and bugs ironed out.  The former would lead toward the latter, I would think. 
Particularly since you couldn't verify anything without a documented definition 
of the claimed completeness anyway.

Tom




___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[Dair Grant]

Chris Morley wrote:

>I have started a new thread with a measure for completeness in the
>title because this is an important topic for OSM. But the response
>to the recent posts quoted above, and my raising of it last July,
>has been only luke-warm.

I also think completeness is a very important idea - it's false 
to think that a map is ever going to be "complete", but I don't 
think it's a good answer to say it can't be done.

There are places in OSM where there is no data; these are 
obviously incomplete.

Equally there are places in where the data is at least as good 
as any other map (bits of London say), subject to our data model 
(no house numbers, say).


>I wonder whether this is because "completeness" is associated in
>people's minds too closely with verification. As Andy has describes
>it in the (incomplete) quote above, verification involves individual
>accountability - "I personally accept responsibility for the
>accuracy of this data".

I don't think you accept responsibility for it in the sense of 
liability in case of mistakes, but as soon you as you enter some 
data into OSM you do accept some responsibility for it.

You're responsible for ensuring that it bears some relationship 
to reality, that it didn't come from an illegal source, etc.


>As is the case for all other mapping information, an assertion of
>completeness should only imply the best endeavours of the
>contributor, not a guarantee of 100% correctness. If you have ridden
>round a housing estate systematically and collected all the required
>information, you can reasonably say the area covered is complete.
>With this understanding, completeness would become part of routine
>mapping. It would encourage a systematic approach and the collection
>of any missed information.

Absolutely. I would be very happy if there was some way I could 
give a simple badge (or a score, 1-5, where 1 is empty and 5 is 
complete), to some area to indicate how "done" I thought it was.

Both to myself as a way to keep track of what's next, but also 
so that other mappers can see just how much there is to do.


>A possible detailed approach is as follows. A completeness boundary
>would be modelled on coastline: it would enclose an area, but would
>consist of many (ordinary) ways, with the completed area on the
>right. They would be tagged with one (or possibly more) definitions
>of completeness like "major roads", "public roads", "public paths",
>which would be defined on a wiki page. Boundary ways would be moved
>or added on a day-to-day basis by anybody with local knowledge. An
>area might even have holes in it.  Somebody would provide an
>overview map showing completed areas, and its animation would
>feature in most presentations on OSM.

I was thinking of a simpler model - each OSM account gets to 
define a list of bounding circles, and a 1-5 completeness rating 
for each circle.

Circles rather than boxes, because completeness is by definition 
a fuzzy subject.

Rather than trying to exactly cover the world with areas that 
are done/not done, it'd be better to just drop some approximate 
circles to cover smallish areas.


These will all overlap and generally look a bit of a mess, but I 
think could be rendered in a way that would give you a sense of 
completeness in some area and demonstrate progress.

E.g., at this point in time the areas that are complete should 
have more priority when rendering a zoomed out view - everyone 
knows that London will have lots of little holes in it, but in 
general most of the circles in there will be "complete".

When you zoom in then the incomplete areas become more 
important, so by the time you're at town/village level you want 
to be able to see which suburbs still need work to do.


The only difficult bit is setting up the database to manage this information.

I think it would be better done as part of the OSM user 
accounts, rather than in the OSM database, since I think putting 
it in the real data encourages us to try and over-specify 
something that's always going to be ambiguous.

Periodically some software pulls all that information out and 
renders a map of it, or sends a message to any users with 
obvious contradictions (two circles share more than 75% of their 
area and their ratings are too far apart, or similar).


-dair
___
[EMAIL PROTECTED]  http://www.refnum.com/


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Dair Grant]

Frederik Ramm wrote:

>I'm not saying that "natural=water" should be deprecated. I'm just
>saying that if someone wants to introduce a tagging for lakes or
>other *special* kinds of water, then there is no technical
>requirement to tag everything that is tagged with the new lake tag
>(say, water=lake) as natural=water *also*, because the fact that
>"water=lake implies natural=water" could be stored externally.

There is definitely benefit in being able to say "X is a kind of Y".

Any client software using OSM has its own internal model (roads 
can be drawn in one of 7 styles, say) and has to map OSM's tags 
to that model to use it.

At present that means a big list of explicit tag matches, and 
anything unrecognised just has to be discarded.


Another approach would be to have a "conforms to" page, like Map 
Features, which describes how tags related to each other.

Software might not know what a reservoir or a dam were, but if 
it can fetch some rules that teach it what they're similar to 
(say a general body of water) then it can do something sensible 
with them.


>Obviously the option of vague tagging must remain, otherwise the
>lake tag would have to go once the biologists start differentiating
>between various types of lakes, and in the end we'd end up with a
>system where nobody can tag anything unless he's one of the world's
>three experts.

In the above case the software wouldn't have to care about what 
kind of sub-types of lake people wanted to define - if they all 
conformed to "it's a lake" then they can be processed as such.

I've been careful to say "conforms to" rather than hierarchy 
here, since I think that might be the bridge between 
pre-defining every tag for mappers (bad) vs every client having 
to hard-wire a list of stuff they understand and ignoring the 
rest (also bad).

The idea of conformance is that things conform to properties of 
something less specific than them - this is a "like a" 
relationship, not an "is a", so things can have multiple ancestors.


We kind of have this today, where something might be tagged with 
multiple tags to indicate different aspects of its nature.

That helps people capture things as they are on the ground, but 
building the inverse would make it easier to actually do things 
with the data.


I'm not sure what the best way to see if this is feasible would 
be; perhaps just sifting through the tags in planet to see what 
values people actually use.

My guess is that people often use the tags supported by the 
renderers, both because they're common things in reality but 
also because making something appear on screen is more 
fulfilling than capturing lots of data nobody ever sees.

A conforms-to system would allow renderers to use the small 
hierarchy of tags that they have rules for, but also allow 
people to tag things however they liked (provided their tags 
relate to something else, they don't need to adjust their 
tagging to match a renderer).

On the subject of tagging, was there any more development on the 
STAGS idea from SOTM?


-dair
___
[EMAIL PROTECTED]  http://www.refnum.com/


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] OSM needs a measure for completeness

[80n]

On Jan 12, 2008 3:48 PM, Chris Morley <[EMAIL PROTECTED]> wrote:

> David Earl wrote:
>  > I've said before and I'll say again: we need a way of
>  > asserting "this area is complete" (for one or more
>  > definitions of completeness).
>
> Andy Robinson (blackadder) wrote:
>  > The only way that we are going to individually or
>  > collectively state the completeness of a specific area
>  > is to carry out a verification process. It doesn't have
>  > to be done by third parties or even different contributors
>  > but it does need to be done by someone.
>  > We need a simple tag to display verification, perhaps
>  > the username and a date, say verification=blackadder_20080111
>  > or similar.
>
> Martin Trautmann wrote:
>  > Is OSM that far that we need verification and quality ensurance?
>  > We are still far from completeness, which might be a primary goal.
>
> I have started a new thread with a measure for completeness in the title
> because this is an important topic for OSM. But the response to the
> recent posts quoted above, and my raising of it last July, has been only
> luke-warm.
>
> I wonder whether this is because "completeness" is associated in
> people's minds too closely with verification. As Andy has describes it
> in the (incomplete) quote above, verification involves individual
> accountability - "I personally accept responsibility for the accuracy of
> this data". I don't think this is suitable for OSM at the moment; it may
> be necessary in the future if and when OSM becomes a serious alternative
> to commercial suppliers - but not yet. I, and probably others, are eager
> to make their contributions of as high quality as possible, but are wary
> about making a public and personal commitment to their accuracy.
>
> As is the case for all other mapping information, an assertion of
> completeness should only imply the best endeavours of the contributor,
> not a guarantee of 100% correctness. If you have ridden round a housing
> estate systematically and collected all the required information, you
> can reasonably say the area covered is complete. With this
> understanding, completeness would become part of routine mapping. It
> would encourage a systematic approach and the collection of any missed
> information.
>
> A possible detailed approach is as follows. A completeness boundary
> would be modelled on coastline: it would enclose an area, but would
> consist of many (ordinary) ways, with the completed area on the right.
> They would be tagged with one (or possibly more) definitions of
> completeness like "major roads", "public roads", "public paths", which
> would be defined on a wiki page. Boundary ways would be moved or added
> on a day-to-day basis by anybody with local knowledge. An area might
> even have holes in it.  Somebody would provide an overview map showing
> completed areas, and its animation would feature in most presentations
> on OSM.
>
> OSM really needs a measure for local completeness to demonstrate its
> progress externally. I hope enough people can be roused to discuss, and
> hopefully agree, the principles, before deciding on an implementation.
>

In a sense I'm already doing this.  The very last thing I do when I've
completed an area is to add landuse=residential (only where appropriate, of
course).  I could easily add complete=level-n to this landuse boundary.

80n




>
> Chris
>
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] OSM needs a measure for completeness

[Chris Morley]

David Earl wrote:
 > I've said before and I'll say again: we need a way of
 > asserting "this area is complete" (for one or more
 > definitions of completeness).

Andy Robinson (blackadder) wrote:
 > The only way that we are going to individually or
 > collectively state the completeness of a specific area
 > is to carry out a verification process. It doesn't have
 > to be done by third parties or even different contributors
 > but it does need to be done by someone.
 > We need a simple tag to display verification, perhaps
 > the username and a date, say verification=blackadder_20080111
 > or similar.

Martin Trautmann wrote:
 > Is OSM that far that we need verification and quality ensurance?
 > We are still far from completeness, which might be a primary goal.

I have started a new thread with a measure for completeness in the title 
because this is an important topic for OSM. But the response to the 
recent posts quoted above, and my raising of it last July, has been only 
luke-warm.

I wonder whether this is because "completeness" is associated in 
people's minds too closely with verification. As Andy has describes it 
in the (incomplete) quote above, verification involves individual 
accountability - "I personally accept responsibility for the accuracy of 
this data". I don't think this is suitable for OSM at the moment; it may 
be necessary in the future if and when OSM becomes a serious alternative 
to commercial suppliers - but not yet. I, and probably others, are eager 
to make their contributions of as high quality as possible, but are wary 
about making a public and personal commitment to their accuracy.

As is the case for all other mapping information, an assertion of 
completeness should only imply the best endeavours of the contributor, 
not a guarantee of 100% correctness. If you have ridden round a housing 
estate systematically and collected all the required information, you 
can reasonably say the area covered is complete. With this 
understanding, completeness would become part of routine mapping. It 
would encourage a systematic approach and the collection of any missed 
information.

A possible detailed approach is as follows. A completeness boundary 
would be modelled on coastline: it would enclose an area, but would 
consist of many (ordinary) ways, with the completed area on the right. 
They would be tagged with one (or possibly more) definitions of 
completeness like "major roads", "public roads", "public paths", which 
would be defined on a wiki page. Boundary ways would be moved or added 
on a day-to-day basis by anybody with local knowledge. An area might 
even have holes in it.  Somebody would provide an overview map showing 
completed areas, and its animation would feature in most presentations 
on OSM.

OSM really needs a measure for local completeness to demonstrate its 
progress externally. I hope enough people can be roused to discuss, and 
hopefully agree, the principles, before deciding on an implementation.

Chris





___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Frederik Ramm]

Hi,

> > I'm not saying that "natural=water" should be deprecated. I'm just
> > saying that if someone wants to introduce a tagging for lakes or other
> > *special* kinds of water, then there is no technical requirement to tag
> > everything that is tagged with the new lake tag (say, water=lake) as
> > natural=water *also*, because the fact that "water=lake implies
> > natural=water" could be stored externally.
> 
> No, that's the wrong approach.

Care to elaborate?

> Do not "break" existing software (in this case renderers). For the
> time being, you also must tag every water area as "natural=water".

It's not like I was suggesting to make a change *now*. I just objected
to the notion that for the sake of programs processing OSM data, every
single object should carry with it a full hierarchy, instead of making
that hierarchy available and one central source.

("This is a crib barn, which in case you didn't know dear renderer, is
a type of barn, which in case you didn't know dear renderer, is a type
of building, which in case you didn't know dear renderer, is a
man-made object...")

The advantage of storing hierarchy with every single object is of
course that you can use any number of hierarchies at the same time and
even invent new ones for every object you map. But I don't assume that
this would make things *easier* for the renderer ;-)

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Karl Eichwalder]

> I'm not saying that "natural=water" should be deprecated. I'm just
> saying that if someone wants to introduce a tagging for lakes or other
> *special* kinds of water, then there is no technical requirement to tag
> everything that is tagged with the new lake tag (say, water=lake) as
> natural=water *also*, because the fact that "water=lake implies
> natural=water" could be stored externally.

No, that's the wrong approach.  Do not "break" existing software (in
this case renderers).  For the time being, you also must tag every
water area as "natural=water".


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Frederik Ramm]

Hi,

>It should be possible to be vague about something when tagging it.  There
>are several vague tags that I really like and use frequently
>(natural=water, natural=grass being my two favorites)

No problem with that at all. (Myself, I also use "landuse=residential"
for "from the low-res sat image I can see there must be people living
there".)

I'm not saying that "natural=water" should be deprecated. I'm just
saying that if someone wants to introduce a tagging for lakes or other
*special* kinds of water, then there is no technical requirement to tag
everything that is tagged with the new lake tag (say, water=lake) as
natural=water *also*, because the fact that "water=lake implies
natural=water" could be stored externally.

Obviously the option of vague tagging must remain, otherwise the lake
tag would have to go once the biologists start differentiating between 
various types of lakes, and in the end we'd end up with a system where
nobody can tag anything unless he's one of the world's three experts.

"Surface=asphalt you say, hm? Let's take a sample and ship it to the
laboratory..."

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] RFC: Import of OpenGeoDB to OSM

[Sven Anders]

The OpenGeoDB Project has data about (many places of 
*Germany, 
*Belgium,
*Liechtenstein,
* Austria and 
*Switzerland. 

There are 45873 places in this database.


You can find there data of:
* postal codes
* license plate codes
* community identification numbers
and some more.

I have writen a small tool, which can import all of the data to OSM.
I would like to start the import in one week, if there is no veto.

More Informatione about the import you can find one the Wiki-Page: 

http://wiki.openstreetmap.org/index.php/User:OpenGeoDB

I`m not a native English speaker, so please correct the field names and  give 
comments to the Wiki Page


Thank you

Sven Anders

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[80n]

On Jan 12, 2008 2:10 PM, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:

> On Jan 12, 2008 2:13 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > > The world has an infinite diversity and we can't go inventing new tag
> > > combinations for all of them. We need to think hierarchically, start
> > > with the real defining characteristics: land/sea/road/rail/etc and use
> > > subtags for the finegrained stuff.
> >
> > While this is true, it would not be necessary to stuff the hierarchy
> > into the tagging scheme.
> >
> > Suppose you say something like this (just an example, not meant as a
> > suggestion for real-world use):
> >
> > 1st level: natural=water
> > 2nd:   water=standing (as opposed to flowing)
> > 3nd:   standing_water=lake (as opposed to puddle, reservoir...)
>
> I'm not sure that's the kind of hierarchy I meant, but I think there
> should be a top-level and stuff under that. A base-type + properties.
> I'm looking at it from the point of view of a tagger. As far as I'm
> concerned the difference between a dam and a reservoir is just a name
> and should be reflected in the name tag.
>
> Let's say I'm looking at a satellite image and I see a body of water.
> Is it a lake/reservoir/dam/blah? I don't know. Yet the proposed scheme
> forces me to choose one with a 2/3 chance of being wrong. Maybe its a
> type that has no translation in English, then I'm really SOL.
>
> I suppose what I'm contesting is the statement that natural=water is
> deprecated. It covers all the impoartant properties needed for 99% of
> users. If somebody cares about details they can add them but I object
> to me being forced to care.
>

I totally agree with this sentiment.

It should be possible to be vague about something when tagging it.  There
are several vague tags that I really like and use frequently (natural=water,
natural=grass being my two favorites) that allow you to describe what you
see without having to worry about whether it's a lake a pond or a reservoir,
or a park a green or a common.  In many cases there's no way of knowing or
finding out, so these vague tags are very useful.




>
> Have a nice day,
> --
> Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Tagging hierarchies (was: RFC - lake)

[Martijn van Oosterhout]

On Jan 12, 2008 2:13 PM, Frederik Ramm <[EMAIL PROTECTED]> wrote:
> Hi,
>
> > The world has an infinite diversity and we can't go inventing new tag
> > combinations for all of them. We need to think hierarchically, start
> > with the real defining characteristics: land/sea/road/rail/etc and use
> > subtags for the finegrained stuff.
>
> While this is true, it would not be necessary to stuff the hierarchy
> into the tagging scheme.
>
> Suppose you say something like this (just an example, not meant as a
> suggestion for real-world use):
>
> 1st level: natural=water
> 2nd:   water=standing (as opposed to flowing)
> 3nd:   standing_water=lake (as opposed to puddle, reservoir...)

I'm not sure that's the kind of hierarchy I meant, but I think there
should be a top-level and stuff under that. A base-type + properties.
I'm looking at it from the point of view of a tagger. As far as I'm
concerned the difference between a dam and a reservoir is just a name
and should be reflected in the name tag.

Let's say I'm looking at a satellite image and I see a body of water.
Is it a lake/reservoir/dam/blah? I don't know. Yet the proposed scheme
forces me to choose one with a 2/3 chance of being wrong. Maybe its a
type that has no translation in English, then I'm really SOL.

I suppose what I'm contesting is the statement that natural=water is
deprecated. It covers all the impoartant properties needed for 99% of
users. If somebody cares about details they can add them but I object
to me being forced to care.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

[OSM-talk] Tagging hierarchies (was: RFC - lake)

[Frederik Ramm]

Hi,

> The world has an infinite diversity and we can't go inventing new tag
> combinations for all of them. We need to think hierarchically, start
> with the real defining characteristics: land/sea/road/rail/etc and use
> subtags for the finegrained stuff. 

While this is true, it would not be necessary to stuff the hierarchy
into the tagging scheme.

Suppose you say something like this (just an example, not meant as a
suggestion for real-world use):

1st level: natural=water
2nd:   water=standing (as opposed to flowing)
3nd:   standing_water=lake (as opposed to puddle, reservoir...)

and I suppose biologists will have a number of additional levels. 
 
What you're saying would now amount to copy this hierarchy into every
single body of water by tagging it natural=water,water=standing,
standing_water=lake,... - just so that a renderer knowing only of
natural=water can still render it.

Obviously this makes it easy to understand if you see the object out
of context, and makes it easy for the renderer. But this is at the
cost of storing the hierarchy a thousand seperate times in the
database, with a high potential for errors (something tagged
natural=forest and standing_water=lake would show up green on some
renderers and blue on others, depending what level they look at...)
and also considerable workload should the hierarchy ever be changed.

Keeping the hierarchy *external*, say on a wiki page that defines
that everything tagged "standing_water=lake" is also "water=standing"
and everything that is "water_standing" is also "natural=water", would
require only *one* tag on the object; the renderer would have to load
the hierarchy from the external source but that would really not be
too difficult.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail [EMAIL PROTECTED]  ##  N49°00.09' E008°23.33'


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders (was: administrative boundaries and is_in)

[Martijn van Oosterhout]

On Jan 12, 2008 11:32 AM, Igor Brejc <[EMAIL PROTECTED]> wrote:
> That would be an interesting thing to implement. It would involve
> creating a union of circles (with radius of 12 NM) and then determining
> the border of that union. If only I had the time... :)

I thin you'd approach it from the other way. Take a 12nm circle and
push it against the coastline so it touches at a point. Then "roll" it
along with the centre tracing a line, forming either an arc where it
rotates around a point, or a straight line as it slides along an edge.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] RFC - lake

[Martijn van Oosterhout]

On Jan 12, 2008 4:45 AM, Robin Paulson <[EMAIL PROTECTED]> wrote:
> > >it seems a logical one to me, we need to differentiate between lakes
> > >and rivers, canals, etc.

> > duplicates natural=water which is very, very widely used - 9421 times
>
> no problem, they can all be changed very simply i should think.

To provide some counter-weight: 99% of of things don't care about
whether it's a lake/reservoir/canal/river. Hence I would suggest a
top-level tag natural=water for *all* land/water boundaries (except
sea I suppose) and a seperate tag waterbody=lake/foo/bar to
differentiate.

I suppose you could say: Won't somebody please think of the renderers!

The world has an infinite diversity and we can't go inventing new tag
combinations for all of them. We need to think hierarchically, start
with the real defining characteristics: land/sea/road/rail/etc and use
subtags for the finegrained stuff. Let's face it: 99% of users won't
care about what the body of water is used for, so there's no reason
why it should be a top-level tag. It's also more flexible, because
then people can invent their own waterbody=foo combinations without
worrying that people won't know what it means.

Have a nice day,
-- 
Martijn van Oosterhout <[EMAIL PROTECTED]> http://svana.org/kleptog/

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] maritime borders (was: administrative boundaries and is_in)

[Igor Brejc]

Robin Paulson wrote:
> On 11/01/2008, Martijn van Oosterhout <[EMAIL PROTECTED]> wrote:
>   
>> - The border of a country is not the coastline, but (at the very
>> least) 12 nautical miles from the coastline and in some places, much
>> further than that.
>> 
>
> ok, let's say i wanted to use this as a basis for drawing the national
> boundary for a country. i appreciate that part of the border will be
> more than 12nm away from the coast (depending on the depth of the
> ocean floor, yes?), but it's a good start
>   
Just as a curiosity: 12 NM was chosen because it it the farthest point a 
person can see from the shore (due to Earth's roundness). Or something 
like that :)
> does some enterprising coder want to come up with a way of
> automagically drawing the border at a 12nm offset to the coastline?
> anywhere that the border is different, i would be happy to edit it
> manually, if a large part of it was being done by programmatic means
>
>   
That would be an interesting thing to implement. It would involve 
creating a union of circles (with radius of 12 NM) and then determining 
the border of that union. If only I had the time... :)

Igor

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] Kosmos v1.3 - shaded relief

[Igor Brejc]

Artem Pavlenko wrote:
>
> I've tried latest Kosmos and it works fine, though a bit slow. Are you 
> planning to release source?
Are you referring to the slowness of generating reliefs or generally? 
When generating reliefs the application first has to download the DEM 
tiles from NASA FTP site and that may take a while. But once the DEM is 
cached locally on your disk, it should work more or less quickly, 
depending on the hardware.
> I'm interested to try your shaded relief algorithm. Also, how do you 
> fill voids ?
>
Currently, the voids are not filled :). I'm using the original NASA 
SRTM3. But I am planning to include void filling or at least support for 
void-filled datasets that are freely available on the net.
As for releasing the source code: I still want to implement a lot of 
ideas with Kosmos, but I haven't got the time to be involved with 
maintaining an open source project on a daily basis. So until I feel it 
has reached a certain level of maturity, I'm keeping it closed source. 
But if you're interested in any particulars (like shading algorithms), I 
can send you the code.

Regards,
Igor

___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk

Re: [OSM-talk] I've removed historic=icon from map features

[Marc Schütz]

Am Donnerstag, 10. Januar 2008 22:40 schrieb Ulf Lamping:
> Hi!
>
> After - I think - three questions over the last months about
> historic=icon on this list - with no real response - I just removed it
>
> >from the map features page.
>
> If some one comes up with a good explanation what this is we might put
> it back later, but in the meantime this was only confusing ...
>

It seems I'm a bit late in this discussion, but could it be something like 
this:

http://de.wikipedia.org/wiki/Bildstock

Regards, Marc


pgpOIUCfzOBRV.pgp
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk