Re: [OSM-talk] Actually using OpenStreetMap and the usability of the current maps

[Sven Grüner]

spaetz schrieb:
> There is always population=20, etc which can help you to find the
> biggest ones. And what prevents us from adding capital=yes to those
> cities? I don't think that the tagging is insufficient today. OK
> there might be a more subjective "important" city tag, and there are
> problems with suburbs and all that. But I don't see that point as a
> big problem.

IMHO the cleanest way to determine capitals is to look which role a city 
has in the country/state/county-relation:
http://openstreetmap.org/browse/relation/16162

regards, Sven

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

Re: [OSM-talk] osmarenderer issues

[Sven Grüner]

Robert Vollmert schrieb:
> I believe angles >90 degrees are being rounded, which seems wrong for  
> most areas at least. Maybe start rounding at 150 degrees, if at all?  
> Probably even for roads, you'd put enough nodes in a bend to have each  
> angle above, say, 120 degrees.
> 
> Unfortunately, I can't find the spot in the osmarender source where  
> this is done.

The curving doesn't happen in Osmarender but is applied to the final 
SVG, that's why it's not possible to differentiate between streets, 
rivers and buildings, they're all just lines. The responsible script is 
lines2curves.pl:
http://trac.openstreetmap.org/browser/applications/rendering/tilesAtHome/lines2curves.pl#L421

Somewhere around that line the magic happens whether the angle is 90° or 
less. A while ago I tried to change that angle but was unsuccessful due 
to my lack of knowledge in Perl. I also emailed Barry Crabtree but 
wasn't able to understand his reply as well.

If anyone want's to investigate on this I'll be glad to forward those mails.

regards, Sven

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

Re: [OSM-talk] WTF ! (about gps traces)

[Sven Grüner]

Karl Newman schrieb:
> Or maybe the tracks need a moderation/voting system. If the tracks are voted
> down below a certain threshold, they won't be downloaded? Would need some
> careful thought to prevent malicious voting down of good tracks, though.
> Even if the editors had a way to hide certain tracks, that would be helpful.
> I've seen a few low-quality tracks in my area that I would like to make go
> away.

The user could (optionally) specify this threshold when requesting data. 
This way one could avoid bad tracks when enough good ones available and 
fall back on the bad ones when there's no alternative.

Alternatively a request would still return all Tracks but each track is 
returned along with it's quality level so that the editors can blank out 
  certain levels on demand.

I believe that somewhere in the distant future when data maintenance 
becomes more important than data creation the track handling will 
improve dramatically.

regards, Sven

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

Re: [OSM-talk] Tagging climbing routes and scrambles

[Sven Grüner]

Andy Robinson (blackadder) schrieb:
> For a climbing route it's normally the distance of assent that is of
> interest is it not and I guess for most traditional climbing routes this is
> known? Much easier to state the length of the route than the top and bottom
> elevations? Accepted that you might want to converge on an elevation for the
> start of the route as accuracy of the position is improved with time.

This reminds me of the recent discussion on canal locks. There the 
level-difference is also far more important than the absolute elevation.

Unfortunately I couldn't find it on the Wiki but if Gerv chose a generic 
tag it could be reused for this purpose as well.

regards, Sven

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

Re: [OSM-talk] Relations not always brilliant

[Sven Grüner]

Sebastian Spaeth schrieb:
> You do know that sometimes people need to download all entities of a
> relation when they download an area with a single node in it? I wouldn't
> want to download all elements of "earth" when I download my
> neighbourhood block. :-) How do you handle this problem?

Well, currently the API only returns direct members, so do our editors 
as well as my script. For "Earth" that would only be the few continents 
and a couple of oceans, totally bearable.

When you start to put all Autobahnen in the Germany-relation (since they 
are run and owned by the national governemnt) you will obviously run 
into trouble just when downloading direct members.
But this could be solved by only making the way-relation as proposed in:
http://wiki.openstreetmap.org/index.php/Relations/Proposed/Collected_Ways

That would result in about 100-200 direct members (instead of thousands 
of ways with millions of nodes), which is okay again. Alternatively one 
could request special member-groups of a relation by their role. I.e. 
"give me all states of Germany and the capital but not the Autobahnen, 
national buildings, etc."

This is of course still an issue but I believe that solutions will occur 
shortly after we run into serious trouble like always in OSM. And it 
will be a while till relations are so well used to cause  bandwith-problems.

regards, Sven

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

Re: [OSM-talk] Voting

[Sven Grüner]

Frederik Ramm schrieb:
> I've been critcised for not suggesting an alternative. So here's my 
> suggestion:
> 
> * [...]

Okay, slowly I realize that I took all this for granted while you didn't.
While I'm not yet certain wether you seriously propose such a task force 
it's no good idea I believe. That would inevitably become a "closed" 
group at that others would point their fingers saying "It's all their 
fault". In contrast our current system is truly open: Anybody can drop 
by in the wiki write one or two lines to a proposal and leave again.

> In this discussion, I find myself on their side: Our project is so open, 
> and I have the impression that you are trying to *reduce* that openness 
> by setting up a voting process. I have the suspicion that in the end you 
> want a project where new tags aren't even allowed unless they underwent 
> discussion and voting. And that's where my fierce opposition comes from.

