Re: [OSM-talk] Landuse areas etc. abutting highways
I'm seeking advice as to best practice in the following type of situation: As an increasingly common example, now that people are getting around to mapping areas such as leisure=, natural= and landuse= ... Consider the case of landuse=farm on one side of a highway (say a secondary road) and leisure=golf_course on the other side of the highway. The easiest way to map this - and the one usually adopted it seems - is to make the boundaries of the farm and the golf course both coterminous with the highway so that the three lines are superimposed in the editors (not quite sure how the various renderers handle this) and the representation of the highway has zero width. There are, however, potential problems with this (quite apart from the slightly clumsy editing when several ways are superimposed) where detailed mapping would ideally show that in real life the golf course and the farm do not in fact have a common boundary but both are, for example, separated by hedges (which may or may not be mapped) from the road. It is clearly possible to map the farm and the golf course as separated areas with the road mapped as a line drawn between them - i.e. the mapping has three separate parallel lines. This assists with mapping more clearly features such as junctions of paths with the road (and stiles on paths at such junctions). But is this unduly messy or does it create rendering issues (e.g. if the lines are not absolutely parallel and just far enough apart to render with random gaps between, say, the golf course and the road. The situation is even trickier where, say, a farm has been mapped as a single area (same land use) with, say, a road crossing it - whereas in practice, this is two separate farms - one on each side of the road - that may at some stage need to be named separately. Then we have to go back and split the area, etc. This seems to be a quite a generic issue and I am wondering how people see the pros and cons of (a) the simple approach with coterminous lines giving a notional zero width to the highway, vs. (b) the more precise approach of mapping the areas either side of the highway as areas that are separate both from each other and from the highway. In practice, almost all mapping seems to use approach (a) - but would approach (b) be easier for subsequent editing and addition of detail, and rather clearer as it avoids superimposed ways and potential editing errors? Views? IMO (a) is the correct way to do this. We are trying to represent reality in our database. In order to achieve this, certain abstractions are necessary. For a road, we can either choose to map it as a linear object (this is the common case), or we can map its geometry more exactly by using an area. In both cases, however, the object in our database represents the entire road (i.e. not only the middle line). Because in reality, there is no gap between the road and the areas next to it, there shouldn't be one in the database either. In other words, we should keep the topology intact, even if we choose to simplify the geometry. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
For a road, we can either choose to map it as a linear object (this is the common case), or we can map its geometry more exactly by using an area. In both cases, however, the object in our database represents the entire road (i.e. not only the middle line). Because in reality, there is no gap between the road and the areas next to it, there shouldn't be one in the database either. In other words, we should keep the topology intact, even if we choose to simplify the geometry. This would be hard to do properly render in the renderers, as they will render the road with non-zero width and to render things correctly, they should push the boundaries of touching landuses so they will touch the rendered road borders. It is IMHO easier to learn renderers to support proper width tag and add that tag to the street between. With proper micro-mapping, even the street between could be mapped as an area, but that could be perhaps a bit too much of detail. But a) could be used as acceptable temporary solution until someone with better information (like having aerial photography) remaps it as b) Yes, this is basically what I wanted to say. Leave it to the mappers whether they want to use a way or an area for a road. But with option (b) and a linear way you would have a gap next to the road. In the case of landuse, this is not a problem in practice, but if there is a place, there you need to insert artificial ways that are not there in reality, just to get the connectivity between the two objects: http://osm.org/go/0JUKytHID-- -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Landuse areas etc. abutting highways
Original-Nachricht Datum: Mon, 5 Oct 2009 15:28:54 +0200 Von: Martin Koppenhoefer dieterdre...@gmail.com An: Marc Schütz schue...@gmx.net CC: MP singular...@gmail.com, talk@openstreetmap.org Betreff: Re: [OSM-talk] Landuse areas etc. abutting highways 2009/10/5 Marc Schütz schue...@gmx.net: But a) could be used as acceptable temporary solution until someone with better information (like having aerial photography) remaps it as b) Yes, this is basically what I wanted to say. Leave it to the mappers whether they want to use a way or an area for a road. it will be much harder to add this detail, if all areas are merged though. Not really. JOSM supports disconnecting ways since a long time now. But anyway: doing things wrong just to make editing easier is not a good thing. But with option (b) and a linear way you would have a gap next to the road. In the case of landuse, this is not a problem in practice, but if there is a place, there you need to insert artificial ways that are not there in reality, just to get the connectivity between the two objects: http://osm.org/go/0JUKytHID-- which objects are you referring to? parkings usually have those ways (for crossing the sidewalk) so they won't be artificial, and pedestrian areas are the exception I mentioned above. Look at the google sat image: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37.0625,-95.677068sspn=59.856937,107.138672ie=UTF8hq=hnear=Bayreuth,+Bayern,+Deutschlandll=49.946316,11.577148spn=0.000754,0.001635t=kz=20 As you can see, there are no ways between the road and the plaza on the left side. But there are in the database (e.g. the one at the end of Alexanderstraße). This is an ugly hack to reenable routing, which was broken by letting the plaza end before the street. (And I don't even want to start about the situation on the other side of the road.) Mapping it the way it is done there does not really make sense: Either the exact geometry is important for you, then you should convert both the plaza and the road to areas. Or it isn't, but then there shouldn't be a problem with extending the plaza so that it borders to the road. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] JOSM Vorlage Spielstraße
Wäre es möglich, dass in der Vorlage Spielstraße fest die Geschwindigkeit Schrittgeschwindigkeit bzw. walk eingestellt ist. Nein, bitte nicht schon wieder. Nur explizite Geschwindigkeitsbegrenzungen sollten getagged werden. Ich stoße immer wieder beim bearbeiten von Spielstraßen living_street auf maxspeed=30. Wer so fährt hat wohl nicht mehr lange Freude an seinem Führerschein... ;-) Gegenvorschlag: einen Test für den Validator/OSMI, der bei highway=living_street mit maxspeed=... meckert. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
On Wed, Sep 30, 2009 at 10:36:21AM +0200, Marc Schütz wrote: Wäre es möglich, dass in der Vorlage Spielstraße fest die Geschwindigkeit Schrittgeschwindigkeit bzw. walk eingestellt ist. Nein, bitte nicht schon wieder. Nur explizite Geschwindigkeitsbegrenzungen sollten getagged werden. nein, bitte nicht schon wieder! walk ist der einzige sichere und explizit eindeutige wert; mit irgendwelchen ableitungen ist keinem geholfen! Ich glaub du hast mich falsch verstanden: ich bin nicht gegen walk an sich, wenn es irgendwo explizit geschrieben steht. Ich bin aber generell dagegen, implizite Geschwindigkeitsbegrenzungen zu taggen, d.h. kein maxspeed=walk, wenn nicht explizit auf einem Schild Schrittgeschwindigkeit fahren! steht, genausowenig wie jede Straße innerorts maxspeed=50 kriegen sollte. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
Ich glaub du hast mich falsch verstanden: ich bin nicht gegen walk an sich, wenn es irgendwo explizit geschrieben steht. Ich bin aber generell dagegen, implizite Geschwindigkeitsbegrenzungen zu taggen, d.h. kein maxspeed=walk, wenn nicht explizit auf einem Schild Schrittgeschwindigkeit fahren! steht, genausowenig wie jede Straße innerorts maxspeed=50 kriegen sollte. Das steht explizit auf dem Schild Verkehrsberuhigter Bereich, Blödsinn. Auf dem Schild http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_325.svg steht überhaupt kein Text. da dessen Bedeutung eine Höchstgeschwindigkeit von Schrittgeschwindigkeit für alle Fahrzeuge enthält. Bedeutung ... enthält = implizit -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] JOSM Vorlage Spielstraße
Blödsinn. Auf dem Schild http://de.wikipedia.org/w/index.php?title=Datei:Zeichen_325.svg steht überhaupt kein Text. Schön dass du deine Behauptung, auf dem Schild stehe das explizit drauf, auf die sich das Blödsinn offensichtlich bezogen hat, nicht mitzitiert hast. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] The French Corine Import has started
I am sending a quick message to mention that the French import of Corine has started. We created an user for the occasion: http://www.openstreetmap.org/user/CLCF06 ... Shouldn't the attribution (source) go into the changeset? I don't know what the current consensus about this is. AFAIK a bot is removing these things from the TIGER data in the US right now. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3.5 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] OSM auf Deutsch
Dort werden internationale Empfehlungen erarbeitet und verabschiedet. Die wichtigsten: 1. grundsätzlich sollen Endonyme verwendet werden, also Ortsnamen sind so zu schreiben, wie sie in den dortigen Ländern geschrieben werden: München, Praha, Beijing 2. für die verschiedenen Schriften soll eine gegenseitige Umschrift erfolgen, damit die Endonyme auch für Dritte lesbar sind. Für uns also eine Umschrift der nichtlateinischen Schriften in eine lateinische, bzw von unserer Schrift in die wichtigsten nichtlateinischen. 3. wenn, dann sollen Exonyme nur in Klammer hinter dem Endonym angegeben werden. ... Um Namen in einem deutschen Rendering politisch korrekt zu verwenden ist m.E. insbesondere die Regel 1 und 3 anzuwenden. Unklar hingegen ist mir, wie die Regel 2 in OSM so umgesetzt wird, dass in der DB die Umschreibungen so in einem Schlüssel erfasst werden, dass sie vom Renderer auch eindeutig wiedergefunden werden. Ich finde, die Karten sollten sich an der Realität orientieren und nicht an politischer Korrektheit. Besonders die Regeln 1 und 3 widersprechen der Realität häufig. Bei Prag würden diese zu Praha (Prag) führen. Dies suggeriert, dass Praha der hauptsächliche deutsche Name der Stadt wäre, und Prag nur ein ebenfalls gebräuchlicher. Tatsächlich ist das Gegenteil der Fall; Praha werden die meisten deutsch-sprachigen Menschen allerhöchstens passiv verstehen, aber nicht aktiv gebrauchen. Mein Gegenvorschlag: - Auf der Karte sollte - sofern vorhanden - immer name:de erscheinen, ggf. mit dem Endonym in Klammern. - name:de sollte nur gesetzt werden, wenn der deutsche Name heutzutage auch tatsächlich in Gebrauch ist; ansonsten sollte old_name oder old_name:de verwendet werden, je nachdem, ob der deutsche Name damals der Hauptname war oder nicht. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Seoul
This looks also very nice: http://www.informationfreeway.org/index.php?lat=37.5760761lon=126.97864158zoom=13layers=BF000F Looks like a font size issue in the renderer. No, the problem is the hundreds of place=town. Most of these should probably suburbs. Besides that, there are also a lot of amenity=arts_centre (even more than place=town). These also look suspicious. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Küstenlinie automatisch aus Landsat-Bi ldern extrahieren?
Sie bestehenden Küstenlinien wurden AFAIR mit einem Script erstellt (zumindest am Anfang). Nein, die sind von irgendwo importiert worden (USGS?) und in vielen Gebieten inzwischen von Hand verfeinert worden. Ob es da jetzt ein besseres Script gibt weiss ich allerdings nicht (oder ob man ggf, nur die Parameter / die Auflösung ändern muss, das aber damals für die ganze Welt zu viel gewesen wäre). Auf das Lakewalker-Plugin wurde ja bereits hingewiesen. Keine Ahnung, ob das Tool auch mit Küstenlinien-Ausschnitten, die ja nicht geschlossen sind, umgehen kann. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
This brings up an interesting question, when you're finding the nearest junction to use for stop key on a node, what counts as a junction? It's going to be a node which belongs to the current way and at least one other way satisfying certain conditions, but what are those conditions? If we are to use the stop key, I think those conditions will need to be explicitly spelt out, so that you can process the data. It would have to be ANY junction, I think (the nearest node that belongs to more than one way, as you say). There should be as little dependence on other tags as possible. Otherwise - a maintenance nightmare... Note that by requiring a junction, you make it impossible to model stop signs don't involve a junction. I don't know how frequent these occur, but I can imagine cases where there is a sharp curve before which you're required to stop. And I believe there are roads near airports with low-flying plains crossing the road, thought these are usually regulated by traffic lights. (Just for the sake of completeness.) Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Sind sie. Den Bereich prüfe ich sehr häufig. Wenn man einen Knoten nimmt, der näher an der Bahnstraße liegt, nimmt er eine andere Route: http://tinyurl.com/l3pj25 maxspeed=50 habe ich hinzugefügt. maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Sagt wer? Wie stellst du fest das du innerorts bist und 50 fahren musst? landuse=residential != geschlossene ortschaft boundary=administrative != geschlossene ortschaft Maxspeeds werden so getagged wie sie gelten und ausgeschildert sind, im oder auch explizit ... Die frage ist lediglich ob wir statt 50 irgendwelche dinger wie DE:citylimit oder aehnliches setzen ... Das ist eben keine Frage; nur das letztere ist eine akzeptable Lösung, wenn wir die Probleme vermeiden wollen, die in der letzten zu diesem Thema geführten Diskussion ausführlich erörtert worden sind. Wie das genau zu geschehen hat, dafür gibt es wohl noch keine einheitliche Lösung, aber das heißt nicht, dass wir stattdessen Workarounds anwenden sollten, die uns eine saubere Lösung in Zukunft verbauen. Ich möchte die Diskussion nicht schon wieder führen müssen; die Argumente von damals haben sich ja nicht geändert. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Umgehungsstraße vs. Landstraße
Am Donnerstag 27 August 2009 14:46:19 schrieb Bernd Wurst: Hallo. Am Donnerstag, 27. August 2009 schrieb Marc Schütz: maxspeeds sollten nur getaggt werden, wenn sie explizit ausgeschildert sind. Bei Straßen innerorts ist das meistens nicht der Fall. Falsch. Es gibt viele diskussionswürdige Ansätze, aber es absichtlich *wegzulassen* wäre wirklich dumm. Die Verfechter von kein maxspeed=50 können das jederzeit durch ihren bevorzugten Tag des Tages ersetzen, aber so lange keine Information über die Eigenschaft des Innerorts vorliegt, fehlt eine Info. Nein können sie nicht, weil man dem maxspeed=50 dann nicht mehr ansieht, ob es explizit oder implizit ist. Das alles ist bis zum Erbrechen diskutiert worden; auch diese Behauptung wurde dabei widerlegt. Ich werde deshalb ab jetzt in diesem Thread nicht mehr antworten, es sei denn es werden neue Argumente gebracht. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] New dimension of vandalism
Dieter and any other supporter of the concept is free to start a proposal to change the most important tag of all. But please stay in the common conventions for such an important change and give *all* users the chance to vote, and do not make changes on the wiki because of an agreement of few persons on the mailing list(s). But the point is that the users already have voted by the way they actually use the highway tag. What dieterdreist did was just change the wiki to match the reality, so that it is actually useful as a documentation. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Das ist doch keine Länderabkürzung, sondern eine *Sprach*abkürzung? Insofern wäre ISO 639-1 relevant, ist auch so auf Key:name dokumentiert. Bei Dingen wie dem DE:urban-Vorschlag von vor einer Weile liegt die Sache übrigens anders, das sind *Länder*abkürzungen und daher in groß richtig. note:DE = deutscher Text ist für mich identisch mit name:DE = deutscher Name Wie gesagt: Es ist meine Tagging-Variante und meine Schule. Niemand muss sich danach richten. Bist du sicher, dass du seine Frage richtig verstanden hast? Es geht nicht um eine Parallelität zwischen note:xx und name:xx, sondern darum dass DE = Deutschland und de = Deutsche Sprache bedeutet (nach der ISO-Norm, auf die du dich berufen hast). name:DE wäre dann ein Name, der nur innerhalb Deutschlands gültig ist. -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Announcemen: Multilingual Country-List
Still I think a case could be made for country names to be different: most of them are so prominent that I would say they exist in most languages, even if they are identical to the native names. For example, the German names for most European countries are different from their native names. However, Portugal happens to have the same name (well, spelling) in German and in Portugese. Would you therefore say, that Portugal doesn't have a German name? It has one, but that's not a translation - rust a repetition. And name:xx-tags are (in my opinion), basically translation-tags. Nevertheless I don't like different rules for similar things, so i don't want to have a different rule for countries as for cities. It's a rule in quotation marks, because no one forces you to remove those tags and if you want to add them for a language, i won't go and delete them. Well, the common rule for both cities and countries would then be: If it has a name in language xxx, then add a name:xxx tag (and don't care if it has the same value as name), else leave it. Although this basically follows from the on the ground rule, it would probably be very subjective to decide. Anyway, I don't have a strong opinion on this anymore. As you and Martin have pointed out, it will probably make no difference in practice, as name will be taken as a fallback. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Announcemen: Multilingual Country-List
But this implicates that if there is no different name, no name:xx-tag should be set (even if it's not *bad* to have one, its also not *necessary*). Do you agree with that, Marc? I was replying in a hurry, and I see now that it is not as easy as I thought it to be. I agree that most objects don't have names in all languages. It would be absurd to add a, say, Inuktitut name to a small street in Budapest, thereby repeating its hungarian name in potentially several thousand languages. Still I think a case could be made for country names to be different: most of them are so prominent that I would say they exist in most languages, even if they are identical to the native names. For example, the German names for most European countries are different from their native names. However, Portugal happens to have the same name (well, spelling) in German and in Portugese. Would you therefore say, that Portugal doesn't have a German name? Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
You seem to be implying that increasing the amount of data in OSM is a bad thing??? Increasing the amount of _implicit_ data surely is. There are good reasons, why putting implicit data into databases is usually avoided. Of course, llama access restrictions probably aren't a top priority, but it IS a GOOD THING to have llama restrictions in the database. The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. But in most cases they are locally consistent, thus it makes sense to simply assume different defaults for different countries/jurisdictions. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Fwd: Re: Proliferation of path vs. footway]
The core issue here (that I believe we agree on) is that if tags have inconsistent implications, they must be made explicit. Absolutely true: explicit in the wiki ;-) I don't think the wiki is a good place for that. Keep in mind that these defaults would be nice to have in a machine-readable format. They could be stored in the DB, too. Maybe this would be an extension for API 0.7: a way to express the defaults (and implications) for various tags depending on the country. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proliferation of path vs. footway
It's not about allowing cycling(like official fooways that _also_ allow bicycles as guests), it's about official designation. This makes, at least in Germany, a big (legal) difference... So you could tag a footway which also allows bicycles as highway=footway,bicycle=yes(assuming footway implies foot=designated) or as highway=path,foot=designated,bicycle=yes. No Information loss, no difference, no problem. :-) ... except that many people don't like your assumption and interpret it as foot=yes instead. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] to all potlatch and JOSM users - automatic simplification of geometry
Am Samstag 08 August 2009 14:42:43 schrieb Martin Koppenhoefer: An example from the result of the current tidy-points-function here: http://trac.openstreetmap.org/attachment/ticket/2148/090808_potlatch_tidy-p oints_.png In this case it looks more like an error of the tidy-function, or at least it having wrong parameters. Most of the nodes in the back of the linkway are indeed collinear and can probably be removed without loss of precision. Personally, I almost never use this function. There were a few cases where someone seems to have converted a GPX track, or where it was clear that the excessive amount of nodes was wrong, because I knew the concerning area. Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
no, it's not, it's about relative order in the db. Fair enough. In other words, at any node which is a junction of way segments with different layers (whether the segments are part of the same way or different ways), the physical implication is that the slope of the way changes in the close vicinity of that node. Not even that: it only says something about the relative ordering, not about slope. Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
On Friday 31 July 2009 17:25:19 Richard Mann wrote: I saw some strange rendering effects when a side road was straight onto a bridge. The bridge was layer=1, so the side road was rendered on top of the main road. That's why all the ways approaching a junction should be on the same layer. You can either achieve this by inserting a short way between the bridge and the junction, or by altering the layer of the thing that is bridged (ie making the stream layer=-1) Recently we have been discussing this problem on the Dutch talk list regarding bridges. Keepright doesn't like T-juntions with different layers and tags these as 'not so obvious' errors. The reasoning that we map the centre of the road is faulty. That reasoning implies that we need to split up the road because the sidewalk does not either continue to the centre of the crossing road. +1 It was always my view that the way is simply an abstraction of the entire road, not only its centre. Adding a little piece of road so the junction can be on one layer just does not make sense. In Amsterdam there are lots of bridges and canals. The canals there are physically not on the same layer as the road and bridges. But for practical reasons we only add layer tags where ways cross without connecting (bridge over water). This 'T-junction rule' is causing just about every bridge to have small extra bits added. Or have roads that do not cross anything tagged as layer=1. On the discussion list the argument is made that we don't need a layer tag for bridges and tunnel (except of course when there are more than two ways above/under each other) and I agree with that. So simply removing the layer tag on most tunnels and bridges would resolve the layer issue. However I am not sure if it is generally accepted that it is wrong to tag a bridge or tunnel with a layer attribute. Please don't do that. On the wiki (and the mailing lists) there are also strong arguments against implied layer. Layer should be kept as simple as it can be, and this also means keeping it as an independent feature that doesn't change its default value depending on other tags. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] restriction=school_zone (second email)
problem if you insist on not putting values in the key? How would you say maxspeed is 40 between 7am-9am, 60 between 4pm-7pm, and 80 otherwise? It's going to get very messy very quickly if you are trying to shoe horn general time limits in with school zones But that's the point! We need a way of modelling more complex cases anyway, so why do you want to special case school zones? Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] restriction=school_zone (second email)
Original-Nachricht Datum: Fri, 7 Aug 2009 02:55:05 + (GMT) Von: John Smith delta_foxt...@yahoo.com An: m...@koppenhoefer.com, Roy Wallace waldo000...@gmail.com CC: talk@openstreetmap.org Betreff: Re: [OSM-talk] [RFC] restriction=school_zone (second email) --- On Thu, 6/8/09, Roy Wallace waldo000...@gmail.com wrote: maxspeed[school_days][08:30-09:30]=40 Except that is putting values on the key side of things. To do things properly you would need something like this. maxspeed:school_zone=40 maxspeed:school_zone:on=08:30-09:30;14:30-15:30 No, you're still putting a value on the key side (the reason). To really handle this properly, I would suggest using a relation: type=property maxspeed=40 when=08:30.../school_days/whatever reason=school_zone This would the apply to all members of that relation. And it is general enough that you could use it for anything you like, not only for restrictions. Its meaning is simply, that all the tags on the relation should apply to all its members. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] restriction=school_zone (second email)
But that's the point! We need a way of modelling more complex cases anyway, so why do you want to special case school zones? School zones are a special case because they don't operate all year round, and you need to store school terms in addition so you can calculate if the school zone is in effect. Let me rephrase the question: if it is possible to devise a tagging scheme that is able to model all relevant restrictions we encounter in reality including school zones (and I believe it is possible), why do you still want a seperate tagging scheme for the latter? Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Landratsamt will OSM
Wenn ich die Karte auf dem Navi benutze hab ich plötzlich mehrere Jugendherbergen mit Namen Stintfang. Da fehlt die datenaufbereitung... Nein, da sind die Daten falsch. Wenn es nur eine Jugendherberge gibt, darf sie nicht zweimal eingetragen werden. Ganz abgesehen davon, dass sich das gar nicht automatisch rausfiltern lässt: Wie erkennt man, welche Einträge zusammengehören und welche nicht (besonders wenn die fraglichen Objekte keinen Namen haben)? Welcher Eintrag ist der richtige oder Haupteintrag? Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Landratsamt will OSM
Da fehlt die datenaufbereitung... Nein, da sind die Daten falsch. Wenn es nur eine Jugendherberge gibt, darf sie nicht zweimal eingetragen werden. Ganz abgesehen davon, dass sich das gar nicht automatisch rausfiltern lässt: Wie erkennt man, welche Einträge zusammengehören und welche nicht (besonders wenn die fraglichen Objekte keinen Namen haben)? Welcher Eintrag ist der richtige oder Haupteintrag? Dann braucht die Anwendung eben eine Option die auswählbar macht was angezeigt werden soll (z.B. POI oder Gebäudebezeichnung). Ein Universalrenderer der alle Daten gleichzeitig lesbar und schön darstellt geht eben nicht. Es geht nicht um eine Anwendung, sondern um automatische Datenaufbereitung. Und die ist nicht möglich, wenn die Daten das nicht zulassen. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] geteilte Fahrrad- Fußwege mit path
wer kennt das allgemeine Tagging für die vertikale Variante Ich empfehle, path nur zu verwenden, wenn _keine_ blauen schilder aufgestellt sind. Bei vertikaler teilung verwendet man: highway=cycleway foot=yes traffic_sign=z241 bei horizontaler: highway=cycleway foot=yes traffic_sign=z240 wenn dann bitte foot=designated und nicht nur foot=yes +1 Außerdem schadet es nicht, gleich noch bicycle=designated dazu zu setzen. highway=cycleway wird ja mal als bicycle=designated, mal als bicycle=yes interpretiert. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] tagging roads
Am Sonntag 02 August 2009 11:49:11 schrieb Blaž Lorger: On Sunday 02 August 2009 10:59:08 John Smith wrote: --- On Sun, 2/8/09, Blaž Lorger blaz.lor...@triera.net wrote: I also propose extending instructions for road classification to use width tag I agree with everything else you wrote except width since I really don't want to get a tape measure out and measure widths of roads, using lanes=* to estimate widths would be more sensible and is already in use. Unfortunately lanes only specifies number of lanes. In general every road that is not one way has at least 2 lanes, even if it is narrow, say 3.5 meters. Yes, but equally unfortunately width only specifies width, and not the number of lanes. Therefore, it would be nice to have both. Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Landratsamt will OSM
Am Sonntag 02 August 2009 07:18:34 schrieb Karl Eichwalder: Bernd Wurst be...@bwurst.org writes: Am Samstag, 1. August 2009 schrieb Karl Eichwalder: Du schuldest immer noch eine Angabe über den Grund für deine etwas obskure Meinung, dass doppelte Daten etwas besonders gutes wären! (Park-)plätze ohne highways sind mist. Hallo Kontext? Ist eben auch so was, wo man in einem polygon noch ein objekt benötigt. Das geht völlig an der ursprünglichen Frage vorbei. Der Parkplatz und die Wege darin sind unterschiedliche Objekte, deswegen sollen sie natürlich beide eingetragen werden. Aber gleichzeitig den Parkplatz als Fläche _und_ als Node einzutragen ist redundant. Übrigens ist es keineswegs immer trivial, den mittelpunkt eines polygons sinnvoll auszurechnet. Bei Fürth macht der damals nur als polygon eingetragene MD-kanal einen schönen bogen, was dazu führte, dass die beschriftung kilometerweit weg in der stadt zu finden war (bei stadtmauern ist ähnliches denkar) - hier im schema sieht es ok aus, aber auf einem plan mit anderen objekten zusammen ist so etwas doch eher befremdlich: Das ist wahrscheinlich ein ausschließliches Renderer-Problem. Aber selbst wenn es nicht praktikabel ist, das im Renderer zu implementieren (z.B. weil es keine effizienten Algorithmen dazu gibt), ist die Lösung bestimmt _nicht_, das entsprechende Objekt zweimal einzutragen, sondern z.B. die vorgeschlagene Label-Relation zu verwenden. Doppelte oder irgendwie redundante angaben sind bei uns notwendig, weil wir aus durchaus nachvollziebaren gründen keine verpflichtenden tagging-vorgaben haben. Non sequitur. Sie sind deswegen allerhöchstens zulässig, aber nicht notwendig. Aber da wir durchaus verbindliche Regeln haben (z.B. die on the ground rule), ist selbst das zweifelhaft. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Layer transitions
to make my question more precise, please have a look at this tunnel that crosses a railway track (the railway is a subway that runs at ground level): http://www.openstreetmap.org/edit?lat=48.1325961lon=16.3109488zoom=19way=29205957 The tunnel tag implies layer=-1 No, it doesn't. and that leads to a junction of ways on different layers on both ends of the tunnel. Which wouldn't be a problem either. Layer is only relevant for defining the relative order of intersecting (crossing) objects. If the objects don't intersect, or have a common node, their layers don't imply anything about their relative or absolute height. On the western end of the tunnel the adjacent way ends, this should be no problem with the layers; on the eastern end there is a T junction. Do you think, this tunnel is OK the way it is or should someone add a small piece of way on layer 0 at the eastern end next to the T-junction to avoid a T-junction of different layers? It is ok as it is. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
Wrong, osm2pgsql does process relations properly. If they aren't then Jon Burgess is happy to take a look to see if he can fix the problem with osm2pgsql. Second there has been no planet reload for a few weeks now. There's definitely something wrong here: http://www.openstreetmap.org/?lat=49.93906lon=10.9213zoom=17layers=B000FTF The building called Angewandte Informatik is a multipolygon, which has been moved one and a half weeks ago. Both the old and the new shape are rendered now, and the hole is filled too. I know that there have been problems with multipolygons and diffs. Are they supposed to be fixed? Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Something Might be Broken
The building called Angewandte Informatik is a multipolygon, which has been moved one and a half weeks ago. Both the old and the new shape are rendered now, and the hole is filled too. I know that there have been problems with multipolygons and diffs. Are they supposed to be fixed? Please file a trac ticket with the details and assign it to me. Lots of issues have been fixed but there are still several possible reasons why things some times don't work correctly. It takes time to analyse, diagnose fix each example. Done: http://trac.openstreetmap.org/ticket/2116 BTW, the link I gave was wrong; here is the correct one: http://www.openstreetmap.org/?lat=49.926286lon=11.585866zoom=18layers=B000FTF Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
I want to talk about this page on the wiki describing how to map tunnels correctly: http://wiki.openstreetmap.org/wiki/Tunnel#How_to_Map Especially the last paragraph causes headaches to me: If the tunnel ends in a junction you'll need a small un-tunneled way between the end of the tunnel and the junction Where does this rule come from? this might be a logical topic: we are mapping the center of the road. The tunnel can not end at the center of the crossing road, because this road itself is not a tunnel. (you will have at least half the width of the crossing road untunneled). No, IMO we're mapping the entire road, but represent it by a line located at the middle. This is a subtile but important difference; otherwise we wouldn't connect the incoming ways at a crossing, because they end at the edge of the road, not in the middle. But I agree that in most cases there is a short way between the T junction and the tunnel/bridge, although I have encountered cases where a bridge started directly at the other road (give or take a few millimeters). I think we should insert a in most cases into this rule. Regards, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Layer transitions
this might be a logical topic: we are mapping the center of the road. The tunnel can not end at the center of the crossing road, because this road itself is not a tunnel. (you will have at least half the width of the crossing road untunneled). No, IMO we're mapping the entire road, but represent it by a line located at the middle. This is a subtile but important difference; yes, I agree with this, but it doesn't IMHO extend the tunnels beyond their real extension. I personally wouldn't think: the tunnel starts right at the crossing and therefore I map it like this, but I would rather think: the tunnel starts at this projected point that is half the width of the crossing road away. otherwise we wouldn't connect the incoming ways at a crossing, because they end at the edge of the road, not in the middle. why not? Who tells you that the road ends at the edge and not in the middle? If both roads continue on both ends, would you say that the center (crossing) belongs to neither road because they both end at the edge? I would say it belongs to both roads. Maybe not in all cases, but have a look at this example: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37.0625,-95.677068sspn=59.467068,107.138672ie=UTF8ll=49.935936,11.646567spn=0.000375,0.000817t=kz=21 It'd be hard to argue that the incoming track does not end at the edge of the road, but goes on to the middle. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Plätze im städtischen Bild - wie tag gen?
Wenn wir schon dabei sind: gibt es einen Tag für eine benannte Straßenkreuzung? Es sind keine Bäume auf diesem Platz, grad mal eine Verkehrsinsel: http://maps.google.com/maps?f=qsource=s_qhl=degeocode=q=bayreuthsll=37.0625,-95.677068sspn=59.467068,107.138672ie=UTF8ll=49.950302,11.572034spn=0.001498,0.00327t=kz=19 Dieses Gebilde nennt sich Berliner Platz. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Tagging einheitlich wie immer mit name:de=xy name=offizieller Name in Landessprache Man sollte dann noch unterscheiden zwischen dem deutschen Namen, dem Namen im Zeichensatz des jeweiligen Landes und der internationalen Transliterierung. Für die Transliteration sollte m.E. int_name verwendet werden. Leider ist dort allzu oft der englische Name untergebracht. Aber das ist niemandem vorzuwerfen, da es für die Transliteration bisher noch keine Tagging-Empfehlung gibt. Ich habe da leider auch keine Lösung. Noch einen neuen Namen-Namensraum fände ich doof. translit_name auch seltsam. Vorschläge? Hier gibt es schon einen Vorschlag im Wiki: http://wiki.openstreetmap.org/wiki/Transliteration_code Streng genommen handelt es sich dabei nicht um Transliteration, sondern Transskription, da erstere bei logographischen Schriften gar nicht möglich ist. Auf der Diskussionsseite zu Multilingual names gibt es auch noch einen Beitrag dazu: http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names Und natürlich gibt es das RFC4646, das die Kombination aus Angaben für Sprache, Schrift, und Region regelt, z.B. ru-Latn. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
m.E. nein, da Königsberg halt wirklich nur der old_name ist, und daher sollte m.E. selbst in einer deutschen Karte Kaliningrad stehen (auch wenn man dt. Namen angefordert hat). In einer historischen Karte sollte da Königsberg (Kaliningrad) stehen. in diesem Fall wäre das richtige Tagging daher: name=Kaliningrad old_name=Königsberg name:de=Kaliningrad Das ist doch Unfug. Kaliningrad ist kein deutscher Name. Es ist maximal die lateinische Schreibweise. Der deutsche Name ist Königsberg. Zu entscheiden ob und in welcher Weise dieser noch gebraucht wird ist nicht die Aufgabe von OSM. Solange er überhaupt gebräuchlich ist und bei Königsberg ist dies eindeutig der Fall. Wenn es der im deutschen übliche Name ist, ist es ein deutscher Name, selbst wenn er russischen Ursprungs ist. Ich hab den Eindruck, dass Kaliningrad öfter verwendet wird als Königsberg, und letzteres eher mit dem Zusatz ehemals. Dass wir das feststellen (nicht entscheiden!) müssen, ergibt sich schon aus unserem Anspruch, die Realität abzubilden, denn die Unterscheidung zwischen aktuellen und ehemaligen Namen in verschiedenen Sprachen ist ja durchaus real. Statt also wilde Taggingregeln zu erfinden um die Karte politisch korrekt erscheinen zu lassen sollte lieber die Darstellung so angepasst werden, dass für jede Sprache die relevanten Namen angezeigt werden. Das wird insbesondere bei vielsprachigen Ortsnamen schwierig werden. Die einzige Möglichkeit, das einigermaßen richtig hinzukriegen, ist, die dafür notwendigen Informationen in der DB zu haben. Dafür, und nicht um die Karte politisch korrekt erscheinen zu lassen, ist dieses wilde Taggingschema eingeführt worden. -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Tagging einheitlich wie immer mit name:de=xy name=offizieller Name in Landessprache Man sollte dann noch unterscheiden zwischen dem deutschen Namen, dem Namen im Zeichensatz des jeweiligen Landes und der internationalen Transliterierung. Für die Transliteration sollte m.E. int_name verwendet werden. Leider ist dort allzu oft der englische Name untergebracht. Aber das ist niemandem vorzuwerfen, da es für die Transliteration bisher noch keine Tagging-Empfehlung gibt. Ich habe da leider auch keine Lösung. Noch einen neuen Namen-Namensraum fände ich doof. translit_name auch seltsam. Vorschläge? Hier gibt es schon einen Vorschlag im Wiki: http://wiki.openstreetmap.org/wiki/Transliteration_code Streng genommen handelt es sich dabei nicht um Transliteration, sondern Transskription, da erstere bei logographischen Schriften gar nicht möglich ist. Auf der Diskussionsseite zu Multilingual names gibt es auch noch einen Beitrag dazu: http://wiki.openstreetmap.org/wiki/Talk:Multilingual_names Und natürlich gibt es das RFC4646, das die Kombination aus Angaben für Sprache, Schrift, und Region regelt, z.B. ru-Latn. Nachtrag: Von int_name halte ich nicht viel (nicht nur zur Transliteration). Zumindest aus dem Wiki geht nicht hervor, für was der eigentlich genau gut sein soll. An was erkennt man denn den internationalen Namen, z.B. von Rom: Rom, Rome, Roma, Rzim, Erroma, an Róimh, Rim, Rzym, Room, Romma... Welcher davon ist jetzt _der_ internationale Name? Der englische? Oder die Form, die in den meisten Sprachen benutzt wird? Oder irgendwas, was in einem Standard definiert wurde? -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracktype=grade1
ich kenne das (als ursprünglich Baden-Württemberger) auch aus den neuen Bundesländern: war schon erstaunt, wieviele Feld- und Waldwege da nicht nur nicht gesperrt sind, sondern auch zu vereinzelten Grundstücken und Bungalowsiedlungen führen. Die Wege sind aber klar Wirtschaftswege, keine Straßen. Nur dass da dann halt mitten im Wald irgendein FDJ-Freizeitheim liegt, das mittlerweile aufgeteilt und privatisiert ist. Teilst du auch noch die Kriterien mit uns, die dich annehmen lassen es handle sich trotzdem noch um einen Feld-/Wald-/Wirtschaftsweg und nicht um sevice bzw. unclassified? Nur so können andere beurteilen ob Dein Ergebnis auf tragfähigen Argumenten beruht. Ich kann es jedenfalls nicht nachvollziehen. Weil ein Feldweg eben ein Feldweg ist. Er wird weder zum highway=service, wenn dort ein Haus hingebaut wird, noch wird er wieder zum highway=track, wenn ein dort stehendes Haus abgerissen wird. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM auf Deutsch
Am Donnerstag 23 Juli 2009 20:15:34 schrieb Tim Alder: Hallo, ich wollte nur mal in die Runde fragen, wie man mit der möglichen politischen Brisanz eines deutschsprachigen Renderings umgehen kann. Bei den meisten Sprachen und den meisten Orten wird das sicher unkritisch sein, ich denke da aber an die Orte in Polen und Tschechien die nur bis 1945 den deutschen Namen trugen. Also Königsberg, Breslau und z.B. eine Kleinstadt namens Schneidemühl. Auf den meisten deutschen Papierkarten schreibt man da den heutigen Namen und darunter in kleinen Buchstaben und in Klammern den deutschen Namen. So mit den alten Namen könnte die Karte halt etwas reaktionär wirken. Besonders auffällig ist es, wenn sich die Wortstämme komplett unterscheiden. Vielleicht gibt es ja eine Idee wie man diese kritischen Fälle einheitlich taggen könnte. Weltweit gibt sicher noch aktuellere Problempunkte. Ich glaube, die meisten Probleme lassen sich durch geschickte Unterscheidung zwischen name, name:de, old_name und old_name:de lösen. name ist dabei immer der aktuelle vor Ort übliche Name, und old_name ein ehemaliger vor Ort üblicher Name. name:de ist dementsprechend der aktuelle im Deutschen gebrauchte Name, old_name:de wäre ein früher im deutschen gebrauchter Name, der aber oft überflüssig ist, weil er mit old_name identisch ist. Ein paar Beispiele: Für Breslau ist wohl auch heute noch die deutsche Bezeichnung üblich, so dass ich so taggen würde: name=Wrocław old_name=Breslau name:de=Breslau Für dein Beispiel Schneidemühl, dessen deutscher Name heute wahrscheinlich nicht mehr gebräuchlich ist: name=Piła old_name=Schneidemühl name:de=Piła Wahrscheinlich kann man in diesem Fall name:de auch ganz weglassen. Für Fälle wie Warschau, welches m.W. wohl schon immer traditionell polnisch- sprachig war: name=Warszawa name:de=Warschau In diesem Fall entfällt das old_name, da identisch mit name. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen kann manchmal wichtig und rich tig sein (war Routerhärtetest )
ja, in diesem Fall sollte man den einzelnen Node löschen und das Gebäude mit den tags versehen. Das sollte man nicht, weil man damit anwendungen kaputtmacht, die gebäude (noch) nicht auswerten. Man sollte vielmehr die renderer bzw. den präprozessor fixen. Wenn ein POI (node) in einem gebäude liegt und den gleichen namen hat, sollte nur ein name dargestellt werden, Ich würde den des POI bevorzugen. Man sollte auf keinen Fall den Knoten _und_ das Gebäude taggen. Jedes Feature in der Realität sollte nur _einmal_ in der Datenbank drin sein. Wenn ein Programm mit diesem einfachen Grundsatz nicht zurechtkommt, ist das nicht unser Problem. -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Löschen kann manchmal wichtig und rich tig sein (war Routerhärtetest )
Man sollte vielmehr die renderer bzw. den präprozessor fixen. Wenn ein POI (node) in einem gebäude liegt und den gleichen namen hat, sollte nur ein name dargestellt werden, Ich würde den des POI bevorzugen. Man sollte auf keinen Fall den Knoten _und_ das Gebäude taggen. Jedes Feature in der Realität sollte nur _einmal_ in der Datenbank drin sein. Das stimmt bei datenbanken im allgemeinen, aber nicht mehr solchen wildwuchsprojekten wie OSM. Eine gewisse redundanz in den daten ist bei uns geradezu überlebensnotwendig. Nein, sie ist schädlich. Wenn ein Programm mit diesem einfachen Grundsatz nicht zurechtkommt, ist das nicht unser Problem. Du bist schon lustig ;) Genau andersrum wird ein schuh draus. Manche kinder brauchen etwas länger, um schwimmen zu lernen. Deswegen nimmt man denen aber noch lange nicht die schwimmflügel weg, nur weil ein paar andere die nicht mehr brauchen... So etwas nennt man auch rückwärtskompatibel. Und warum genau das eine schlechte Idee (zumindest in unserem Stadium), hab ich mich schon mehrmals drüber ausgelassen (siehe Archiv). -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Problem With Trails
Regarding the duplicates - it must be because the bulk upload using Balrogg's upload.py sometimes fails part way through because the server closes the connection. But if it doesn't appear in the list of edits under my name then I assumed that no data was stored. The changeset shouldn't have been closed. Changesets aren't transactions, they are only a collection of independent (atomic) edits. If you don't close the changeset, the API will automatically do it for you after a certain amount of time, and your edits will not be rolled back. They should, however, appear in the list of your edits. Regards, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Pferdestall
Was mache ich aber mit dem eigentlichen Reitstall? building=yes + horse=yes? Damit könnte man dann ja auch einen Kuh (cow=yes) oder Schweinstall (pig=yes) taggen :) horse=yes würde ich nicht nehmen, weil das schon für Zugangsberechtigungen (reiten erlaubt/verboten) in Benutzung ist. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Schweiz und Südtirol
Eine Route ist die Verbindung zwischen zwei Wegweisern. Wegweiser haben hier (meistens) einen Namen und referenzieren sich somit gegenseitig. Das ergibt zusammen mit den Markierungen eine ausgeschilderte, objektiv verfolgbare Route. Dann reduziert sich das Problem schlichtweg darauf: Eigentlich wollen wir das Gleiche. Nur mit unterschiedlichen Tags. Für Dich heißt es in Deiner Beispielrelation: note = Staubern-Kastensattel name = fehlt Für mich ist das ein Mißbrauch von note [1], da es keine ergänzende Mitteilung für Mapper/Bearbeiter ist sondern eine handfeste Kennzeichnung der Relation. Doch, es ist eine Mitteilung an den Mapper, dass es sich um den Wanderweg Staubern-Kastensattel handelt. Aber wenn du meinst, dass das nicht da reinpasst, solltest du es trotzdem nicht in den name-Tag schreiben. Namen sind für mich so etwas wie Jakobsweg, Via Mala etc. Viele Wanderrouten haben so etwas einfach nicht. Das was du verwendest, ist aber eher eine Beschreibung. Wenn ich dich richtig verstanden habe, brauchst du das ja sowieso nur, um die Relation von Hand in eine Liste aufzunehmen, damit sie gerendert wird. Warum renderst du nicht automatisch alle Routen? Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Schweiz und Südtirol
Namen sind für mich so etwas wie Jakobsweg, Via Mala etc. Viele Wanderrouten haben so etwas einfach nicht. Das was du verwendest, ist aber eher eine Beschreibung. Nein. Wenn auf der Wandertafel oder auf dem Wegweiser oder im Verzeichnis der Wanderwege steht Wanderweg nach XXX dann ist das der Name des Weges. Wenn Menschen ihn so nennen, um sich zu verständigen, dann ist es der Name des Wegs. Nein. Wenn ich eine Tierart ein schwarz-weiß gestreiftes pferdeähnliches Säugetier nenne, um mich zu verständigen, ist das eine Beschreibung, genauso wie Wanderweg nach XXX. Der Name der Tierart wäre Zebra (aber sie könnte genausogut auch keinen Namen haben). Umgekehrt: Wenn das alles nur Hinweise sind, dann ist Jakobsweg auch kein Name eines bestimmten Weges, sondern nur der Hinweis auf die Zugehörigkeit zu einem bestimmten Wegenetz. Beim Jakobsweg trifft das mit dem Wegenetz vielleicht zu, aber die Via Mala bezeichnet genau einen Weg zwischen zwei Orten. Andere Beispiele sind die diversen Rennsteige. Wenn es zwischen zwei Orten A und B mehrere Routen gibt, dann sind das alles Wanderwege von A nach B. Aber jeder davon kann einen anderen Namen haben. Wenn ich dich richtig verstanden habe, brauchst du das ja sowieso nur, um die Relation von Hand in eine Liste aufzunehmen, damit sie gerendert wird. Das hast Du falsch verstanden. Warum renderst du nicht automatisch alle Routen? Weil das nicht automatisch geht: 1. Die Symbole müssen beim Großteil der Routen von Hand eingetragen werden. Auch mit osmc:symbol müssen die Fehler in den Tags korrigiert werden Aber beides doch in der OSM-Datenbank, nicht in einer externen Liste, oder? 2. Ohne Namen kann ein Weg nicht in das Wegeverzeichnis eingetragen oder von irgendjemand wiedergefunden werden. Damit kommt man nicht mehr an die Zusatzinformationen (Wegverlauf, Betreiber, Länge, Wiki/Weblinks) ran. Da gibt es verschiedene Möglichkeiten: man könnte für diesen Zweck ein neues Tag erfinden, oder man könnte eine Bezeichnung generieren (route=hiking, symbol=Roter Kreis = Wanderweg Roter Kreis bei Heidelberg). Oder zuerst Namen, dann ref, dann selbsterzeugte Bezeichnung probieren. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/atbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Datenstand bei OpenRouteService.org
in letzter Zeit sind mir verstärkt seltsame Stellen bei der Routenplanung von openrouteservice.org aufgefallen. Mal wurden Wege und Straßen nicht berücksichtigt, mal lag die Route ein Stück neben dem Weg oder der Straße. Wenn ich mir an diesen Stellen die history der betroffenen Wege anschaue, komme ich zu dem Schluss, dass die Daten mittlerweile für osm-Verhältnisse ziemlich alt sind; ich schätze das Datenalter im Moment auf etwas über 3 Wochen. Laut wiki sollte eigentlich jeden Dienstag eine Aktualisierung durchgeführt werden... Was ist da los? Leider ist auch seit einiger Zeit der Menüpunkt News verschwunden, so dass man nicht mehr feststellen kann, wann die letzte Aktualisierung erfolgt ist. Grüße, Marc -- Jetzt kostenlos herunterladen: Internet Explorer 8 und Mozilla Firefox 3 - sicherer, schneller und einfacher! http://portal.gmx.net/de/go/chbrowser ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Species names
No real opinion on the question whether to use the scientific names or not, but if you do, please do _not_ use name:la for that purpose, because this would be how the ancient romans (or the speakers of Modern Latin) call the animals. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Kindergarten
Dann hoffe ich mal darauf, dass die Renderer entsprechend angepasst werden. Momentan wird die amenity=Kindergarten als Gebäude dargestellt, oder jedenfalls als oberster layer. Building=yes auf demselben Gelände scheint nicht durch, dafür werden die Straßen teilweise verdeckt, und die Einfärbung entspricht auch den Gebäuden (und der Namefinder findet sie nicht). http://www.openstreetmap.org/?lat=53.64181lon=10.03891zoom=17layers=0B00FTF Im Zentrum, Gelände Hummelsbüttler Hauptstraße 72A, Mikuteit Kann es sein, dass es am building=no liegt? Wahrscheinlich hat der Mapnik eine Regel, die alle building=* als Gebäude interpretiert... Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zwei OSB-Seiten?
habe ich gestern mal mit gespielt und hatte meine Probleme: Karte sprang wild hin und her, Bug-Marker waren an falscher Stelle, Zoom-Regler war nicht in sync mit dem tatsächlichen Zoom. Das kann ich bestätigen, auch wenn es nur sehr selten passiert. Manchmal bleiben bestimmte Marker beim Zoomen an der Stelle stehen, wo sie im vorherigen Zoomlevel waren. Das passiert meistens bei neu angelegten Bugs, ich habe es aber auch schon bei bestehenden erlebt (dann gleich bei mehrere auf einmal). Browser: FF 3.0.11 (nicht sicher, obs bei 3.5 auch passiert) Grüße, Marc -- Neu: GMX Doppel-FLAT mit Internet-Flatrate + Telefon-Flatrate für nur 19,99 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Projekt Postleitzahlen
Am Sonntag 21 Juni 2009 03:36:03 schrieb Mirko Küster: Ticket habe ich nicht aufgemacht. Von jemand anderes habe ich nur gehört das diese bekannt sei und einer etwas ungenaueren Programmierung in OSM liegt. Da ich kein Programmierer bin, kann ich dazu nichts sagen. Und Tickets überlasse ich denen die Englisch können. Die Koordinaten werden in der Datenbank soviel ich weiß als 32bit-Integer gespeichert. WIMRE führt das zu einer Genauigkeit von ca. 10-20cm. Könnte es daran liegen? Punkte auf einen Meter genau festzulegen dürfte aber dann trotzdem kein Problem sein. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] cutting and embankment on only one side
Am Freitag 12 Juni 2009 17:28:55 schrieb Rolf Bode-Meyer: is there any known way to give a attach cutting or embankment to a way only on one side? Besides from highways having a batter on only one side, my main need for it would be wide features like a canal running on a dam including ways to the left and to the right. There is this proposed feature: http://wiki.openstreetmap.org/wiki/Proposed_features/right_left Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-ca] [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
I think the definitions really don't belong in the the data -- perhaps if you want to see them, your browser should look them up in some table rather than load from the data. +1 It should be sufficient to keep the canvec:UUID, source and attribution tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we would need most of the others. If someone is really interested in them, they can look them up in Canvec using the UUID. created_by should be removed, too. This is better moved into the changeset. One could even argue that source belongs there, too. Regards, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-de] User: Kraftfahrstra?e Edit-War
Achja, wie verfährt man mit einer Straße, die am einen Ende per VZ 267 gesperrt ist, jedoch am anderen Ende kein Einbahnstraßenschild hat und in der auch alle Eingeborenen in beiden Richtungen umherfahren? Bisher habe ich mich damit beholfen, am verbotenen Eingang fünf bis zehn Meter Einbahnstraße zu deklarieren. Das hab ich früher auch so gemacht; jetzt wo wir Relationen haben, benutze ich Abbiegevorschriften dafür. Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Lake Cowichan Now loaded (more of sample 092c area)
I think the definitions really don't belong in the the data -- perhaps if you want to see them, your browser should look them up in some table rather than load from the data. +1 It should be sufficient to keep the canvec:UUID, source and attribution tags, and maybe a few of the other canvec:* (CMAS?). I don't see why we would need most of the others. If someone is really interested in them, they can look them up in Canvec using the UUID. created_by should be removed, too. This is better moved into the changeset. One could even argue that source belongs there, too. Regards, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] forest wood und Layer
Zu der Problematik landuse in landuse u.ä. ist hier vor kurzem ein Ticket aufgemacht worden: http://trac.openstreetmap.org/ticket/1953 Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] forest wood und Layer
Zu der Problematik landuse in landuse u.ä. ist hier vor kurzem ein Ticket aufgemacht worden: http://trac.openstreetmap.org/ticket/1953 wobei das hier m.E. nicht relevant ist, da parks kein landuse sind (bei OSM), sondern leisure. Doch, das passt schon. Ich hätte es nur allgemeiner formulieren sollen: Fläche in Fläche. Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] accessibility mapping and OpenStreetMap
Am Samstag 13 Juni 2009 06:09:32 schrieb Mikel Maron: Anyone working on accessibility projects with OpenStreetMap? Please get in touch, would like to talk more. Maybe you could contact the users in this category: http://wiki.openstreetmap.org/wiki/Category:WheelchairRoutingContributor AFAIK, especially Astrid and Lulu-Ann are active in this project, though they are probably not subscribed to this list. Regards, Marc signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Bicycle boulevards
In my eyes, that road would be simply tagged with highway=cycleway. These streets are completely analogous to highway=pedestrian, just for bicycles. If pedestrian streets deserve their own highway type, these do too. Regards, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[Talk-de] area und Wegrichtung
Wie wendet man richtungsabhängige Tags (z.B. oneway) auf Straßen an, die mit area=yes getaggt sind? Soll ein zusätzlicher einfacher Weg angelegt werden, der die entsprechenden Attribute kriegt, analog zu Flüssen? Welche Tags sollen dann auf diesen Weg, welche auf die Fläche? Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] area und Wegrichtung
Wie wendet man richtungsabhängige Tags (z.B. oneway) auf Straßen an, die mit area=yes getaggt sind? Soll ein zusätzlicher einfacher Weg angelegt werden, der die entsprechenden Attribute kriegt, analog zu Flüssen? Welche Tags sollen dann auf diesen Weg, welche auf die Fläche? areas haben per se keine Richtung. Wenn da zusätzlich ein Way mit einer Richtung ist (z.B. oneway), würde ich das auch als solchen zeichnen, wie Du ja auch vorschlägst: extra Way. Die Tags jeweils an den passenden Way hängen. Was ist denn konkret die Sache, die Du darstellen / eintragen willst? Konkret geht es darum, dass ein Benutzer den Fußgängerteil der Richard-Wagner-Straße in Bayreuth in eine Fläche umgewandelt hat: http://www.openstreetmap.org/?lat=49.942973lon=11.579238zoom=18layers=B000FTF Dieser ist jedoch auch eine Einbahnstraße (wahrscheinlich für Lieferverkehr zu bestimmten Uhrzeiten; ist noch nicht getaggt). Leider geht dadurch eben diese Richtungsinformation verloren. Bei Flüssen wird aus dem Grund ja zwischen den Umrissen (waterway=river_bank) auch noch ein linearer Weg mit waterway=river angelegt. Prinzipiell ist dieses Verfahren hier auch möglich, ich bin mir nur nicht sicher, wie dann der lineare und der flächige Weg getaggt werden müssen. Erhalten beide das highway-Tag? (Wohl schon.) Erhalten beide oneway=true? (Eher nicht.) Was ist mit name, access, usw.? Grüße, Marc -- GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] area und Wegrichtung
Am Mittwoch 10 Juni 2009 16:09:28 schrieb Martin Koppenhoefer: Am 10. Juni 2009 15:51 schrieb Tobias Knerr o...@tobias-knerr.de: Martin Koppenhoefer schrieb: inwiefern ist es für das Routing ein Problem, wenn es 2 anstatt einer Möglichkeit gibt? An einer der 2 Möglichkeiten kann man die Einbahnstraßeneigenschaft nicht sinnvoll unterbringen (weil eine Fläche keine Richtung hat). Daher wird die Straße weiterhin in beide Richtungen befahrbar sein. daher sollte man ja auch die Erlaubnis für Lieferverkehr nur an den einzelnen way, nicht an die area hängen. Das funktioniert aber erstens nicht im allgemeinen Fall, und zweitens ist es eigentlich falsch, weil auf der Fläche der Lieferverkehr genauso fahren darf. Man bräuchte entweder eine Möglichkeit, einem flächigen Objekt eine Richtung zu geben, oder umgekehrt, einem linearen Objekt eine Fläche zuzuordnen. Vorschlag: Relation type=outline Member way = ein linearer Way (oder vielleicht mehrere?) Member outline = geschlossener Way, der die Fläche beschreibt Der Outline-Weg bleibt wohl im Normalfall ungetaggt; Renderer können dann die Attribute vom Hauptweg übernehmen, und Router können ihn ignorieren. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] meinungsbild botlauf für geordnete rel ationen - was: Neuigkeiten von der ÖPNV-Karte
Am Mittwoch 10 Juni 2009 17:30:29 schrieb Frank Sautter: hallo zusammen, Jochen Topf schrieb: On Wed, Jun 10, 2009 at 01:30:25PM +0200, Rolf Bode-Meyer wrote: Wie mache in eine Linienrelation also ordered? Das ist leider etwas schwierig und eigentlich sollte das auch automatisiert geschehen (Frank Sautter wollte sich das glaube ich mal anschauen). Wobei das nur dort automatisch gefixt werden kann, wo die Reihenfolge eindeutig ist. nachdem seit der api 0.6 relationen geordnet sein können und es von verschiedener seite die anforderung gibt, würde ich gerne hören, ob es einwände gegen eine automatische sortierung der ways anhand ihres anfangs- und endnodes gibt. später könnte auch noch eine geographische sortierung von teilstücken einer route erfolgen, bei der es noch lücken gibt. ebenso könnten einzelne, neben den ways liegende nodes geografisch sortiert werden. das ganze soll eher defensiv programmiert werden, sodass bei nicht eindeutig zu lösenden fällen die relation nicht angefasst wird, sondern im logfile eher als problemfall zur händischen bearbeitung markiert wird. Es sollte auch nur Relationen betreffen, bei denen die Sortierung überhaupt relevant ist. D.h. Routen, Buslinien ja, (advanced) Multipolygons m.W. nicht. Also lieber nicht auf Verdacht alle gefundenen Relationen sortieren. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] FreieTonne - Seekarteninformationen/ Seezeichen nach OSM kopieren
tag k=minzoomlevel v=9/ Das wird wohl dafür verwendet, um eine Art von Wichtigkeit für die einzelnen Objekte festzulegen. Es ist wahrscheinlich besser, stattdessen mehrere objektive Eigenschaften anzugeben. Beispiele: - warnt das Seezeichen vor Gefahren, oder dient es nur zur Information? - wieviel Verkehr herrscht auf der jeweiligen Wasserstraße? Dann können die Auswertungsprogramme (meistens Renderer) selber entscheiden, was für ihren speziellen Anwendungsfall am wichtigsten ist, und dieses dann entsprechend ab einem niedrigeren Zoomlevel darstellen. Grüße, Marc -- GRATIS für alle GMX-Mitglieder: Die maxdome Movie-FLAT! Jetzt freischalten unter http://portal.gmx.net/de/go/maxdome01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNV-Workshop
Das Problem ist eher noch das Mitgliederhandling: Bei einer Linienrelation muss man die Mitglieder sortieren. Das ist bisher häufig nicht der Fall, weil das vor 0.6 ja nicht ging. Ist aber schwierig zu sehen, wenn man den Relation-Editor offen hat, wo die verschiedene Mitglieder sind. Das könnte der Editor von alleine machen. Es müsste dafür eine Liste von Relationstypen angelegt werden, mit Informationen darüber, ob automatisch sortiert werden soll, und ob Elemente doppelt vorkommen dürfen. -- Nur bis 31.05.: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate und Telefonanschluss nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] How to tag small city alley ?
And I guess it should be rather highway=service than highway=residental. That changes rendering a bit too (it is narrower in Mapnik IIRC). What was that again with the don't tag for the renderer meme? :-) It's clearly a public road so you shouldn't use highway=service here. The description page for highway=service [1] states: This is also commonly used for access to parking, driveways, and alleys. So this is within the intended use of highway=service, especially in combination with service=alley [2]. [1] http://wiki.openstreetmap.org/wiki/Tag:highway=service [2] http://wiki.openstreetmap.org/wiki/Key:service -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] tracks in osmarender (16-17)
Für z12-z14 bin ich zum Mapnik-Stil übergegangen, da man da anders gar nix mehr erkannt hat und nix zu optimieren ging... Diesen Stil finde ich generell ziemlich gut; die Tracks und auch die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege (besonders letztere): http://www.openstreetmap.org/?lat=49.895lon=10.9201zoom=14layers=0B00FTF Das sieht alles aus wie ein hellgrüner Brei, man muss sich schon sehr konzentrieren, um die einzelnen Wege auseinanderhalten zu können. Wenn man rauszoomt, wirds noch schlimmer. Bei den Feldwegen (z.B. weiter nördlich in dem großen Kleingartengebiet vor Hallstadt) kommt mir das nicht so schlimm vor, deswegen vermute ich, dass es an der grellen Farbe liegt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Daneben wird es noch mässige Geschwindigkeit, Ortsgeschwindigkeit, Richtgeschwindigkeit,etc. geben. Warum willst Du verhindern dass man auf Anwendungen mit OSM quasi verzichten muss die darauf aufbauen dass man für jeden Streckenabschnitt einen expliziten Geschwindigkeitsgrenzwert hat - und das nicht nur die nächsten paar Wochen? Damit hat man eine saubere Schnittstelle zwischen Datensammlung und Applikation. Die Applikation muss nicht unbedingt wissen wie der Wert zustande kam (welche aktuelle Gesetzgebung, Land,...) Und auf der Datenbankseite kann man Prüfmechanismen loslassen die die plausibiltät des Wertes prüfen. *gähn* Vorverarbeitung *gähn* ... (zum x-tausendsten mal) Und über das Warum bist du auch schon oft aufgeklärt worden. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Am Freitag 22 Mai 2009 21:04:11 schrieb Garry: Marc Schütz schrieb: Daneben wird es noch mässige Geschwindigkeit, Ortsgeschwindigkeit, Richtgeschwindigkeit,etc. geben. Warum willst Du verhindern dass man auf Anwendungen mit OSM quasi verzichten muss die darauf aufbauen dass man für jeden Streckenabschnitt einen expliziten Geschwindigkeitsgrenzwert hat - und das nicht nur die nächsten paar Wochen? Damit hat man eine saubere Schnittstelle zwischen Datensammlung und Applikation. Die Applikation muss nicht unbedingt wissen wie der Wert zustande kam (welche aktuelle Gesetzgebung, Land,...) Und auf der Datenbankseite kann man Prüfmechanismen loslassen die die plausibiltät des Wertes prüfen. *gähn* Vorverarbeitung *gähn* ... (zum x-tausendsten mal) Ja ich weiss dass Du dafür nichts besseres zu bieten hast... Und das von einem, der lieber unbedingt was schlechteres durchsetzen will... Und über das Warum bist du auch schon oft aufgeklärt worden. Wie kann man über etwas Aufklären was man nicht versteht? Natürlich, die Leute haben alle keine Ahnung, von was sie reden. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Richtung von Ways - Digitalisierungsrichtung (was: Fahrradwege)
Im naechsten Schritt sind, wie bei einem API-Versionswechsel, auch alle Editoren und sonstige Werkzeuge anzupassen, so dass einige Tags wie oneway=... und wenn man sich auf left/right, forward/backward bezieht, diese beim Drehen des Weges ebenso automatisch gedreht werden ... oder eben eine Warnung erscheint. Wenn alle, die dieses Argument bei jeder Gelegenheit vorbringen nur je eine Zeile Code schreiben wuerden, haette JOSM schon lange eine Info-Box, die einen warnt sobald man einen Weg dreht, bei dem irgend ein key oder irgend ein Wert left/right oder forward/backward enthaelt. :) Diese Funktionalität existiert bereits seit geraumer Zeit. Das betrifft oneway sowie alle Schlüssel, die mit left, right, forward und backward anfangen. Wenn man so einen Weg umdreht, kommt ein Dialogfenster, das vorschlägt, die Tags entsprechend mit umzudrehen. Man braucht nur noch auf Anwenden klicken. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-aktionspreis/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
das einzige was wirklich definiert ist, ist der wert schrittgeschwindigkeit! ganz einfach, kein aufwand. ... und technisch nicht verwertbar Oder erklär mir mal wie Du einer Maschine beibringst dass sie mit Schrittgeschwindigkeit durch einen verkehrsberuhigten Bereich fahren soll... Ganz einfach: man gebe der Maschine eine konkrete Geschwindigkeit vor, die in der jeweiligen Jurisdiktion/Umgebung als Schrittgeschwindigkeit akzeptabel ist. Um das zu können, muss man natürlich erstmal wissen, dass Schrittgeschwindigkeit gilt, und nicht 7 km/h. in der stvo steht der wert kein limit, warum also irgendeine an den haaren herbeigezogene zahl benutzen?!? weil bei Lichtgeschwindigkeit bereits alles hinter Dir ist was Du wahrnimmst - Klarer Verstoss gegen §3... Man soll eine an den Haaren herbeigezogene Zahl verwenden, weil bei LG bereits alles hinter einem ist!? -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map - Kompromissvorschlag
Ganz einfach: man gebe der Maschine eine konkrete Geschwindigkeit vor, die in der jeweiligen Jurisdiktion/Umgebung als Schrittgeschwindigkeit akzeptabel ist. Um das zu können, muss man natürlich erstmal wissen, dass Schrittgeschwindigkeit gilt, und nicht 7 km/h. Ja klar - ganz einfach formuliert - über die Umsetzung musst Du Dir ja keine Gedanken machen, dass Problem hast Du ja ganz einfach - abgewälzt. Ganz und gar nicht. Ich hab eine Lösung für das Problem angegeben: in die Datenbank kommt das was in die Datenbank gehört, und in die Anwendung kommt das was in die Anwendung gehört. Aber das haben dir schon genug Leute erklärt. So wird aus einer einfachen, zweckmässigen und schnell umsetzbaren Problemlösung ein riesen Projekt mit vielen schwer lokalisier- und schwer behbaren Fehlerquellen. Lieber eine Lösung mit möglichen Fehlerquellen als eine, die von vornherein falsch ist. Es ist ein bewährtes Vorgehen in der Technik dass man Wertebereich auf die realistisch vorkommende Werte einschränkt um u.a. Fehler leichter erkennen und gegebenfalls beheben zu können. Genau. Realistisch vorkommende Werte sind z.B. 100, 80, walking_speed, none, etc. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sonderzeichen beim Import von Daten
Negernb?tel 4 - ich hoffe das kommt bei Euch richtig rüber ! Kann mir einer sagen wie ich diese z.b. unter Notepad ++ abspeichern muss damit JOSM die Umlaute richtig annimmt. Keine Ahnung welchen Charset JOSm verwendet aber ich würde pauschal UTF-8 vermuten, also die Datei als UTF-8 speichern. Der Zeichensatz ist normalerweise in der ersten Zeile des XML-Files deklariert, typischerweise als UTF-8: ?xml version='1.0' encoding='UTF-8'? Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer Weg-Style
Beim rendern von tracktype=gradex sah man m.E. kaum die Unterschiede auch nicht mit den Mittellinien, die irgendwann mal eingefuehrt wurden. Habe daher an den Strichstaerken geschraubt und zudem die Strichlierung des Randes geaendert, damit es besser zur Strichlierung von Mapnik passt, damit man nicht immer umdenken muss... ;-) http://daten.mueck.de1.cc/osm/grades-z15.PNG zeigt ein Beispiel, bei dem ich ie tracktypes auch noch reingemalt habe zur Orientierung. Oben am Rand und links sieht man auch noch Bereiche mit altem Rendering. Also ICH sehe im Wald keine Unterschiede der grades beim alten Rendering... Unterschiede: alt: grade1 = grau durchgezogenes casing grade2 = braun durchgezogen grade3 ff = braun strichliert in div. Varianten neu: grade1 = braun durchgezogen grade2 = braun strichliert, Strich laenger als Luecke grade3 = braun strichliert, Strich kuerzer als Luecke grade4 = braun strichpunktiert grade5 = braun punktiert ohne grade = braun strichliert mit sehr kurzer Luecke, also zwischen 1 und 2 Zu sehen in http://daten.mueck.de1.cc/osm/surface_rendering2.PNG Zoom level 15 gefaellt mir ganz gut, ich glaube, ich kann den core in 16 und 17 wieder leicht breiter machen, in: http://daten.mueck.de1.cc/osm/grades-z16.PNG http://daten.mueck.de1.cc/osm/grades-z17.PNG werden die Wege fast schon zu aufdringlich, oder? Ja, ich finde die sind zu dick. Das fällt besonders auf, wenn man sie mit den anderen Wegen vergleicht. Das erweckt den Eindruck, dass die Feldwege wichtiger sind als normale Straßen, oder irgendwie absichtlich hervorgehoben sind. http://www.openstreetmap.org/?lat=49.9213lon=10.88064zoom=17layers=0B00FTF Um die Erkennbarkeit im Wald und anderen landuses zu gewährleisten, wäre es evtl. möglich, den weißen Rand zwischen dem Casing und der Umgebung auf 2-3 Pixel zu erhöhen, und dafür die Linien wieder dünner zu machen? Es gibt im übrigen noch eine kleine Hässlichkeit (die wahrscheinlich schon vorher existiert hat, aber jetzt mehr auffällt): http://www.openstreetmap.org/?lat=49.96052lon=11.5715zoom=17layers=0B00FTF Der Feldweg zum Morethsgut und das Stück, das von dort aus Richtung Wald weitergeht, wird von abzweigenden Feldwegen niedrigerer Ordnung überdeckt. Mit surfaces und smoothness fuer alle highway-Arten bin ich nicht ganz so zufrieden... http://daten.mueck.de1.cc/osm/surface_rendering.PNG http://daten.mueck.de1.cc/osm/surface_rendering2.PNG Man erkennt die Unterschiede kaum, mit mehr Strichstaerke waere es wohl zu prominent, mehr Groesze der Symbole geht auch nicht, da die dann groeszer als die Wegbreite werden, ... Die Farben, die die smoothness bedeuten sollen (von blauelich-gruen fuer excellent ueber gelb und rot zu dunkellila fuer impassable) erkennt man auch kaum... In den Beispielen sieht man umgedrehtes Kopfsteinpflaster ;-) fuer ground und ein Muster fuer gravel auf den anderen Wegen, vereinzelt auch grass (ueber dem Kanalweg im 1.), auf den besseren asphalt und auf dem 2. auch paving_stones Sehr schade eigentlich; es wäre schön, wenn sich eine Lösung für die Oberfläche finden würde. Das Tag ist fürs Behinderten- und Fahrradrouting relativ wichtig, und es ist erfahrungsgemäß ein guter Anreiz für die Erfassung von Straßeneigenschaften, wenn man die dann irgendwo anschauen kann. Apropos: neu ist in z17 auch das Rendering von cutting=yes und embankment=yes, also EInschnitte und Daemme. Da habe ich aber gerade kein passendes Beispiel, weil der letzte Durchlauf nach alten Regeln erfolgte an der Stelle, wo ich Daemme ergaenzte. Die habe ich zudem gerade von feldwegbraun auf gruen umgestellt... Sonst koennte man einen weglosen Damm fuer einen Feldweg halten... Das gefällt mir nicht so ganz. In normalen Karten findet man die Farbe grün für sowas eigentlich nicht, eher braun und schwarz. Grün verbinde ich irgendwie mit Gras/Natur, was ja keine primäre Eigenschaft von Dämmen ist. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Tiles-Generierung mit Mapnik momentan wieder lahm?
ich hab mitbekommen, dass letztens das Intervall verkürzt wurde, in dem neue Tiles generiert werden. Das hat dann den erfreulichen Effekt gehabt, dass ich teilweise bereits nach 10min die ersten Auswirkungen auf der Karte gesehen hab. Jetzt scheint das aber nicht mehr der Fall zu sein. Ich hab Anfang der Woche was geändert und sehe noch immer keine Anpassung der Mapnik-Karte. Osmarender frissts aber bereits. Was ist da los? Das ist wegen Arbeiten am Server vorübergehend bis morgen außer Betrieb gesetzt: http://lists.openstreetmap.org/pipermail/talk/2009-May/036875.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-Gebäude in Google-Pseudo-3D ?
http://artem.dev.openstreetmap.org/files/osm_3d.png weiß jemand Näheres? Das ist ein Test von Artem Pavlenko, den er hier angekündigt hat: http://lists.openstreetmap.org/pipermail/talk/2007-September/018019.html Hier geht der Thread weiter: http://lists.openstreetmap.org/pipermail/talk/2007-September/018059.html -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Höhlen / Höhleneingang
Wie sollte man nun eine Höhle am besten taggen? Die Höhle selbst als tourism: attraction und den (die) Eingang (Eingänge) zusätzlich als natural: cave_entrance? Ich würde den Eingang auf jeden Fall als natural=cave_entrance taggen, und falls gegeben auch noch als tourism=attraction. Nicht jede Höhle ist ja eine Touristenattraktion. Wenn es denn mal eine Möglichkeit gibt, die Höhle als ganzes zu modellieren (z.B. mit einer Relation), dann sollte natürlich diese statt dem Eingang als attraction getaggt werden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Featurevorschlag Gewichtung für OSB
Irgendwie habe ich den Eindruck, dass wir zumindest teilweise aneinander vorbeireden. Es ging einzig und allein darum: * Es wurden weitere, komplexere Features vorgeschlagen * Ich finde, für den Einsteiger sollte OSB nicht komplexer werden Es gibt z.B. folgende Möglichkeiten: a) keine weiteren Features in OSB einbauen b) jedem die vermutlich bald kompliziertere Oberfläche zumuten c) verschiedene Seiten für expert.OSB und newbie.OSB einsetzen d) einfache Oberfläche im Web, Expertenoptionen im Editor(-plugin) e) OSB konfigurierbar machen und e1) Konfiguration einem Account zuordnen e2) Konfiguration über Cookie speichern (nur auf einem Rechner, wird eventuell gelöscht ...) Ich habe neben e1) auch e2) und d) schon erwähnt. a) und b) finde ich nicht so toll. Welche Option bevorzugst du? Ich würde bevorzugen, zum jetzigen Eingabedialog einen Link Erweitert hinzuzufügen, der die Box vergrößert und weitere Eingabemöglichkeiten sichtbar macht. Der Zustand kann dann in einem Cookie gespeichert werden (es wird ja sowieso schon eines genutzt, um den eingegebenen Namen zu speichern). Im zweiten Schritt könnte man dann für wirkliche Poweruser eine Login-Option einbauen mit den üblichen Bugtracker-Funktionen (Meine Bugs usw.), natürlich alles optional. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
1. sollte man den Namen angeben, auch wenn es eher nur ein Identifier ist? 2. gibt's hierfür ein besseres Tag als name? Nimm note. Dürfte für den Zweck, über den Sinn der Relation zu informieren, passen. Euch ist schon klar, daß wir damit anfangen uns hier richtig gut zu verzetteln? Bisher waren die Begriffe Name und Note klar - dachte ich zumindest und habe zumindest nie ein Element gesehen, wo das anders benutzt wurde als ich es auch setzen würde. - Name = Name - Note = interner Hinweis für Mapper, häufig sowas wie fixme oder mit längerem Text Jetzt bekommen wir ein Mischmasch aus: - Name_für_die_Karte - Note_als_Workaround_Name_für_Mapper - Note als Kommentarfeld für alles Während der Editor richtig bemerkt nur zur Eingabe eines Namens einlädt. Wäre es nicht sinnvoller, das Problem an der Wurzel anzupacken? Deshalb nochmal die Frage: Warum erscheint der Name einer Relation auf der Karte? Relationen an sich werden nicht gerendert, der Name muß durch einen zusätzlichen Mechanismus auf die Karte kommen, was in diesem Fall ein Fehler ist. Sollten wir in diesme Fall nicht lieber den Fehler beheben anstatt die Bedeutung von häufig verwendet Tags durcheinanderzuwürfeln? Das klappt jetzt in diesem Fall, aber: - wieviele andere Relationen müßten jetzt auch von name auf note geändert werden? - Wieviele neue Relatioen werden umgeändert müssen? - Was ist mit echten Notes mit Kommentarcharakter und Langtext? Einfach löschen? Oder ein neues Tag Note_note einführen? :-) - Wie lange funktioniert dieses Flickwerk bevor das nächste Problem es eh zu Fall bringt? - Wir taggen nicht für den Renderer? Aber wir verschmieren jetzt die Bedeutung lange benutzter Tags um diesen Effekt einzudämmen? Das ist meiner Meinung nur das erste Problem mit übereifriger Übernahme von Tags von Relationen. Wir sollten uns die Ursache ansehen, nicht an den Symptomen herumfummeln. Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Weil er ein Objekt beschreibt, das auf der Karte dargestellt wird - nämlich ein Multipolygon. Das ist Sinn und Zweck der Sache und kein Fehler. Wie sonst willst Du Waldgebiete, Teiche und andere Multipolygone mit Namen versehen? Eine Lösung des Problems könnte darin bestehen, Relationen mit einem weiteren Tag zu versehen, welches die Darstellung in der Karte beeinflusst. Ich denke dabei weniger an Tag wie osmarender:renderName sondern eher an eine generelle Bewertung zwischen allgemeinrelevant und interner Verwaltungsbezeichnung. Nein. Interne Verwaltungsbezeichnung haben im name-Tag überhaupt nichts verloren. Verwendet einfach (wie gehabt) note oder comment, und das Problem ist erledigt. Ich ärgere mich darüber, dass an der Küstenlinie (oft an unpassenden Stellen) Relationsbezeichnungen wie Schleswig-Holstein (Landmasse), Deutschland (Landmasse) oder Kreis Rendsburg-Eckernförde (Landmasse) stehen. Das sind im Grunde keine physischen Objekte, sondern nur Schnittmengen aus Deutschland und dem Inneren der Küstenlinie. Ich finde es trotzdem sinnvoll, der Relation den Namen Deutschland (Landmasse) zu geben und nicht eine namenlose Relation mit einem Kommentar zu versehen. Man braucht nur eine Möglichkeit, diesen Namen als nicht oder weniger darstellungswürdig zu kennzeichnen. Die hat man schon, nämlich im Stylesheet des Renderers. Abgesehen davon heißt das von der Relation bezeichnete Gebiet bestimmt nicht Schleswig-Holstein (Landmasse), sondern das ist eine Beschreibung und ist daher im name-Tag an der falschen Stelle. Ich kann mir viele Relationen vorstellen, die in die OSM-Datenbank passen und einen Namen haben, der aber nicht in der üblichen Karte auftauchen sollte: Historische Grenzen (vom der mittelalterlichen Staatsgrenze bis zur im letzten Jahr fusionierten Gemeinde, die noch in verschiedenen amtlichen Verordnungen genannt ist), Außengrenze der Schengen-Staaten, Wasserschutzgebiete, alte Bahntrassen, etc. Hier gilt das gleiche wie oben: wenn der Betreiber des Renderers alte Bahntrassen anzeigen lassen will, soll er sie ins Stylesheet eintragen, wenn nicht, soll er sie rauslassen. Man muss halt nur sauber zwischen name, comment und note unterscheiden. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
Du hast glaub ich den aktuellen Fall völlig missverstanden. Das Problem ist nicht, dass der Name der Relation gerendert wird, sondern dass Martin den name-Tag dazu missbraucht hat, dem Objekt einen Bezeichner zu geben, um es in der Relationsliste von JOSM besser auffinden zu können (einen Bezeichner, der _nicht_ der Name des Objekts, sondern eine Beschreibung davon ist). Das sehe ich völlig anders. Das Problem ist, daß Nodes und Ways physikalische Objekte sind, aber Relationen Beziehungen zwischen Objekten. Die Beziehung kann, muß aber nicht ein physikalisches Objekt beschreiben. Wie Stephan mit weiteren Beispielen schon dargestellt hat, liegt das Problem darin, stumpf den Namen einer logischen Beziehung oder Gruppierung mit dem von physikalischen Objekten gleichzusetzen. Dieser Schluß ist ungültig. Das ist wieder ein anderes Problem, und da stimme ich dir auch zu. Trotzdem ist das, was Martin gemacht hat, ein Missbrauch des name-Tags. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Namen von Relationen
name kann ich evtl. noch abgrenzen von den beiden anderen, aber wie ist die Abgrenzung von note und comment? Und vor allem: wo ist das dokumentiert? Note wurde bisher allerorten für alle möglichen Hinweise verwendet und keineswegs nur als Identifier für Relationen. Dafür spricht auch, dass JOSM neben name sowohl comment als auch note berücksichtigt. Klar: man kann jetzt damit anfangen und alle zu einer großen Sichtungsaktion des Bestands auffordern. Am wichtigsten ist, zwischen name und den anderen zu unterscheiden. Nachdem comment hier auf der Liste (oder auf talk) ein paar mal empfohlen wurde, bin ich davon ausgegangen, dass dieses Tag irgendwo genauer definiert wäre. Im Wiki konnte ich jetzt aber auch nix darüber finden. Ich hab die beiden immer so interpretiert: note = beliebige Notiz für andere Mapper, z.B. hier fehlt noch xyz, oder dies ist Absicht, bitte nicht löschen comment = eine Art Beschreibung/Bezeichner des Objekts, z.B. um es in einer Liste leichter identifizieren zu können Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Das interessante hierbei ist, diese Software existiert schon mehr oder weniger (JOSM/Portlach + OSM XAPI, Relation als Fileformat), aber Punkt 2 is zwar möglich, soll aber nicht gemacht werden. (= kein Abspeichern privaten Routen in OSM) Aber was spricht dagegen, die private Relation auf deiner privaten Festplatte abzuspeichern? Mir fält gerade der Pferdefuss meiner Idee auf. Wege in OSM können sich ändern (zerteilt and verbunden werden), so meine Liste von way ids wäre wahrscheinlich nach einiger Zeit falsch. Es gibt auch noch das Problem, dass Du ggf. einen way erst mal zerteilen musst, weil er vielleicht zu lange ist. Aber mit so privaten Relationen, die alle zugehörigen Elemente (ways, nodes) enthalten, könnte man doch arbeiten, oder? Das Problem ist, dass wir nicht garantieren können, dass die Wege nicht gelöscht oder (wahrscheinlicher) aufgespaltet werden. Es wäre schön, wenn es ein Programm gäbe, dem man ein GPX o.ä. übergibt, und das dann die dazu passenden OSM-Objekte raussucht. Das würde die lose Anbindung von externen Daten extrem erleichtern. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Private Wander/Rad Routen in OSM
Das Problem ist, dass wir nicht garantieren können, dass die Wege nicht gelöscht oder (wahrscheinlicher) aufgespaltet werden. Es wäre schön, wenn es ein Programm gäbe, dem man ein GPX o.ä. übergibt, und das dann die dazu passenden OSM-Objekte raussucht. Das würde die lose Anbindung von externen Daten extrem erleichtern. Das wäre schön, ist aber faktisch unmöglich, jedenfals mit GPX (oder anderen punkt-Formaten) als Input. Aus einer reinen Liste von Koordinaten die dazu am besten passenden Wege zu finden, hört sich sehr komplizier an und ist ja auch subjectiv. Is es besser auf der Strasse oder auf dem parallelen Wanderweg zu gehen ? Für diesen Fall is es realistischer dies als Routingproblem zu sehen. Also Start- und Endpunk und Vorlieben eingeben einen Weg berechnen lassen. Ich war von einer Datenbasis ausgegangen, wo sich nur Objekt-IDs ändern können, der Rest aber mehr oder weniger fest bleibt. In so einem Fall müsste man nur alle Nodes aus den OSM-Daten als Punkte in das GPX aufnehmen, um die Route relativ einfach rekonstruieren zu können. Allerdings können sich in der Realität auch die Koordinaten ändern, und dann kann es leicht zu Verwechslungen zwischen zwei parallelen Wegen kommen, wie du es beschrieben hast. Mein Vorschlag, siehe nächste Mail, geht ein wenig in die Richtung, eine subjective beste Route von einer Person erstellen zu lassen und dies mit der Community zu teilen. Innerhalb oder außerhalb der Datenbank? Bin schon gespannt... -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte wieder online
Hallo! Die Reit- und Wanderkarte mußte auf ein anderes Hosting umziehen und ist jetzt wieder online. Ihr findet sie unter http://topo.geofabrik.de Das Relief ist verfügbar und derzeit läuft ein Update aller Kartenregionen. Den Fortschritt der Wiederherstellung könnt Ihr im Wiki verfolgen. http://wiki.openstreetmap.org/wiki/DE:OSMC_Reitkarte#Regionstabelle Kleiner Bugreport: In der höchsten Zoomstufe scheinen bestimmte Beschriftungen doppelt zu sein; sie liegen direkt übereinander in zwei verschiedenen Schriftgrößen. Das betrifft zumindest Ortsnamen und Kirchennamen. Hier bei Bamberg sieht man es ganz deutlich: http://topo.geofabrik.de/?zoom=15lat=49.89215lon=10.88872layers=BT Bei der Siebenschläferkapelle sieht man das S, das b und das ll hervorspitzen: http://topo.geofabrik.de/?zoom=15lat=49.85758lon=10.83962layers=BT Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk] Languages
I agree that's nothing political, and there is some information missing. You propose to add this information in the following way: name=Bergstrasse name:en=Mountain Road local_language_used_in_name_tags=de I think it complicates things without a goog reason. I solve it as I've shown above: name:de=Bergstrasse name:en=Mountain Road I remember that in some countries, the official language of the name depends on the municipality; in these cases it would be nice to be able to specify this language on the object itself. Otherwise you would have to build a huge external database correlating villages to languages. Something like this would be feasible in a (hypothetical) german-english bilingual area: name:de=Bergstrasse name:en=Mountain Road language:name=de The language tag could also be used on higher administrative units like counties, and would be automatically inherited to objects inside them, unless explicitly overridden. Note that you would not need to specify a general name tag here. Regards, Marc -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] barrier=bollard
Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Warum dann nicht an den Poller motorcar=no? Weil die Router aus mir auch nicht bekannten Gründen access-Tags an Nodes nicht auswerten. Vermutlich weil die intern mit Graphen arbeiten und die Nodes lediglich Verbindungen zwischen Kanten sind. *gähn* nicht für den Router mappen... -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wie bezeichne ich das?
Am Donnerstag 07 Mai 2009 20:27:58 schrieb Torsten Leistikow: Ulf Lamping schrieb: Es ist ja einfach nur ein Gebäude, also viellecht einfach building=hut? Wobei das von keinem Renderer und keinem Kartenkonverter erkannt werden duerfte. Bessere Chancen haetten man da schon mit einem einfachen building=yes. Sicher? Zumindest osmarender prüft nur auf building=*. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] bug plot
-1 möchte ich eigentlich nicht, da sonst der Fluss schon mal gerne vom Wald überdeckt wird Wo passiert das denn noch? Dieser Fehler sollte eigentlich inzwischen in allen Renderern behoben sein; wenn es trotzdem noch vorkommt, leg bitte einen Bugreport auf http://trac.openstreetmap.org/newticket an. Grüße, Marc -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] barrier=bollard
Ok, das Beispiel war blöd. Also simpler: Poller auf mittelbreiter Straße, so dass man mit 'nem Smart durchkommt, mit einem Mercedes aber nicht. Der Poller an sich stellt also m.E. keine Zugangsbeschränkung dar. Der Mapper sollte im Einzelfall entscheiden und wenn er meint dass da keine Auto durchgeroutet werden soll, ein Wegstückchen mit motorcar=no taggen. Wenn, dann aber andersrum. Das Wiki legt folgende Berechtigungen als Default fest: access=no foot=yes bicycle=yes. Ich finde das sehr vernünftig, denn die Beispiele, die du anführst, sind doch eher seltene Ausnahmefälle. Grüße, Marc signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
So verkommt der maxspeed - tag zur Bedeutungslosigkeit weil jeder was neues dazu erfindet und die Anwendungen gar nicht so schnell hinterherkommen die neuen Tags zu erlernen um noch was sinnvolles damit anfangen zu können... Um so besser - dann entsteht wenigsten gar nicht erst der Eindruck, dass es in diesem Stadium des Projekts irgendwelche Kompatibilitätsgarantien bezüglich unseres Datenmodells gibt. Wenn man mit Beta-Software und -Daten arbeitet, muss man halt immer damit rechnen, dass sich was wichtiges ändert. Hast Du vor einen grossteil der Mapper die OSM gewonnen hat wieder zu vergraulen? Die meisten davon dürdten dabei sein um die Daten einsatzfähig zu machen und nicht um sie als programmiertechnische Spielwiese zu benutzen die man regelmässig platt macht um sie wieder anderst aufzubauen. Mapper werden dadurch nicht unbedingt verkrault, höchstens Datennutzer, die nicht damit leben können, ab und zu mal was ändern zu müssen. Und es ist ja auch nicht das gesamte Taggingschema, das sich ändert. Letztendlich sehe ich nur drei Möglichkeiten: - Man definiert von Anfang an ein gut durchdachtes Taggingschema und Datenmodell, dass möglichst schon alle Sonderfälle abdeckt und das rückwärtskompatibel erweiterbar ist. - Man lässt das Schema sich mit der Zeit entwickeln, besteht aber darauf, dass einmal eingeführte Features für immer gültig bleiben. - Man lässt das Schema sich mit der Zeit entwickeln, verbessert aber Fehler und nicht ganz ausgegorene Teile, und erklärt auch mal nicht benötigte Tags für obsolet. Das erste trifft bei uns offensichtlich nicht zu, das zweite führt letztendlich zu einem Chaos, das keiner mehr überblickt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[OSM-talk] Rendering of footways with bicycle=yes
Right now, ways highway=footway or highway=path,foot=designated where riding a
bicycle is allowed with bicycle={yes,designated} are rendered as normal
footways, so there is no way to see that they are open for bikes.
Is there a chance this could be shown on Mapnik, or at least on the cyclemap?
Maybe a mixed blue-red line, or even dashes for the designated vehicle type,
and dots for the one with yes?
Regards, Marc
signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Maxspeed map
So verkommt der maxspeed - tag zur Bedeutungslosigkeit weil jeder was neues dazu erfindet und die Anwendungen gar nicht so schnell hinterherkommen die neuen Tags zu erlernen um noch was sinnvolles damit anfangen zu können... Um so besser - dann entsteht wenigsten gar nicht erst der Eindruck, dass es in diesem Stadium des Projekts irgendwelche Kompatibilitätsgarantien bezüglich unseres Datenmodells gibt. Wenn man mit Beta-Software und -Daten arbeitet, muss man halt immer damit rechnen, dass sich was wichtiges ändert. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 17:39:08 schrieb Bernd Wurst: Hallo. Am Mittwoch 29 April 2009 17:14:54 schrieb Guenther Meyer: Schade, dass du jede Parallel-Existenz von pragmatischem und korrektem Wert ausschließen möchtest. wie kommst du da drauf?! Weil maxspeed=7 und maxspeed=walk sich gegenseitig ausschließen. Man kann nicht beide Vorgehensweisen parallel nutzen. Natürlich kann man: da wo Schrittgeschwindigkeit angesagt ist, nimmt man maxspeed=walk, und da wo 7 angesagt ist, nimmt man 7. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Ich möchte gerne maschinenlesbare Daten irgendwo haben. Maschinenlesbar in dem Sinne, dass man keine Datenbanken der jeweiligen Geschwindigkeiten oder whatever mit herumtragen muss sondern einfach numerische Werte. Numerische Werte entsprechen in bestimmten Fällen nicht der Realität; du willst also nichts anderes als aus Bequemlichkeit falsche Daten eintragen... So wie es die map-Features seit Ewigkeiten spezifizieren und so wie es mit Null-Aufwand verarbeitet werden kann. Ich möchte gerne eine Möglichkeit haben, egal aus welchem Grund ein Limit gilt, das Limit numerisch aufzuschreiben. Ob es 100% korrekt ist, ist mir dabei Latte, ... und es stört dich nicht mal :-( Eigentlich müsste damit die Diskussion erledigt sein. es dient dazu, dass man eine Abschätzung treffen kann, wie schnell man da wohl unterwegs sein wird. Das man das mit den korrekten Daten noch viel besser kann, ist schon oft genug erklärt worden. Diesen numerischen Wert, den man intuitiv im tag maxspeed erwartet, kann man nicht mehr setzen wenn da jeder ein anderes Gedicht einträgt. Ich erwarte intuitiv, dass jeder Tag die Wirklichkeit abbildet. Ergo: Es schließt sich aus. Warum nutzt du nicht für deine pingelig genaue Erfassung der Theorie (ohne Rücksicht auf die Praxis) ein tag, das nicht bisher als rein numerisch spezifiziert ist? Warum nicht andersrum? Nehm halt implied_maxspeed=5.66782. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Je länger ich bei OSM dabei bin, umso mehr gefallen mir solche eigentlich total uneleganten Lösungen, denn irgendwie geht das einfach ratz-fatz, keiner muss irgendwelche hässlichen Implikationen beachten und man hat sofort ein Ergebnis. Glaubst du wirklich, dass es schneller geht, an jede Straße ein maxspeed=innerorts hinzuhängen, als schnell ein Polygon um die Stadt rumzumalen? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