Naturally I can only speak for myself but I'm almost certain this 
applies to others as well: I don't want to allow or disallow anything! 
When I spent time with proposals I consider that a service to others. 
Those others are free to chose wether they want to use my service of 
neatly structured and described tags or not.

I'm a mechanical engineer and see on a daily basis how industrial norms 
like ISO, DIN, etc. make things easier by allowing you to concentrate on 
your core business rather than worrying if other people will now what I 
mean by a M6x40 bolt. Take ISO 5457 for example: You are free to use 
whatever paperformat you like but isn't it also comfortable to walk into 
any shop and ask for DIN A4 paper sheets, that every printer and every 
desktop application will know what you mean without the need to say that 
it's a piece of paper with the dimensions 210x297mm?
Even when there are several competing norms that's fine as long each one 
clearly defines it's meaning and one knows which one applies.

There are of course laws and alike which enforce people to meet such 
norms but it's false to blame the resulting hassle on those who created 
the norm.
So we should try to scatter the illusion that tags as they can be found 
in the wiki are obligatory in any kind. I'll be glad to do so when you 
point me to such places.

regards, Sven

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

Re: [OSM-talk] Relations not always brilliant

[Sven Grüner]

Lester Caine schrieb:
> Until there is some UNIQUE way of tagging high level relationships 
> consistently, then there seems little point trying to fix fine detail at the 
> lower level. It brings back up the simple problem of producing a unique list 
> of objects in the data. How DO we currently identify all roads in the UK, so 
> that we don't end up with some of the simply silly links that the likes of 
> Autoroute returns when asking for a location.

I'm thinking along those lines as well for a while now. I don't believe 
it suffices to map all boundaries to determine which roads belong to 
which country/city/suburb. Leave alone the fact that many boundaries are 
pretty hard to find or even map. When I've mapped a village with, say, 
20 roads it takes me less than five clicks to group those in a relation 
and adding that relation to the relation of the municipality, town, etc. 
Even with the lowlevel relations support our editors currently have. I 
believe this is far more practical than to require mappers to map all 
relevant boundaries.

I've recently created a sandbox going the whole way from "Planet Earth" 
to "Some Road" all in nested relations. You can browse it here:
http://osm.schunterscouts.de/relation-browser.php
(the URL accepts other relations as well, comments welcome)

regards, Sven

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

Re: [OSM-talk] Voting

[Sven Grüner]

Frederik Ramm schrieb:
> But honestly, how can you  
> ever believe that a process run by less than 0.1% of participants in  
> the project can have any authority?

I can't remember that ULFL ever claimed that.

I also can't remember that anyone in this discussion has given any 
reason or example where the voting-process could harm the OSM-project. 
On the contrary, there are many Newbies who are thankful there's ONE 
tagging-sheme for one feature instead of several contrary opinions on 
what could be bad and good.

Will this discussion only end when Ulf, Robin, me and several others set 
up a separate wiki for those who want to agree on and use a consistent 
tagging sheme because they believe it's a good thing? When this project 
is so open, why are we always blamed for what we do?

regards, Sven

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

Re: [OSM-talk] OSM poll

[Sven Grüner]

SteveC schrieb:
> See the poll at the bottom right hand corner, and vote OSM:
> 
> http://www.directionsmag.com/

I think those last three words were redundant ;-)
(at least when adressing this list)

WTH would anyone want to contribute to NavTeq & Co.

Maybe I should give that some consideration after submitting my patches
for Vista SP2 as Microsoft volunteer...

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

Re: [OSM-talk] Name finder and home page search working again

[Sven Grüner]

Colin Marquardt schrieb:
> Since we have people's attention: please everybody extend
> http://wiki.openstreetmap.org/index.php/Name_finder:Abbreviations

That brought up another question to my mind, which isn't related to the
name finder in particular: Is there any agreement on how to tag
abreviated place names? When there's the 'Volkswagen plant' people would
also search for 'VW plant'. Obviously no application like the name
finder can be expected to know the abreviations of all companies and
institutions of the world. So the data should hold that information itself.

What about 'short_name', just to make that *_name list a little longer?

BTW, does name finder use loc_name and such?

regards, Sven

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

Re: [OSM-talk] Cycle lanes

[Sven Grüner]

Bjørn Bürger schrieb:
> Yes, but this is also the reality for cyclists. Everything involving
> cycleways is actually a mess, unfortunately. That is, because a
> bicycle is (mostly) not seen as an equal means of transportation.

Being considered a fanatical biker by my friends as well I share that
believe.

> But on the map, each distinct lane/track of a cycleway should
> be handled like e.g. the single lanes of a motorway/highway: Even the
> tiniest cycle-lane beneath a street has a different usage profile, 
> different size and surface, different access rules, different right
> of way, etc. than the street. So IMO it clearly needs it's own way.

I can follow that argumentation based on the fact that dual carriageways
get separate ways. But in my opinion those are just as unfortunate.
Every traffic infrastructure (ie. road) consists of certain features
which IMHO should be represented by one single object in our DB holding
information about the features it's made from. I consider it really
strange that we currently map two roads instead of one only because the
real road has the feature "hard shoulder in the middle".
Renderers can of course be trimmed to compensate all the disadvantages
that come with this strategy or mappers can be encouraged to use
relations to glue these together again but that's not really solving the
problem, but creating workarounds for every purpose it encounters.

This worked fine when focussing on car-traffic but when we really want
to provide high-quility (usable for routing/navigation) data of footways
and cycleways I'm afraid we need a different approach.

I'm not saying it's impossible by the way we do it now but I envision
there must be a better way...

> It will get easier, if support for that stuff is added to the editors.

There are people who already believe our editors are too complex (not me).

> Bjørn

You're coming to tomorrows Stammtisch?

Grüße, Sven

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

Re: [OSM-talk] Survey: Bad Map Rendering

[Sven Grüner]

Frederik Ramm schrieb:
> I'd be happy to hear from you about such "areas of bad rendering",
> whether they are bugs in there renderer(s) or just things that are
> ugly for some reason.

I'm sure you are alluding to the redundant captions of ways that are
split up for bridges or of dual carriageways. But I feel that problem
needs to be solved by both, mappers and programmers. Surely it's
possible for the renderer to analize name and ref-tags and assume that
several pieces make up one whole way but that doesn't seem right to me.
The data itself should tell that one way is a whole. Same applies to
dual carriageways where the data should tell they belong together.

Another thing that could purely be solved by code is placing additional
captions on large objects. At high zooms you often have to pan in order
to see the name of an object. Google has some kind of algorithm
repeating a caption every x meters so that's always a caption within
view. This applies to ways as well as areas (lakes).

regards, Sven

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

Re: [OSM-talk] OSMXapi

[Sven Grüner]

hi,
I also experienced this problem and was well surprised that the weekly
dump [1] of my town has increased by factor four.

After checking the file in JOSM I feel that XAPI just does not do as
descriped for the main API. The ways and nodes I got are spread all over
Europe. I even failed to figure out the relations linking them with the
object I requested, but that may be due to the (still) primitive support
for relations in JOSM.

Should my suspicion apply that will produce desastrous outputs when
relations become more popular (what I look forward to). Requesting even
the tiniest BBox will return huge amounts of data.

regards, Sven

[1] http://osm.schunterscouts.de

Daniel Taylor schrieb:
> Hi,
> 
> I had this problem the other day extracting data from the Wigan area, 
> when I looked at what was being downloaded it was data that was 
> connected/related to data that was inside the bbox I had selected. For 
> example a large primary road (one _long_ way) was included even though 
> the majority of it clearly outside of the bbox I had selected, from what 
> I have read this happens by design.
> 
> http://wiki.openstreetmap.org/index.php/OSM_Protocol_Version_0.5#About_bounding_boxes
> 
> "The following command returns:
> 
>  * All nodes that are inside a given bounding box and any relations 
> that reference them.
>  * All ways that reference at least one node that is inside a given 
> bounding box, any relations that reference them [the ways], and any 
> nodes outside the bounding box that the ways may reference. "
> 
> That might be the cause of your issues, and if so there doesn't seem to 
> be a way around it.



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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[Sven Grüner]

Frederik Ramm schrieb:
> There may be a misunderstanding on my part. I always thought that those
> who vote, by using un-qualified terms like "approved" and "not
> approved", somehow feel that their decisions have an authority that in
> the end applies to everone's mapping work, including mine. If that's not
> really what they want, but instead they just want to provide guidance to
> those who can't be bothered, then I guess that's ok with me. But we
> should really drop big words like "approved" then.

I agree with you that some terms in this process might not be optimal,
same applies to depricated. But as a non-native speaker I never thought
about that and just took these words for what they mean in this context.

On the other hand I still see that the word approve fits in here quiet
well. The question is what, how and why someone approves something. In
our context I (when voting) approve by the authority of my own opinion
that the tagging in question is making sense. That's all to it.

I consider it obvious that I'm casting my vote NOT on behalf of OSMF or
some other superhuman instance somewhere out there but just on the
authority any human has from it's birth on, his own opinion.
I also consider it obvious that nobody has any authourity or even power
about which tags a mapper may enter, regardless of what he writes in our
wiki or elsewhere.

And after a quick glance at http://dict.leo.org/?search=approve I don't
even think 'approve' is such a strong word at all. But when you're more
comfortable with 'agree' we should consider that.

regards, Sven

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

Re: [OSM-talk] Tag proposal/approval system is too heavyweight

[Sven Grüner]

Frederik Ramm schrieb:
> Decisions have to be made every day. But they can be re-decided  
> tomorrow if the need arises. As long as nobody thinks that something  
> that has been voted upon by 20 out of 20,000 project members is  
> somehow above being re-decided tomorrow, that's ok I guess.

That's what I'm taking for granted in any wiki-like project.

The approving of tags is (like anything in our wiki) just a recommodation.
When you have the desire and time to read the discussion of any tag you
use that's fine. That's why those discussion aren't deleted after the
voting closed.
But I'm not willing to read all those discussions while my desk is
covered with paper sketches and JOSM is running. Instead I'm thankful
that other people took the time to read and think about those
discussions and gave there opinion on a yes/no base allowing me to sum
up the discussion at one glance. When the outcome of such a vote doesn't
appear sound to me I'm still able to dive into the discussion and make
up my own opinion.
But on many topics I just have no clue at all and do trust those people
who have. When Gerv and other people come to a conclusion how to tag
canals I'll just use that sheme when I come along one without making up
my opinion.
It's like trusting my doctors advice. He's got the expertise I don't.
When his advice appears bogus I try another doctor or study medical
sciences myself.

When your tagging is purely based on the discussions that's fine. But
why are you against voting just because you don't use it? Especially
newbies can't be expected to spend days reading. On the contrary, they
are unexperienced in mapping and trust those who cast their vote based
on weeks/months/years of mapping.
You aren't against other people mapping features that don't interest
you, are you?

This, of course, relies on the fact that people only vote on issues they
have the knowledge to judge about. The German phrase for this is "Wenn
man keine Ahnung hat, einfach mal die Fresse halten!" ;-)

regards, Sven

Ps: Sorry about the crappy English

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

Re: [OSM-talk] Rendering power lines: black is beauty

[Sven Grüner]

Tom Chance schrieb:
> I don't think they should even be visible in urban areas like this on our
> main street map, what use are they? I can see how they would be useful for
> a walking map in sparse rural areas, but otherwise they're:
> 
> a) Not obvious (what other street map has power lines on it?)

That once again throws up the general question which purpose the
(official) maps displayed at openstreetmap.org should serve.

A) Should they be a neat, beautiful (street-) map flattering the eyes of
people who are used to the map-design of Google?

or
B) Should they be a show case of what OSM is really about, the data.
Showing off what cool features we've got that no other map supplier can
offer.

Since the rendering has great effect on what mappers do map I favour
option B. That would encourage them do make our data even richer.

Neither of these options apply to our current maps. There are many
features rendered which are pretty useless on a classical streetmap. If
I understood recent discussions correctly that's not because nobody
wants to edit the stylesheets but to avoid an overcrowded map.

The obvious solution to this seems to be layering. But I am not to judge
the technical issues of that.

regards, Sven

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

Re: [OSM-talk] area_with_holes as alternative to multipolygon relation

[Sven Grüner]

Martijn van Oosterhout schrieb:
> On Tue, Mar 4, 2008 at 12:06 PM, Dave Stubbs <[EMAIL PROTECTED]> wrote:
>>  It's feature X that's too weakly defined. The question you're really
>>  asking here is what is meant by forest? I think most people are
>>  interpreting it as an area of land covered by trees, in which case a
>>  lake is certainly not forest.
> 
> This is beginning to sound a lot like "if a road goes through a
> forest, does it split the forest in two?". Is a park with lots of
> footpaths actually many little parks separated by footpaths? You're
> right, this discussion isn't going anywhere useful :)

I remembered that as well :-)

IMHO when using forest as landuse the road doesn't split it, you are on
that road while you are in the forest at the same time. At least that's
how I do it for landuse=residential/idustiral, which aren't split by
roads either.
When there'd be something like natural=trees things would be different.
Because there's either tarmac (road) or trees. Same for lakes and other
features a landuse would encase and a more specific natural wouldn't.

I'm not sure if natural=wood was intended for this, but for me as a
German it's not as catchy as natural=trees would be. (though an explicit
explanation in the wiki could adjust that)

Same for parks. In my terms a park consists of trees, gras, benches,
ways, playgrounds and maybe even some buildings housing a cafe or public
toilets. So leisure=park wouldn't be split by ways. But natural=gras
would be limited by the features (ways) surrounding it.

So IMHO some statement like
"Natural-areas must not interfere/overlay with any other physical feature"*
could clarify this conflict.

regards, Sven

[*] Landuse isn't physical, put this way.

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

Re: [OSM-talk] area_with_holes as alternative to multipolygon relation

[Sven Grüner]

Robert Vollmert schrieb:
> On Mar 3, 2008, at 22:29, Martijn van Oosterhout wrote:
>> Hmm, I thought you could use the inner natural=water as the boundary
>> of the forest? Does this not work?
> 
> I think not. I'm pretty sure for osmarender, but may not have had  
> enough patience to test out the various combinations with mapnik.

Nah, that island is just natural=water and role=inner in a multipolygon.
The green comes from the park encasing the lake. But it only works when
drawn counter-clockwise.

http://www.informationfreeway.org/?lat=52.249&lon=10.52656&zoom=17

regards, sven

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

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

Gervase Markham schrieb:
 > Why wait so long to define best practice? We're just storing up work for
> ourselves later. When you map an area, it's just as much effort to use 
> system A as system B; but if 50% of mappers are using system A and 50% 
> are using system B, then you've just created a lot of unnecessary work 
> which could have been reduced by better communication.

Thanks Gerv, you made my point - better than I could've done.

Guidelines of good practice should be so versatile that they apply to
every situation. I'll try to correlate those with "editing conventions
and standards" in a way that "Good Practice" is just about a few short
and simple statements that define how all this should happen. While the
other page contains technical details how to put these guidelines into
action.

Bye, Sven

http://wiki.openstreetmap.org/index.php/Good_practice

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

[OSM-talk] Good practice [was: Parking symbols: YUCK!]

[Sven Grüner]

Lester Caine wrote:
> And a simple definition of good practice will remove the need for any 
> discussion when we start getting similar conflicts with church icons, or any 
> other POI.

Voilà:
http://wiki.openstreetmap.org/index.php/Good_practice

I quickly wrote those up. Anybody is invited to comment or add 'guidelines'.

Given there's no general objection I'll cross-link it in a few days time.

regards, Sven



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

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

J.D. Schmidt schrieb:
>> True.
>> I don't understand why it's so fashionable on this list to play down the
>> importance of "Map features". Without that page all those "80GB of
>> cryptic XML would be pretty useless.
> 
> Thats again because you look at the DB and the usage of the data
> contained therein as one entity that defines OSM.
> 
> If you on the other hand look at the DB and the data contained therein
> as one entity and the USAGE of the data in the DB as a seperate entity,
> you get a more correct view of the state of our wonderfull hutsputz of
> geodata and geodata usage.

I'm not talking about certain uses, I'm talking about encoding and
decoding of information using certain keys. That applies to all kind of
geodata whether it's stored in a papermap, a database or a GPX-file.
We encode the geodata we survey on the street when entering it into the
DB and we decode it again when we use it, regardless for what we use it.
The data stored in the osm-DB isn't self-explaining when it says . It would be self-explaining if we would
tag things like

That would make something like map-features obsolete (sure, an extreme
example but highway=residential could also be a street where people live
on the street, ie. the homeless or a road *leading* to a residential
area (since it's a HIGHway))

>  But that's nothing bad or something
>> we should encounter, that just the nature of any map, whether it's
>> stored in a DB or printed on colorful paper.
> 
> We (OSM) do not store a map in a DB. We store geodata.

Sorry, I used the wrong term.
In my terms a map stores geodata, ie. is geodata. Whether that geodata
is in a strict GIS-sheme on a HD or colorful lines on some paper doesn't
make a difference in the first place. When I know which
tranformation/encoding was used for reality->geodata I can read both.

> Again, look at the visualization of the data as a seperate entity -
> related to, and an important part of OSM, but not the defining measure
> of OSM.

I'm trying to. But rendering a map is just another way of bringing the
data in a different shape, which still is encoded. Stylesheets are
patient, you can draw every highway=primary with red lines. But when you
don't know what highway=primary means you aren't any smarter with those
red lines. At least here in Germany they are (like most roads) not red
but grey-black (because of the tarmac), neither do they have big labels
everywhere saying *primary*.
Ie. that tag doesn't describe the road, it's explanation on map features
does.

> An example (graphic to fit my reputation ofcourse.. You have been duly
> warned ;) ) :
> If I decided to map all the trees I have taking a leak up at on the way
> home from drinking bouts the last couple of years, I can do so. I'll
> just tag it with
>  v="200 ml used and processed beer"/>.

That's actually pretty close to my example above and pretty far apart
form what the DB looks like. Still might someone reading it expect a
tree that's urinating because of some disease which also colors it's
leaves yellow/brown. Maybe that tree secretes 200ml of beer each day ;-)

> This points out the wiki-like outlook on our DB. The tag and data has
> only mildly interest for anybody else, but it might have real value for
> me. I could be the type that tends to loose my keys everytime I take a
> leak in toxicated condition, and now I have the possibilty to see where
> I have been, and go look for them. Or maybe I'm making a map showing
> which trees not to sit under during summer.

Sure, you can use the DB to store whatever geodata you like and I'm fine
with it. You can use it just like a scrap of paper on your desk. But
that's nothing this community will bother about or what we run a wiki
for. That happens because we want to create geodata that's valuable to
everybody and not only to the mapper himself.

> Whatever the reason, it's geodata, and valid to go into the DB or the
> 80GB of cryptic XML as you called it. It might be useless for anybody
> else, but it wouldn't be to me. AND it could become usefull for someone
> else later on (urologists researching maximum distance intoxicated
> people can go between leaks, city planners looking for information on
> best placement of public restrooms, etc, etc).

But those city planners would have much less scope of interpretation if
you described your tag on something like map features.

> So as I said before, its not the rendering mechanism that should define
> what goes into the OSM DB. At the most basic level, if it is geodata,
> and can be described within the scope of  it IS valid
> for inclusion in the OSM database, no matter how "useless" it would
> appear to other users.

And that's not what we're doing, describing geodata within that scope.
Instead we're using keywords to label things and those keywords are
described in map features.

> The Mapfeatures page on the wiki is an important part, but only for "the
> second entity" - the visualization of the data. Thats why it is called
> "MAP feat

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

J.D. Schmidt schrieb:
>> TAGGING as laid out in the wiki are all rules for content but as yet they do 
>> not provide a consistent USABLE base once one moves away from the basic road 
>> stuff. And even the base road stuff people are trying to change the rules!
> 
> Correction: Tagging as laid out in the wiki is NOT rules for content IN 
> THE DB. Let me just repeat that: Tagging as laid out on the wiki in the 
> "Mapfeatures" page is NOT rules governing the content in the DB.
> 
> 
> They are recommendations, to be used if you'd like to see your content 
> rendered by the current default rendering engines used on the OSM site.
> Nothing more, nothing less.

True.
I don't understand why it's so fashionable on this list to play down the
importance of "Map features". Without that page all those 80GB of
cryptic XML would be pretty useless. But that's nothing bad or something
we should encounter, that just the nature of any map, whether it's
stored in a DB or printed on colorful paper.

A map is an abstract description of the landscape, that's what makes it
different from an aerial or plat. Someone making that description uses
certain symbols or certain code for certain features. Someone who uses
that description needs to know what every symbol/code resembles. On a
paper map that's done by the map keys which tell you whether those blue
lines are motorways, railways or maybe rivers, for OSM-data "Map
features" tell you.

Anybody can enter anything into the DB, we can't change that, we don't
want to change that and we are all aware of that. But when I (and most
other mappers as well) enter something in the DB I want other people to
know what it stands for in reality. I could use some crude tags only I
know, but what's then the point in making it accessible for the whole world.

And things like the cycle map would definitely not exist without some
kind of explanation of the relevant tage in the wiki. Without this
translation/documentation ("ncn=xyz means this way is part of a route
that...") there wouldn't be all those tags in the DB. I'm sure Andy
didn't think, well today I'm gonna render abc=xyz, maybe there are some
mappers who describe their cycleroutes just that way.

Without "Map features" OSM is like an undocumented command-line
programm: To be certain about all it's capabilities you'd need to read
every single line of code. And reading planet.osm might take a while...

regards, Sven

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

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

graham schrieb:
> In my case I have mapped many private parking areas (inside schools, 
> industrial estates, or explicitly marked 'private') as 'parking'. I 
> really don't want a parking sign to show on them as it makes them look 
> available to the public, rather than just a use of land. I realise I 
> should have marked them 'access restricted', but I didn't - and even if 
> I do now they will still be rendered with a parking sign...

I've been tagging those as access=private because Mapnik makes use of
that for quite a while now. So does osmarender.

I'm not native but the translation of amenity doesn't fit on private
parking-lots. In other words, some parking feature which isn't open to
the public is no amenity to the public. But since our mapping is by
default for the public (like most roads) should amenities that are not
open to the public always be tagged as such if mapped at all, regardless
of what it looks like now in the rederers.

regards, Sven

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

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

David Earl schrieb:
> On 23/02/2008 21:29, Andy Robinson wrote:
>> If I create a parking area I really don't want to have to place a node
>> as well so it would be better if the renderer's were clever and
>> ignored any node thats within the area where it has the same tags (eg
>> parking / name). 
> 
> Nor do I, but that wasn't the case until this week, so there are many, 
> many examples where it has been done manually, that will be a severe 
> pain and many hours of work to fix.

Vice versa. There are also many, many examples of correct tagging
without additional node. Adding some crude osmarender-tag to them will
also take many hours of work.

But the people who placed nodes inside areas, because they wanted to see
a shiny icon in the map did so in contradiction to the rule not to map
for the renderers. Or is there anything interesting (in terms of
geodata) about some random spot inside a parking-lot? So when these
people were willing to spent time in making nice icons appear to get a
beautiful map they shouldn't hesitate to make nice icons disappear to
get a beautiful map.

BUT they could also wait until there's even further improvement of the
renderers, as they should have done in the first place. There's
improvement everywhere and all the time while your argumentation seems
to claim OSM being in some kind of stable branch.

There was some hotshot-mapper in this area who tagged cafe's and delis
as tourism=attraction just to see them on the map.

regards, Sven

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

Re: [OSM-talk] Parking symbols: YUCK!

[Sven Grüner]

David Earl schrieb:
> Unfortunately removing the related node isn't going to work, because 
> Mapnik won't then render parking symbols. And it is a lot of work to do 
> that.

At least in my part of the world Mapnik does that for quite some time
now. Osmarender only measured up.

But somehow Mapnik seems to sense the additional node an doesn't display
two icons.

> In the meantime, I think osmarender should only do this if there is a 
> tag on the area (eg osmarender:symbol=yes).

I think differently. I think this is a great feature, always liked it in
Mapnik and am glad to see it in Osmarender as well now.

We had the discussion before if parking-areas should have icons on their
own or only the additional node. As this makes an explicit node obsolete
(and does a fine job doing so) I see no reason why to stick to the old
arguments.

Personally I'd like to see icons on even more areas like soccer or
tennis field, townhalls and supermarkets. Actually every feature where
the icon is now only rendered on nodes.

regards, Sven

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

Re: [OSM-talk] Slippy map - clickable POI

[Sven Grüner]

Martijn van Oosterhout schrieb:
>>  Thing is if you look at the code(line 70+) you'll see I'm manually entering
>> in the lat/lon box where each symbol appears. Not ideal, especially when the
>> POI are in the map data.
> 
> You need something on the server to get the POI data on the fly as in:
> http://dev.openstreetmap.org/~kleptog/pois/pois.html

Or as in:
http://www.lenz-online.de/divers/osm/osm5.htm

regards, Sven

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

Re: [OSM-talk] unpaved residential

[Sven Grüner]

Robin Paulson schrieb:
> On 11/02/2008, Alex S. <[EMAIL PROTECTED]> wrote:
>> Lukasz Stelmach wrote:
>>> 1. why there is (i'll answer it in a moment) unsurfaced highway while in
>>> practice every highway can have surface=unpaved?
>>
>> Highway=unsurfaced is old.  Surface=unpaved is much more recent, and
>> should be used by preference, IMO.
> 
> totally.

+1 from me.

I think we should make this a Deprecated feature as long as nobody objects.

Sven

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

Re: [OSM-talk] [OSM-talk-nl] Recent Edits

[Sven Grüner]

Sven Grüner schrieb:
> Martijn van Oosterhout schrieb:
>> I think we have a pretty good analogy here: we could ask people to
>> submit bugs by committing comments to the relevent parts of SVN. We
>> don't for pretty much the same reasons we don't want notes in the DB
>> as nodes... A seperate system like Trac is far more appropriate.
> 
> I think this error-reporting you're working on is gorgeous and will
> become a milestone in the evolution of OSM.

Just adding to the wish-list :-)

As mentioned by others is this feature only sensible in areas with a
certain degree of completion. So some kind of function allowing mappers
to unlock reporting in a certain area would be really cool. These areas
could be based on the z13 or z14 tile-grid.

When unlocking a tile the mapper claims (!=guarantees) a certain degree
of completion which lacks a little error here and there but not large
blanks. Assigning all reported errors to this mapper and notyfing him by
mail in such cases could be thought of.

regards, Sven

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

Re: [OSM-talk] [OSM-talk-nl] Recent Edits

[Sven Grüner]

Martijn van Oosterhout schrieb:
> I think we have a pretty good analogy here: we could ask people to
> submit bugs by committing comments to the relevent parts of SVN. We
> don't for pretty much the same reasons we don't want notes in the DB
> as nodes... A seperate system like Trac is far more appropriate.

I think this error-reporting you're working on is gorgeous and will
become a milestone in the evolution of OSM.

As you compared it to trac I'd like annotate a few ideas for it's
further development. Like in trac different categories of error would be
nice:
- Wrong/No name (ideally referring to the object's ID)
- Wrong position/location (dito)
- Wrong direction for oneway (dito)
- Missing feature (just referring to coordinates)*
- [?]
- other

Depending on such a classification the mapper knows what needs to be
done to confirm/correct the error. Mispellings could probably be solved
by couch-potatoes, wrong directions must be checked on-site and missing
features or wrong locations require a GPSr.

regards, Sven

* Maybe offering a dropdown with all possible features to avoid reports
like "you missed my marvellous tulip bed" :-)

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

Gervase Markham schrieb:
> 2) Making renderers which need to understand all possible units anyone 
> might use, and how to convert them into the units they want to render on 
> the map (which may or may not be the units encoded).
> 50kph -> 31.07mph -> "30mph"
> 45mph -> 45mph -> "45mph"
> 73000furlongsperfortnight -> 27.16kph -> "28kph"

Just to mention:
I don't know of any country using the metric system that is familiar
with the term "kph". The unit symbol is "km/h" and so everbody uses *kmh*.
AFAIK is "kph" an expressession from American English. And since the
folks over there aren't experts on the metric system ;-) you should be
careful joining their terminology.

just my 2ct,
Sven

Ps: KiloPerHour also wouldn't make much sense as well. That could be
thousand grams, volts, rabbits, everything.

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

Re: [OSM-talk] Render icons for parking areas

[Sven Grüner]

Knut Arne Bjørndal schrieb:
> Why not go for the automated approach? If a shape proves to be hard to
> handle for the renderer we can tune the algorithm and make it better
> for all areas at once, instead of individual contributors having to
> manually insert nodes which are nothing more than rendering hints.

I totally agree and wonder why people are so afraid of using this algorithm.

Why not just give it a try?
We're not sluggish MegaMapping Inc. When this turns out to be not
working we can disable it and within a few days time (when most tiles
are rerendered) we're where we were before - nothing is lost.

But the algorithm Knut wrote seems to be quite smart (discussion on dev
please) and is IMHO an excellent approach to keep the data free from
rendering issues.

I *propose* to implemtent this algorithm testwise!
+1

regards, Sven

Ps: Please apply this to lakes and forests as well, these are often more
fissured than parking places.

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

Sven Grüner schrieb:
> Tag them seperately! Depending on their condition and usage it could be
> footway, bridleway, track or even residential. The tracktype-tag might
> not be the best way to tag quality

...but is still widely used.
(I meant to say)

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

Re: [OSM-talk] Mapping canals

[Sven Grüner]

Hi Gervase,

first of all: OSM evolves (as steve is saying). Take on step after the
other and apply everything you've learned from the previous one to the
next. So it's not smart to do everything in the first step because then
there's nothing left to make better for the next, if you catch my drift.
(I love that phrase since "loose change" :-)

As you said this is still the start, but you should start by picking
only a couple of your points, use them for mapping, try to render them
on maps specialised for baoters and then use the experience from that to
approach the other "problems".

I will try to point out some existing tags which might do a good start
for that.

> Looking at the Map Features section for waterways, it seems that the 
> amount of detail available is insufficient. Here follows a sampling of 
> issues and queries. Should I make proposals for the following changes?

Generally speaking: yes!

> - waterway=lock_gate might be great for the Manchester Ship Canal, 
> doesn't work so well for narrowboat canals. Locks are 70ft long or less, 
> and marking the upper and lower gates individually seems unnecessary and 
> makes them harder to render. Locks also have names (e.g. "Hatton Bottom 
> Lock") which seems to make them better rendered with nodes.

There's an active proposal for that, join the discussion.

> On the other hand, canals have no direction of water flow (with a couple 
> of exceptions) but locks are directional. So one might want to indicate 
> that by using a short directional way. (But should the way point low to 
> high or high to low?) Or perhaps level tags either side of the lock, but 
> that could interact badly with bridges if this persisted along the 
> canal. (I'd expect the entire canal to have "level=-1" to make creating 
> bridges over it easier.) One might also consider "ele" either side, but 
> accurate data is hard to obtain with a GPS. Is there best practice in 
> this area?

Many sluices I know from France, Germany and Scotland have small tags
(or even carved stone) stating the height above sealevel or at least
their level-difference. You can then go and tag the nodes in the
waterway right next to the lock and give them ele-tags, according to
level-difference. If I understand this correctly is absolute height
(accuracy) of secondary importance.

> - Locks have a maximum width and length, universally measured in feet. 
> It should be possible to indicate what it is, presumably using maxlength 
> and maxwidth. Is there a danger of these being rendered with symbols 
> appropriate only for roads?

Speaking for my own: I don't see why this should cause interference with
roads. That must be a dumb routing-algorithm sending cars over canals
because of such a tag :-)
But please keep in mind that distances and height in OSM are generally
saved in meters, not in feet. If the british boaters are used to feet
the renderer would need to convert for their charts.

> - Sometimes you have a "staircase lock", where the exit of one is the 
> entrance of another. These need denoting.

The discussion in the locks-proposal are aware of that.

> - It is useful to denote the rise/fall of a lock (again, universally 
> measured in feet). There needs to be a tag for this. We could 
> appropriate "depth", but it's not actually the depth of the canal.

Is this the same as level-difference? I'm a landlubber...

> - waterway=aqueduct should surely be applicable to ways rather than nodes?

pheew... maybe that's to be discussed later

> - waterway=mooring should also be applicable to ways, so that the length 
> of the mooring can be seen. It should be possible to indicate what side 
> of the canal the mooring is on (perhaps by reference to the towpath 
> side?), and any conditions attached to mooring there (usually a maxstay, 
> measured in days, or perhaps a fee).
> 
> - Navigation on canals is done by means of bridge numbers. All bridges, 
> including those between two fields (and so with no associated road) have 
> a number. There needs to be a tag to associate a bridge number with the 
> short "bridge=yes" way.

We have the ref-tag to store all kinds of IDs. There are extensions like
int_ref, nat_ref and loc_ref or ncn_ref and so on to tell to which
network the id belongs. Mybe it would make sense to invent something
like canal_ref or some kind of abreviation.

> - Sometimes bridges which no longer exist (but you can see the remains) 
> have numbers. How could this be denoted?

Just set a node with the ref mentioned above. Maybe there will be a way
in the future to tag no-more-structures as well. There's already
historic=ruins...

> - Some bridges are swing bridges, which means they need to be moved out 
> of the way, by one of various means; these need notating. "bridge_type"?

This cries a new proposal :-)

> - All canals have towpaths. These paths are of varying quality, and this 
> information is useful to walkers and cyclists. The towpath can be on 
> either side. How should the towpath be 

Re: [OSM-talk] CLC2000

[Sven Grüner]

Lukasz Stelmach schrieb:
> Are these
> http://dataservice.eea.europa.eu/dataservice/termsofuse.asp
> terms of use acceptable for OSM so we could import those data?

I don't get the grips to that license. But the data for Germany has it's
own license, containing the following sentences:

"A transfer to third parties or any further publication of the data is
not permitted. The applicant will provide any kind of access to the data
solely to his/her own employees and/or contract partners in the
framework of the declared objectives."
http://www.corine.dfd.dlr.de/termsofuse_en.html

regards, Sven

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

[OSM-talk] voting open for url= and

[Sven Grüner]

Already trying to avoid unneccesary mails I herewith inform you about
open voting for two tags:

Links to websites (url=)


Official phonenumbers (phone=)


Regards, Sven

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

Re: [OSM-talk] voting ended? - population

[Sven Grüner]

Martin Trautmann schrieb:
> Thus I feel it is not possible to add a pouplation tag directly to a
> place.  Apart from node, way and area this would require yet another  data
> primitive, such as data

Why not KISS (keep it stupid simple)? Like David I've been using this on
dozens of places just by instinct.

Accuracy:
The numbers I've put into OSM are what I would have said in personal
conversation, like 260,000 instead of 263,814. When looking on a map
stating the population (many German Topo-maps do so) I don't see why
someone would want to know it down to the person. It's just to get an
idea of the place.

Being up-to-date:
When rounding the numbers as shown above you're still quite close when
the population changes to say 255,000. And even when ten years pass and
it drops to 220,000 I (as map user) would not bother about the offset.
But surely the tag would've been updated many times, remember that
people here are even willing to tag construction sites. And BTW
population changes on a daily basis and even the local administration
won't know the exact figures with better that a few percent accuracy.

So I will keep on tagging rounded population figures, because I consider
them useful.

regards, Sven

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