Re: [OSM-talk-nl] Fietspaden
On Wed, 7 Oct 2009, altijd verdwaald wrote: Ik zie dat al op veel plaatsen 'los liggende' fietspaden die grote wegen volgen ook ingetekend worden. Ook ik maak me hier wel eens schuldig aan. Wat is het standpunt over dit soort fietspaden. Intekenen als 3 wegen of als 1 weg met toevoeging van een cycleway=track tag? Bij het laatste is er wel een probleem om aan te geven welke kant (evt beide kanten) een track ligt. Wiki is voor mij niet duidelijk. Toch staat er al heel wat op: http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging http://wiki.openstreetmap.org/wiki/NL:Cycleway Niet duidelijk genoeg? Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] New dimension of vandalism
On Thu, 27 Aug 2009, Martin Koppenhoefer wrote: 2009/8/27 lulu-...@gmx.de: You made a change after a discussion with 8 persons and not all did agree. This is far below the limit for a proposal voting to become approved. 1) there is no procedure to vote upon an edit like mine (see the guidelines linked above, that don't reflect your point of view) 2) I guess you did not see all of the discussion. I'm leaving out national lists and refer just to talk: ... It seems your translation of the german wording is incorrect. In german it talks about 'Verkehrsbedeutung' which does not sound so bad to me. But 'importance' is something else IMO. A road's importance can be different for different traffic participants (or even non-participants), so it is too subjective. The following probably makes just as little sense, though ): A way with the highway tag set is a road. The value of this tag reflects the purpose of the road within the road network of a country. As such, a proper definition of many of the values can only be found in each country project. Some of these country-specific definitions are listed in the International Equivalence table below. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Proposed feature: Directional node
On Fri, 28 Aug 2009, Roy Wallace wrote: On Fri, Aug 28, 2009 at 2:22 AM, Andrew MacKinnonandrew...@gmail.com wrote: This is a proposal for a generic way of tagging a node which represents an object which faces a certain way - e.g. a traffic sign such as a stop sign. Note this is not a specific proposal on how to tag signs of a certain type, only a generic relation which can be used for all objects of this type. http://wiki.openstreetmap.org/wiki/Relations/Proposed/Directional_node Good effort, nice picture, and good to see it's generic :) But I don't like the stop sign example. I think the direction of the sign would be better described by the direction of the way, in this case. Like traffic_calming:starboard=stop ? (; Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Tue, 25 Aug 2009, Aun Johnsen (via Webmail) wrote: On Tue, 25 Aug 2009 10:47:14 +0200 (CEST), Christiaan Welvaart c...@daneel.dyndns.org wrote: hi, On Sat, 22 Aug 2009, Tobias Knerr wrote: I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags I didn't really answer this question yet. My idea with :forward and :backward was to group all access restrictions - keys that take yes/no/destination/private/etc. - with the access key. So I also sometimes write e.g. access:vehicle:forward=no . But time restrictions should also be included, e.g. as :Tfrom-to, so one could write (crazy) things like: access:vehicle:forward:Tmo-fr=destination access:vehicle:forward:Tsa-su=yes access:vehicle:backward:Tmo-fr=delivery access:vehicle:backward:Tsa-su=no A problem with oneway= is that it cannot accept the whole range of access values - only yes/no. So the above cannot be done with :oneway AFAICT. (max)height/weight/width/speed could maybe also be included with access, but I think it is better to treat them as access limits and keep them separate. Then the conditions proposal looks good for these keys. When you are getting this complicated on it, maybe it is better to handle this in relations? This way each special condition can be handled separately without cluttering the map with tags. A road can have a set of general access tags, and than use relations for the complicated access conditions, such as psv only on school days, goods delivery 10-12 mon-fri + 11-12 saturdays in july, destination for taxies exept saturdays after 22, and so on. That will allow you to do all these special condition without access:vehicle:forward/backward. I havn't seen that complicated access restrictions in the areas I map, so I have no need for it, but I know that reality is a little different in Europe. I guess using relations is an option. But AFAIK the vast majority of roads in the world only needs a highway tag for access, and most specific access restrictions are simple. My example was not really practical, if such complicated restrictions exist they are likely rare. This would mean that an access restriction relation needs a completely new specification that will not be used much, while the system I described scales from simple situations to quite complicated ones. Also, having access restrictions in two locations (tags on the way/node and in relations) only complicates things. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Mon, 24 Aug 2009, Tobias Knerr wrote: Christiaan Welvaart wrote: http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags For example, with this proposal it is possible to create both bicycle:backward and oneway:bicycle, while I would really prefer to only have the former. If we don't try to abolish oneway completely, I would prefer the latter in most situations. My opinion is that a base key should not be able to remove a restriction introduced by another base key. For example, hgv=yes should not be able to remove a maxweight=3.5 restriction. Similarly, an access tag (such as access:bicycle:*=* or short bicycle:*=*) should not be able to remove an oneway tag. Interesting, wouldn't it then be better to always use maxweight instead of hgv, since AFAIK the only property of hgv is its weight? One example why I think oneway and access (including the transport mode and category tags) should not affect each other: In front of a station, there is a road that must not be used by motor vehicles except busses. This road also is an oneway road, with no exceptions. Therefore, I consider it natural to tag this - oneway = yes - (access:)motor_vehicle = no - (access:)bus = yes This can easily be understood if oneway isn't influenced by the other tags. If, however, we consider oneway=yes just another way of saying (access:)vehicle:backward=no, then we suddenly have a problem: Neither of the two conditional expressions vehicle:backward and bus is more specific than the other one, so we cannot determine whether the yes from bus or the no from vehicle:backward is relevant here. This can be defined. As I described it one would have to write bus:forward=yes , but people may indeed expect bus=yes to work. To sum up: Yes, both bicycle:backward and oneway:bicycle are direction-dependent restrictions for bicycles. However, they are still different because only oneway:* keys should be able to overwrite other, less specific oneway keys. It is not clear from the text on the proposal page that oneway:transportation mode is more specific than transportation mode:forward ... It would be nice to have an explicit description of how all the different tags can be evaluated. One thing I don't like about using the oneway tag in complex situations is that oneway works the opposite way of regular access restrictions: oneway=no allows access in both directions, while access=no denies access. This could be a reason why having *both* oneway:* and access:*:forward/:backward is not such a good idea. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Mon, 24 Aug 2009, Martin Koppenhoefer wrote: 2009/8/22 Christiaan Welvaart c...@daneel.dyndns.org: hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. currently there is no more mofa (I guess this is not English, as it is an abbreviation of Motorfahrrad = motor-assisted bicycle) on the page and no definition for moped (until which ccm it is considered to be such, or what else is the criteria). I put some descriptions in the hierarchy, are those good enough? Indeed mofa is AFAIK the german word for this vehicle class (25km/h mopeds), I could not find a proper english word for it. IMHO motor_vehicle should not include mofa, lawn-mowers and other stuff like this. AFAIK mofas (below 50 ccm) are in many countries considered as bicycles, at least outside town. The general sign to exclude motorcars and motorcycles often don't exclude mofas. If mopeds *are* considered motor vehicles it seems a bit arbitrary, because mopeds and low performance mopeds aka mofas are very similar (at least in the EU), even though they may be treated somewhat differently by traffic rules. That said, I do not care much about the exact categorization of 'mofa' as long as it is clearly defined so everyone knows the meaning of access tags on a way. (For dutch traffic law it would make sense to define motor_vehicle as motorcycles, cars etc. - excluding any mopeds.) Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009, Tobias Knerr wrote: Christiaan Welvaart wrote: Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. This reasoning is not quite valid. The restrictions for a vehicle category are affected by categories higher up in the hierarchy, not by those below. At least this is the idea behind current documentation such as http://wiki.openstreetmap.org/wiki/Computing_access_restrictions , and I don't see why we should be restricted to leaves of the category tree. I made mistake in the position of motorcar compared to the last version of the hierarchy picture, which I now fixed. ( http://wiki.openstreetmap.org/wiki/Image:Access_modes.png ) I did not know the Computing_access_restrictions wiki page, maybe the text about evaluation I added to Key:access should be replaced by a link to that page. * Direction specific restrictions I listed :backward and :forward postfixes for access keys What you are doing here seems like picking raisins from conditional tagging and trying to handle it as a special case. I'm not sure whether you are aware of my proposal? http://wiki.openstreetmap.org/wiki/Proposed_features/Conditions_for_access_tags This proposal does not seem specific enough. Shouldn't it list exactly which simple keys can be modified this way, especially for the :transport mode extension? For example, with this proposal it is possible to create both bicycle:backward and oneway:bicycle, while I would really prefer to only have the former. While direction may be considered as something special when constructing a routing graph (unlike most other parameters it will have different values during creation of the same routing graph; unless you are really sophisticated and use changing time, it will be the only parameter like this), it's not a special case for *evaluation*: It's just another parameter needed to get the value of a base tag for the current situation. In the model I used, there is no base tag wich a value: each way direction has completely separate access restrictions. It only applies to the data in OSM, not a routing graph. As evaluation is the aspect that needs to be documented (routing graph creation is up to the application), I believe forward/backward shouldn't be introduced or documented separately but instead as a part of conditional tagging. Is it really a problem if work is one in this respect as long as it does not contradict the conditional tagging proposal? * Evaluating access tags Your use of category and (transport) mode confuses me, especially as they both seem to be things that can be a key. I did not invent these names, but as I understand it, a transport mode is a distinct way of physically moving around, in other words a class of traffic participants. Differences within a class are not relevant for access to a road, while differences between classes are, in some cases. A (transport mode) category is simply a group of transport modes and/or other categories that are sometimes treated similarly regarding road access (by law). So such a category is used to limit the number of tags needed to describe access for a particular way. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
On Sat, 22 Aug 2009, Craig Wallace wrote: On 22/08/2009 20:33, Christiaan Welvaart wrote: I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. There already is a separate tag for cars: key:motorcar. I think trying to define this as different from an automobile is confusing. Have a look at Wikipedia for example, which says they are different terms for the same thing: http://en.wikipedia.org/wiki/Automobile I think your definition of motorcar (category: motor vehicles with more than 2 wheels / more than 1 track) is confusing / wrong. goods/ hgv / psv / hazmat etc should be in the hierarchy directly below motor vehicle, not below motorcar. Finally figured out what was going on: I did not look closely enough at the picture apparently - fixed. BTW what is a hov? I assume it's high occupancy vehicle, ie a vehicle with more than a certain number of passengers in it. In some places they are allowed to use bus lanes etc. Sure, but is this not a bit too complicated to put between the regular access tags? For tagging, hov= can be used although it makes me wonder what the exact qualifications are. But a routing engine supporting this should also allow specifying that at some point the number of passengers drops below the limit. With hov in the hierarcy this would mean the remaining passengers are suddenly sitting in a different kind of vehicle. That seems strange at least (: Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Changes to Key:access wiki page
hi, I changed some things on http://wiki.openstreetmap.org/wiki/Key:access - only to document current (best) practices. * Transportation modes The transportation mode hierarchy picture is replaced by a simple outline, because the picture was not integrated in the text and too small to read on the page itself (could both be fixed), and having to figure out how to modify the picture complicates editing of this wiki page. The hierarchy is however the only definition of several transportation mode categories so quite important. IMHO the picture can be re-added but not replace the outline. Some transportation modes were listed in two unrelated categories. This needlessly complicates determining the correct tags for a real-world situation. Specifically, the meaning of access tags becomes very unclear if they belong to unrelated categories. There was apparently a good reason for doing this but I have not found a clear explanation. (Note that *=agricultural is not necessarily defined by this hierarchy, only tags like agricultural=no.) Added a separate tag for cars, because AFAICT any routing app computing routes for cars uses this transportation mode. If routing would be done for 'motorcar', ways tagged as hazmat=no, for example, could not be used because the motorcar *could* be a hazmat vehicle. Maybe the actual tag is not needed, in which case the description can stay but the tag removed. BTW what is a hov? Added a tag for low performance mopeds, because in some countries they are by law neither a bicycle nor a true moped. Separated land (road), water, and rail based transportation because they can be treated separately(?). * Direction specific restrictions I listed :backward and :forward postfixes for access keys but apparently forgot explicit descriptions. The examples should be enough for now. Some roads (around here at least) have complicated oneway restrictions that cannot be modeled with oneway= and cycleway=opposite*. The postfixes allow specifying any restriction (yes/no/destination/etc.) for any transportation mode in either direction. I'd like to deprecate cycleway=opposite because it is used for roads that have neither a cyclelane nor a cycleway in that direction, so using a cycleway tag does not make much sense. * Evaluating access tags In order to know the meaning of a set of access tags on a way with some highway tag (in case of roads), it is necessary to define how access for each transportation mode can be computed from these tags. I added a section about this which hopefully matches current tagging practice. It does not include time-based, height, width, or weight restrictions so it is certainly not yet complete. Many of the values listed at the top of the page are also missing. The idea is that this model links tagging to routing so if it used, while currently AFAIK one needs to find out how a router computes access and tag accordingly or accept broken routing in one or more routing engines. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Wegentagging in NL
On Wed, 12 Aug 2009, Roeland Douma wrote: secondary binnen de bebouwde kom: misschien om het iets duidelijker te maken: (grote) verbindings wegen tussen wijken in een stad. Daar zit wat in, maar de 'officiele' ringwegen zouden er dan ook onder vallen. Misschien moeten we grote steden en kleinere plaatsen maar splitsen, hieronder een lijst van gebiedsontsluitingswegen binnen de bebouwde kom: Officiele ringwegen (in grotere steden): primary Belangrijke toegangswegen (bijvoorbeeld vanaf een snelweg) naar een officele ringweg: primary In steden met een officiele ringweg: overige wegen die grote delen (meerdere wijken) van de stad ontsluiten: secondary N-wegen binnen de bebouwde kom: zie N-wegen buiten bebouwde kom In plaatsen zonder officiele ringweg: een ringweg en/of andere wegen die de mogelijkheid bieden om van de ene kant naar de andere kant van de woonplaats te rijden (dit is dus een functie van die weg): secondary Wegen binnen de bebouwde kom die toegang bieden tot enkele wijken (of een grote wijk), vaak aftakkingen van primary of secondary wegen. De van Duurzaam Veilig terminologie afgeleide wijkontsluitingswegen of wijktoegangswegen vallen hier ook onder. De wegen in die (sub)categorie hebben ook een verblijfsfunctie (dus meerdere huizen aan de weg): tertiary Overige wegen binnen de bebouwde kom die toegang bieden tot een beperkt gebied (bijvoorbeeld 1 wijk): unclassified En dan zitten we nog met wegen die een kleinere plaats op een snelweg of N-weg aansluiten. Ook nog een vraag: een 30km/h weg in een woongebied waar geen huizen aan liggen maar eventueel wel 1 of meerdere bedrijfspanden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wegentagging in NL
On Thu, 13 Aug 2009, Paul Smits wrote: Wat betreft tertiary buiten de bebouwde kom weet ik niet of je het zo beknopt moet omschrijven. Unclassified wegen kunnen bijvoorbeeld ook wegen (geen N-wegen) die dorpen of een dorp en een stad met elkaar verbinden zijn. Het gaat mij om de functie van zo een weg. Dus als de weg functioneert als verbinding tussen twee dorpen of een dorp en een stad is die tenminste tertiary. Het lijkt mij tenminste dat de inwoners van het dorp dat een redelijk belangrijke weg vinden. Verder ziet het er prima uit. Wat mij trouwens opviel aan het huidige overzicht waren de titels die gegeven zijn aan de verschillende wegen buiten de bebouwde kom. Provinciaal zegt slechts iets over het beheer van de weg, niet de functie of uiterlijk. Veel zogenaamde Nationale (primary) wegen zijn in feite provinciaal. Ik zou niet weten waar de term Nationale weg vandaan komt. Maar die benamingen voor N-wegen zijn inderdaad niet handig. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Wegentagging in NL
hoi, Ik heb (enige tijd geleden alweer) geprobeerd de wiki pagina waarop wordt uitgelegd hoe wegen in Nederland van tags kunnen worden voorzien in OSM [1] te verbeteren door dingen toe te voegen. Ik zie nu echter dat de bestaande beschrijvingen van algemene wegen niet helemaal lijken te kloppen. Ten eerste is het waarschijnlijk handig om wegen binnen en buiten de bebouwde kom te groeperen of zelfs in losse tabellen te zetten. Verder zijn volgens mij de onderstaande wijzigingen nodig. (sommige beschrijvingen bevatten termen uit de Duurzaam Veilig [2] wegcategorisering) Toevoegen: Officiele ringwegen binnen de bebouwde kom (vaak 70km/h in grotere steden): highway=primary secondary binnen de bebouwde kom, vervangen door: overige (niet officiele, 50km/h) ringwegen binnnen de bebouwde kom en soortgelijke gebiedsontsluitingswegen die bruikbaar zijn om van de ene naar de andere kant van een plaats te rijden tertiary binnen de bebouwde kom, vervangen door: overige wegen binnen de bebouwde kom die toegang bieden tot meerdere wijken (of een grote wijk), vaak aftakkingen van primary of secondary wegen. De van Duurzaam Veilig terminologie afgeleide wijkontsluitingswegen of wijktoegangswegen vallen hier ook onder. De wegen in die (sub)categorie hebben ook een verblijfsfunctie (dus meerdere huizen aan de weg). toevoegen: overige wegen binnen de bebouwde kom die toegang bieden tot 1 of enkele (kleine) wijken: highway=unclassified toevoegen: wegen op bedrijventerreinen: highway=unclassified tertiary buiten de bebouwde kom, vervangen door: wegen (geen N-wegen) die dorpen of een dorp en een stad met elkaar verbinden toevoegen: wegen in landelijke gebieden die toegang bieden tot bebouwing aldaar en officieel geen doorgaande functie hebben: highway=unclassified Christiaan [1] http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging [2] http://nl.wikipedia.org/wiki/Duurzaam_Veilig ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] [RFC] highway=unclassified currently is too ambiguous, so here's my proposal to fix it.
On Wed, 5 Aug 2009, Richard Mann wrote: I'd define a rural as a road which is (usually) maintained by a public body, and open to public access, but where only partial provision is made for vehicles travelling in opposite directions to pass (be that lower-grade shoulders, Australian-style or occasional formal or informal widenings, UK-style). That's still too much of a physical definition (: How about: highway=rural: a road not in a built-up area that provides direct access to buildings (e.g. farms), similar in function to a residential road in built-up areas. Such roads often have a smaller width than connecting roads like unclassified and tertiary ways, and are not supposed to be used for passing through the rural area. A possible additional characteristic: no bicycle facilities are present on such roads. Just like residential roads they are not very suitable for cyclists passing through: for residential roads, many cyclists passing them could cause the people living there to complain, while cycling on rural roads is relatively unsafe/uncomfortable because of the road width and large vehicles using the road (combined with the lack of bicycle lanes or ways). A problem could be that rural areas may have a whole network of roads that all look the same. I suppose they can all be tagged highway=rural in such a case(?), but does that match the above description? Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] highway=unclassified currently is too ambiguous, so here's my proposal to fix it.
On Wed, 5 Aug 2009, Shaun McDonald wrote: On 5 Aug 2009, at 20:59, Christiaan Welvaart wrote: On Wed, 5 Aug 2009, Richard Mann wrote: I'd define a rural as a road which is (usually) maintained by a public body, and open to public access, but where only partial provision is made for vehicles travelling in opposite directions to pass (be that lower-grade shoulders, Australian-style or occasional formal or informal widenings, UK-style). That's still too much of a physical definition (: How about: highway=rural: a road not in a built-up area that provides direct access to buildings (e.g. farms), similar in function to a residential road in built-up areas. Such roads often have a smaller width than connecting roads like unclassified and tertiary ways, and are not supposed to be used for passing through the rural area. A possible additional characteristic: no bicycle facilities are present on such roads. Just like residential roads they are not very suitable for cyclists passing through: for residential roads, many cyclists passing them could cause the people living there to complain, while cycling on rural roads is relatively unsafe/uncomfortable because of the road width and large vehicles using the road (combined with the lack of bicycle lanes or ways). Am I right in seeing that you think that residential streets are not for cycling along? Then explain why the majority of the London Cycle Network is along residential streets. Many of the rural roads I've been on are quiet country lanes with little traffic, some of which are part of the National Cycle Network. So what I wrote about bicycles is not valid - thanks for clearing that up. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sun, 2 Aug 2009, Martin Koppenhoefer wrote: 2009/8/1 Christiaan Welvaart c...@daneel.dyndns.org: On Sat, 1 Aug 2009, Martin Koppenhoefer wrote: Well I disagree. IMHO we should tag what is 'on the ground', not invent things or try to tag what's in people's minds. If a government body gives a road it maintains some importance (or class/type) we should tag it accordingly. yes. We should tag the importance it receives. But that's what this is about. Class and type put equally aside are not helpful in this discussion. Classes there are also in law more than just administrative classes. Maybe you can read German, so have a look at this: I don't see what you're saying here. Do you have a complete text to replace the intro text on http://wiki.openstreetmap.org/wiki/Key:highway ? Maybe the following helps a bit (derived from the current text): There are at least 4 attributes of a road that can be used to determine highway types: 1. the physical attributes: a. number and surface quality of the regular lanes b. signs for access, right of way (yield), road type, etc. c. whether there is a separate cycleway along the road d. presence (and programming) of traffic lights e. whether buildings are at the road (addresses) f. whether buildings are near the road (within X m) g. how access points/crossings/etc. are built etc. 2. intended use/function Roads usually must be built and maintained. The people who arrange this construction work need to have some idea of the function of each road. 3. actual use Must be measured, usually written as number of vehicles/day, differentiated by: a. vehicle type b. local/regional/other traffic 4. who funds road maintenance IMHO we are already tagging intended use (2.) often by looking at the pysicial attributes (1.) so it would be nice to have this described on the wiki. http://de.wikipedia.org/wiki/Stra%C3%9Fenkategorie This seems to be based on the same 3 categories as in The Netherlands, and then further subcategorized. The 'Verbindungsfunktionsstufen' might be useful for tagging. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Fri, 31 Jul 2009, Martin Koppenhoefer wrote: If the administrative class in your country coincides with the importance: fine. Nothing changes. Unfortunately this is neither in Italy nor in Germany the case: some roads have been downgraded / passed to a lower maintenance entity for administrative reasons (now somebody else pays and cares for the maintenance, what was before a nation / federal road has sometimes become a regional / Landstra??e). Others, like Kreisstra??en in Germany (comunal roads) have been upgraded and are now almost Autobahn-Standard. As result of this, it has been agreed not to corelate administrative status and highway-class. But there is a problem with tagging pure physical state as well: it depends on the context. In a rural area a secondary or primary street will be much smaller than in a highly dense urban area. This is why importance of the road seems most useful (be it for routers or to structure visually and according to significance on rendered maps). Why would who maintains a road directly determine its administrative classification? If a municipality decides that some road is a motorway, we better tag it as such. In The Netherlands some provinces maintain short stretches of motorway, for example, while most motorways are maintained by the national government. The maintainer of a road can be tagged independently. So is it really a big change for Germany and Italy to define the highway tag as the administrative classification of the road? The problem with 'importance' is that it is too vague and it is the task of the road maintainer to determine/define a road's function. Also, if there is a mismatch between a road's classification and its 'importance', we should tag the classification. The importance is derived from the topology of the road network, which is already in OSM. An example is a route through a town to a motorway access. The municipality this town belongs to considers this route inappropriate, while the municipality where the route starts considers it an appropriate route. The road inside the town is still tagged as secondary, while its maxspeed was already lowered to 30km/h. AFAIK its 'importance' has not changed, however, as no alternative route to this motorway access is available (there are several alternative access points to this an other motorways, though). So, do you think we should keep it as secondary which probably matches its importance (access to a motorway) or tag it as tertiary or even lower which matches its classification (only meant for traffic from and to the town)? Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] definition of the main highway-tag
On Sat, 1 Aug 2009, Martin Koppenhoefer wrote: 2009/8/1 Christiaan Welvaart c...@daneel.dyndns.org: On Fri, 31 Jul 2009, Martin Koppenhoefer wrote: Why would who maintains a road directly determine its administrative classification? If a municipality decides that some road is a motorway, we better tag it as such. In The Netherlands some provinces maintain short stretches of motorway, for example, while most motorways are maintained by the national government. The maintainer of a road can be tagged independently. So is it really a big change for Germany and Italy to define the highway tag as the administrative classification of the road? seems as if you got me completely wrong. The administrative classification _IS_ about who maintains the road (at least in Germany and Italy). While BAB (Bundesautobahn / motorway) and Bundestra??e (federal road) are maintained by the federal administration, Landstra??en (~Land-roads) are maintained by the Bundesland (~region) and Kreisstra??en (comunal road) by the municipality. But as I tried to explain this does not mean that every Bundesstra??e is a bigger and more important road. There are Kreisstra??en (comunal roads) that are more important (and physically bigger) than other Bundesstra??en or Landstra??en. That's why we cancelled the idea of tagging highway according to administrative class already years ago. Of course I don't want to reimplement it. It seems to be an interpretation problem for the phrase 'administrave class' then because I clearly argued that who is the maintainer of the road should not directly influence the value of the highway tag. What I was trying to say is that I'd prefer to tag the importance that the road maintainer sets for a road. This *class* can usually be derived from how it was built, the maximum speed on the road, etc., not from how many cars actually drive on it or even its position in the grid. Road maintainers also take other things into account like how many houses are near the road, how much pollution and noise will be generated by traffic on the road, etc. On the other hand a road's class is often not clearly visible except for motorways. Also, there is usually no uniform classification system available - there is a proposed system for The Netherlands but it only has 3 categories which is not really enough... So in the context of Germany I say take 'Autobahn' and 'Kraftfahrstrasse' as a classes for the highway tag (not 'Bundesstrasse' and 'Landesstrasse'). These terms are defined in law, so it is not something OSM invented or a vague importance of the road. The problem with 'importance' is that it is too vague and it is the task of the road maintainer to determine/define a road's function. Also, if there is a mismatch between a road's classification and its 'importance', we should tag the classification. what do you mean by classification? Administrative, physical or importance? There is clearly all the three of them, and of course I want to tag the administrative classification (inside ref-tag) but not as the parameter for the highway-class. I mean how the road maintainer designates the road. An example is a route through a town to a motorway access. The municipality this town belongs to considers this route inappropriate, while the municipality where the route starts considers it an appropriate route. The road inside the town is still tagged as secondary, while its maxspeed was already lowered to 30km/h. AFAIK its 'importance' has not changed, however, as no alternative route to this motorway access is available (there are several alternative access points to this an other motorways, though). So, do you think we should keep it as secondary which probably matches its importance (access to a motorway) yes, of course. Because as you wrote: there is no other way, i.e. if you want to go to this motorway, you will have to take it - it is important, gets a high class (secondary or primary). No, I said there are other routes. This is just the shortest or fastest route for some people I guess. or tag it as tertiary or even lower which matches its classification (only meant for traffic from and to the town)? of course not. Well I disagree. IMHO we should tag what is 'on the ground', not invent things or try to tag what's in people's minds. If a government body gives a road it maintains some importance (or class/type) we should tag it accordingly. Another example is Bicycle streets. These are designated by municipalities in .nl (and .de) but they do not have a uniform importance: for cars they are e.g. a living street but for bicycles they are part of an important and much used route. These roads are classified specially by the road maintainer, and this should be reflected in the highway= value. What is the conclusion according to your proposal? Anyway how do you determine if something is a cycleway, from its importance and its position in the grid? That does not work while
Re: [OSM-talk-nl] Saaie, disfunctionele website
On Mon, 27 Jul 2009, Ante wrote: OSM is een groot project, met veel kanten. Het is van belang dat een aantal van die kanten op de website direct aanwezig zijn. Goede informatie voor beginners hoort daar zeker bij. Een andere kant is dat je als OSM ook je belangen wilt behartigen. Komt het NWB eindelijk eens beschikbaar? Waarom zijn de postcodes afgeschermd? Waarom krijgt de fietserbond veel geld maar is de kaart niet open, terwijl open data een overheidssteven is? Had dit niet beter gekund? Nieuws hierover moet op de voorpagina te vinden zijn. Als mensen er naar op zoek moeten ben je ze kwijt. Er zijn verschillende oplossingen. Om het blog te redden kan het makkelijkste teruggekeerd worden naar de oude blogtechniek. Het alternatief is dat er voor gezorgd moet worden dat de oude accounts, tags, etc werken met de nieuwe techniek. Ook moet het nieuws op de voorpagina te vinden zijn. Door het blog daar weer neer te zetten of door de koppen, etc over te nemen. Als de tweede oplossing te lastig is om snel te implementeren, zal er voor de eerste oplossing gekozen moeten worden. Het klinkt een beetje alsof je iets als Joomla! en drupal wil, behalve dat dit soort systemen ingewikkeld zijn in vergelijking met een simpele website, een wiki of een weblog. Zo een 'CMS' is volgens mij gebaseerd op nieuwsberichten, maar je moet er ook statische informatie in kwijt kunnen. Voordelen van een dergelijk systeem zijn dan: - meerdere mensen kunnen relatief eenvoudig aan de site werken (?) - (nieuws)berichtjes kunnen erop, dit werkt mogelijk beter dan een weblog - het is geen wiki, dus geen concurrent voor wiki.openstreetmap.org nadelen: - niet simpel op te zetten? - importeren berichten oude weblog(s)... Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] pier tagging
On Mon, 27 Jul 2009, Lambert Carsten wrote: On Monday 27 July 2009 22:05:51 Lennard wrote: Hans van Wijk wrote: Maar weet iemand de reden daarvoor ook? Een brug loopt in het algemeen niet door tot op een kruising. Ik ken anders in Amsterdam genoeg voorbeelden. Die regel (3 of meer wegen bij een kruispunt moeten alle dezelfde layer hebben) vindt ik niet goed. Overal stukjes weg toevoegen bij ongeveer alle bruggen in Amsterdam is onzinnig. Misschien dat keepright blij wordt als alle bruggen layer=0 krijgen en alle waterways en natural=water layer=-1 ! Dat moeten wij volgens mij ook niet doen. Toch is dat de situatie: het straatnivo ligt al gauw een meter boven de gemiddelde waterstand, en bruggen waar geen schepen onderdoor hoeven liggen vaak op straatnivo dus zijn (eigenlijk) niet level=1 maar level=0. Het probleem is misschien dat die levels vooral gebruikt worden om dingen netjes te kunnen stapelen bij het renderen. Het is de vraag of waterways e.d. met level=-1 goed gerenderd worden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk] Problem With Relations
On Sat, 25 Jul 2009, Karl Guggisberg wrote: Is this the expected behaviour? Is there a problem perhaps with that particular way? I think it isn't. I today applied the patch from the provider of the sort feature, but sorting of relations is still under development. We had tickets about *adding* members because of sorting, see http://josm.openstreetmap.de/ticket/3047 *Removing* members is not what I'd expect sorting to do, either. Could you file a trac ticket on http://josm.openstreetmap.org ? A fix for this issue is in ticket http://josm.openstreetmap.de/ticket/3102 Note that I wrote this sort function for polygons, e.g. simple boundaries and routes without loops. A relation that contains a closed way looks more like a multipolygon. Christiaan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] Relationseditor - Sortieren
On Fri, 10 Jul 2009, Jan Tappenbeck wrote: ich habe gerade gesehen das im Relationseditor ein Sortieren-Schalter vorhanden ist. Kann mir einer die Funktionsweise kurz erl?utern - insbesondere was -- bzw. -- bedeutet ? Die -- usw. haben nichts zu tun mit der Sortierfunktion. Sie zeigen nur wie die ways verbunden sind (statt connected wie bisher): -- : Endnode von diesem way ist Startnode n??chste way -- : Startnode Endnode usw. (-- und -- gibt es auch noch) Die Sortierfunktion versucht f??r jeds nelement ein Node oder Weg dazu zu finden. Wenn es kein verbunden Node oder Weg gibt f??r ein Element dann stoppt das sortieren. Christiaan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Tue, 7 Jul 2009, Philip Homburg wrote: Dat ligt niet aan de routeplanners maar aan de data. Werk aan de winkel dus! Dat klopt niet. Ik heb redelijk veel met http://yournavigation.org/ gespeeld (die natuurlijk gosmore als backend heeft) en recenter met ANDNAV2. En in beide gevallen zie je dat de navigatie software heel veel steken laat vallen. Heb je ook de andere 2 webrouteplanners bekeken? http://www.openrouteservice.org/ Deze is (voor zover ik weet) nog steeds niet helemaal open source ook al is ooit beloofd dat dit binnenkort zou gebeuren, op http://www.freeopenls.org/ De andere is http://www.cloudmade.com/ maar die doet het niet in mijn webbrowser. Met ORS ben ik tot nu toe eigenlijk alleen data fouten tegengekomen voor fietsrouting. Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. [zie volgende mail] Misschien is fiets/voetganger/etc. routing een goede applicatie is als niemand anders dat zo compleet aanbiedt als de osm/web-based routers. Met compleet bedoel ik zowel detail (fietsbruggen etc. die niet in google maps zitten) als geografische dekking (Europa of de hele wereld, terwijl de fietsersbond applicatie hoogstens heel nederland doet). Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ook in de data zitten veel fouten maar op route gebied is het model dan ook verre van compleet. Kun je eens wat voorbeelden noemen? Een paar voorbeelden: - De tagging standaards zijn gewoon fout. Voor een verboden in te rijden voor motorvoertuigen op meer dan twee wielen staat (op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging): motor_vehicle=no motorcycle=yes moped=yes mofa=yes Dat klopt niet want dan is de weg in beide richting afgesloten. In de praktijk wordt een oneway tag gebruikt, maar wat doe je dan weer met fietsen? Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Problematischer om te taggen vind ik een combinatie die ik op dezelfde rit tegenkwam: een onverplicht fietspad bord met daaronder 'uitgezonderd X' (aanwonenden ofzo). Dat is eigenlijk geen access tag maar een conditionele highway tag. - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Dat doe ik met een generieke access tag. Die moet iemand wel een keer gaan beschrijven op de wiki: access:motor_vehicle:backward=no access:motorcycle:backward=yes access:moped:backward=yes access:mofa:backward=yes Deze tags zijn dus de eenrichtingsversie van de algemene tags die bij dat bord horen, waarbij ik even aanneem dat het bord aan het 'eind' van de way staat. Het access: voorvoegsel kan eventueel weggelaten worden. Laten we het bij oneway houden. Een weg die enkelrichting is uitgezonderd fietsers wordt dan: oneway=yes + bicycle:oneway=no Die backward/forward syntax zal ook wel eens ingevoerd worden, maar is wat minder leesbaar wat mij betreft, en kan volgens mij meer gebruikt worden moest de straat ook echt verbodsborden hebben langs ??n zijde en geen gewone enkelrichtingsborden. Daar ging het hier over, het eerste verbodsbord op http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging . Nu maak je de discussie nodeloos ingewikkelder ): - In Nederland wordt een vrijliggend fietspad getagd als een losse cycleway. Maar dan weet de navigatie software niet dat je daar wel verplicht bent om te fietsen. Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Oh, wat een verschrikkelijk slecht idee om dat te doen :-) Temeer omdat die wegen in bepaalde situaties die categorie?n juist wel toelaten. Ken de exacte regels van Nederland niet, maar hier mogen bij gebrek aan begaanbare bermen of voetpad voetgangers de rijbaan gebruiken, ook al is er een verplicht fietspad (ze mogen ook het fietspad gebruiken, wat meeste mensen dan wel normaal doen). In NL moeten voetgangers het verplichte fietspad gebruiken! Dit staat ook op die wiki pagina. Wat mij betreft kan een routeplanner slim genoeg zijn om te zien dat er een fietspad ongeveer parallel loopt en dat als dusdanig als verplicht aanzien. Dat vind ik te veel werk voor een routeplanner om uit te zoeken. Maar dan is het natuurlijk belangrijk om verplichte fietspaden als dusdanig te mappen, en al wat niet als een verplicht fietspad aangeduid wordt ook niet zo te mappen, zodat dat bospaadje vijftien meter parallel naast de weg niet aanzien wordt als verplicht fietspad door de routeplanner. Een tag als highway=cycleway voorbehouden voor een fietspad dat als dusdanig bewegwijzerd is is dan een goed idee. Dat kan je met 'designated' doen, d.w.z. als bicycle=designated op een pad staat (door de highway tag of anders) dan is het een verplicht fietspad, als er bicycle=yes op staat dan niet. Dit heb ik op de wiki pagina http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging ook zo aangegeven voor het onverplichte fietspadbord. Maar met de goede bicycle=no etc. tags op de hoofdrijbaan hoeft een routing app dit verschil niet te maken. Maar ja, ik ga er ook van uit dat routeplanners slim genoeg worden om verkeersregels van elk land te kunnen begrijpen. Als een weg motorcar=no is (vertaling van het verbodsbord met auto-icoon naar tag) dan moet die bv. weten dat brommobielen of motorfietsen met zijspan ook niet op de weg mogen. Want het expliciet taggen voor elk mogelijk voertuig voor zo'n bord zoals http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging op het eerste zicht schijnt te doen is geen goed idee, want zoiets krijg je al met moeite foutloos opgesteld in zo'n tabel en regelmatig denk iemand aan een ander regeltje waardoor voor een verkeersbord ineens een nieuwe extra tag nodig is (voor het verbodsbord met een auto: zie brommobielen, quads, motorfietsen met zijspan etc, die volgens de wikipagina zijn toegelaten als je geen impliciete regels invoert), en je maakt het mappers ook niet makkelijk als je hen alles expliciet laat taggen. Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Ben Laenen wrote: Christiaan Welvaart wrote: Een routing app moet dan intern een lijst van transportmiddelen gaan aanleggen en voor elk land een andere mapping maken. Alles kan natuurlijk, dus schrijf maar een voorstel en zet het op de wiki (country specific access tag semantics for routing?), dan kunnen we kijken of mensen dit een goed idee vinden. country specific access tag semantics for routing, dat bestaat al hoor. Zoiets moet niet worden voorgesteld want ieder land doet het al. In land X bevat vehicle ruiters, in land Y niet. In land X mogen voetgangers op highway=cycleway, in land Y niet. access=destination is van toepassing op fietsers in land X, en niet in land Y. In België is moped zowel voor bromfietsers klasse A (snorfietsen) en B, en in NL willen jullie het Duitse mofa invoeren voor snorfietsen, en moped voor enkel onze klasse B, enzovoort. Je zegt hier nu wel dat 'het al bestaat', maar waar kan ik dit op de wiki teruglezen? En dan heb ik het niet over verschillende beschrijvingen voor elk land-project want dat noem ik eerder chaos. En aangezien het al bestaat en routers al een lijst hebben van regels voor elk land, kan je er beter ook maar deftig gebruik van maken om tagging regels in Welke router heeft dat dan? Gosmore doet niets land specifieks volgens mij en traveling salesman alleen maxspeed de laatste keer dat ik ernaar keek. je land niet nodeloos moeilijk te maken om het te proberen in te passen in een internationale omgeving, een utopie die niet mogelijk is omdat het al anders is in elk land. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Jawel want dan geef je op de weg aan: foot=no bicycle=no mofa=no . Dit moet ik nog duidelijk op die wiki pagina zetten. Dat zou kunnen, maar persoonlijk zou ik liever zien dat daar een relatie voor komt en dat de routing software het dan uitzoekt. Dat zou ook bij een ventweg de extra naam schelen. Er zijn natuurlijk ook heel veel situaties waar wel een verbodsbord bij de hoofdrijbaan staat, soms overbodig. Hiervoor zal je meestal toch access tags op de weg moeten zetten, wat betekent dat de toegankelijkheid van een weg voor een bepaald voortbewegingsmiddel op minstens 2 manieren beschreven kan zijn. Dit lijkt een voorstel in deze richting te zijn: http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Een toegangelijker OSM, deel 2
On Wed, 8 Jul 2009, Philip Homburg wrote: Ik probeerde voor de grap even Amsterdam-Stadskanaal, en ORS gaat via de Afsluitdijk, dus dat is niet optimaal. Lijkt idd een fout in de routing app want door waypoints toe te voegen kan ik de reistijd korter maken. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Mon, 15 Jun 2009, Lambert Carsten wrote: On Sunday 14 June 2009 23:55:15 Christiaan Welvaart wrote: On Sun, 14 Jun 2009, Lambert Carsten wrote: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.359638tlon=4.906853v=bicyclefast=0layer=mapnik Helaas doet yournavigation het op dit moment het niet goed. Ik had beter een screenshot kunnen bijvoegen. (De tunnel en bijbehorend stuk weg heb ik inmiddels met bicycle=no en foot=no getagged, dus het komt wel goed met die 'shortest' route in die laatste link). Wat voor borden staan erbij? Zie voor tagging voorbeelden: http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging Waar doel je op? Dat je niet door die tunnel mag fietsen of lopen weet ik zo wel. Of een brommer er ook niet door mag zal ik volgende keer dat ik er langs kom nagaan. Yournavigation gaf een route voor de fiets die door die tunnel ging en ik wilde slechts aangeven dat het mij daar niet om ging. Mijn reactie was off-topic. Maar het ging me inderdaad om snorfiets/bromfiets access. De 'snelle' route ging over de Singelgracht, langs de Spinozastraat, stukje Sarphatistraat om weer over de Singelgracht te gaan in plaats van gewoon de Mauritskade te volgen zoals de kortste route. Ik snap (ook) niet wat die 'snelle' optie doet, ik gebruik altijd 'korste' route. openrouteservice.org heeft die optie niet eens voor fietsers en voetgangers. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Mon, 15 Jun 2009, Rejo Zenger wrote: ++ 15/06/09 11:59 +0200 - Christiaan Welvaart: De 'snelle' route ging over de Singelgracht, langs de Spinozastraat, stukje Sarphatistraat om weer over de Singelgracht te gaan in plaats van gewoon de Mauritskade te volgen zoals de kortste route. Ik snap (ook) niet wat die 'snelle' optie doet, ik gebruik altijd 'korste' route. openrouteservice.org heeft die optie niet eens voor fietsers en voetgangers. Just to make sure: je snapt wat het wezenlijke verschil is tussen die twee opties en je snapt specifiek deze situatie niet of is je dat verschil tussen die twee sowieso niet duidelijk? Het laatste, d.w.z. ik vraag me af hoe een snelheidsverschil berekend kan worden tussen twee routes voor fietsers m.b.v. data in osm. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] weesperstraat/sarphatistraat-mauritskade
On Sun, 14 Jun 2009, Lambert Carsten wrote: http://www.yournavigation.org/?flat=52.361942flon=4.917075tlat=52.359638tlon=4.906853v=bicyclefast=0layer=mapnik (De tunnel en bijbehorend stuk weg heb ik inmiddels met bicycle=no en foot=no getagged, dus het komt wel goed met die 'shortest' route in die laatste link). Wat voor borden staan erbij? Zie voor tagging voorbeelden: http://wiki.openstreetmap.org/wiki/NL:The_Netherlands_roads_tagging Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] relatie bij punt
On Mon, 8 Jun 2009, Lennard wrote: Rene Dohmen wrote: De reden om een punt tot rotonde te verheffen was overigens om een geharrewar met relaties te vermijden (maar daar ben ik dan ook een beginner voor). Rotondes zijn inderdaad geen handige constructies, voor relaties en routes. :/ Als je elk segment van de rotonde als aparte weg tekent is er toch enkel probleem? Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] relatie bij punt
On Tue, 9 Jun 2009, Lennard wrote: Christiaan Welvaart wrote: Rotondes zijn inderdaad geen handige constructies, voor relaties en routes. :/ Als je elk segment van de rotonde als aparte weg tekent is er toch enkel probleem? Het wordt nog leuker/interessanter/een nachtmerrie* als er een vrijliggend fietspad om de rotonde ligt, en de rotonde zelf is ook nog een fietsknooppunt. Als je echt 3 verschillende kanten op kan fietsen op die rotonde, misschien moet je dan een fietsknooppunt relatie op de hele rotonde (het fietspad) zetten? Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Cycleway/footway [was: relatie bij punt]
On Tue, 9 Jun 2009, Ben Laenen wrote: On Tuesday 09 June 2009, Myckel Habets wrote: Rene Dohmen rdohmen+osm-talk...@gmail.com schreef: - als er pedestrian gekozen is in OSM, maar er ook fietsers rijden is dan niet een cycleway beter? Mijn ervaring is dat vaak wel aangegeven staat of iets een voetpad of fietspad is. Tot daar volledig akkoord, een cycleway is voor een fietspad, en een footway voor een voetpad. Is dat niet het geval, dan kijk ik hoe het op dat moment gebruikt wordt (als genoeg mensen van de weg gebruik maken) of hoe het wegdek er uit ziet (geheel vast geasfalteerd of toch nog wat los asfalt er boven op/ruw vast wegdek). Is er dan nog onduidelijkheid, dan tag ik het als cycleway met foot=yes. En dat vind ik helemaal niet zo. Je gaat zo beginnen interpreteren, en de volgende mapper die langskomt zal het anders zien en de mapper daarna zal ook weer een ander idee hebben over hoe het gebruikt wordt, omdat er misschien net een horde mountainbikers langs komt gereden, of omdat er net een stoet ruiters passeert. Interpreteren door naar actueel gebruik te kijken lijkt me ook niet handig. Laten we de verkeersregels erbij nemen, en die zeggen dat standaard alles mag op een pad wat erop kan als er geen verkeersborden staan. Dus hoe ga je bijvoorbeeld ooit een deftige routeplanner maken als je het pad waar ruiters mogen tagt met cycleway? Dus, wat niet is bewegwijzerd als een fietspad (zij het met zo'n bord fietspad of zo'n rond blauw bord) kan geen cycleway zijn, en wat niet zo'n rond blauw bord met een voetganger heeft kan geen footway zijn. Vanaf dan wordt het path als er geen auto's kunnen rijden. Zo simpel is het toch weer niet. Binnen de bebouwde kom liggen paden die eruit zien als fietspaden maar geen bord hebben. Daar kan je in principe ook met een motor rijden, maar dat gaat niemand doen. Ook staat er vaak een paaltje aan het begin, wat toch een aanwijzing is over het type weg. Die ronde blauwe borden zijn eigenlijk alleen nodig op fietspaden langs wegen, dus bij sommige 'shortcut' fietspaden staat geen bord. Je kan dan wel proberen te interpreteren en highway=path plus allerlei access tags erop zetten, maar het is gewoon een fietpad dus highway=cycleway is hier beter. Buiten de bebouwde kom zal dit veel minder vaak voorkomen. Wegbeheerders zetten gewoon niet altijd goede borden neer, bijvoorbeeld staat er in Amersfoort een bord 'verboden voor brommers' op een plek waar bromfietsers de parallelweg op moeten (dus geen fietspad). Daar zou je in theorie op de hoofdrijbaan mogen fietsen, wil je dat dan zo taggen? Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Cycleway/footway [was: relatie bij punt]
On Tue, 9 Jun 2009, Christiaan Welvaart wrote: Zo simpel is het toch weer niet. Binnen de bebouwde kom liggen paden die eruit zien als fietspaden maar geen bord hebben. Daar kan je in principe ook met een motor rijden, maar dat gaat niemand doen. Ook staat Ik had beter moeten kijken, een highway=path mag je natuurlijk alleen met paard/fiets/te voet overheen. Paardrijden weet ik alleen erg weinig van. Er lopen soms paarden op fietspaden, terwijl dat blijkbaar niet mag(?). En een paaltje midden op een (smal) fietspad, ga je daar met een paard langs? Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen taggen
On Fri, 29 May 2009, Eugene van der Pijll wrote: Christiaan Welvaart schreef: On Thu, 28 May 2009, Lennard wrote: Blijft over de kwestie van tagging. Ik ben er nog steeds voor om het onder admin_level te scharen. Voor woonplaatsen zou boundary=town kunnen werken (wat moet boundary=civil voorstellen?). Boundary=town heeft als nadeel dat het verwarring oproept met place=town, wat een specifiekere betekenis heeft (een plaats met tussen 10.000 en 100.000 inwoners). En voor de grens van een gehucht is boundary=town raar. admin_level=X heeft als nadeel dat dat niet zegt dat deze grenzen met adressering te maken hebben. Op een gegeven moment moeten deze grenzen gebruikt gaan worden voor iets als de internationale Namefinder service, om adressen te zoeken. Standaard zal toch in alle boundary=administrative gezocht worden? Dan zouden we hoogstens waterschappen en deelgemeenten uit kunnen sluiten. Je moet toch ook op land en provincie kunnen zoeken? Er zijn verschillende woonplaatsen met dezelfde naam in Nederland, en het is gebruikelijk om dan de provincie te vermelden. Overigens moeten we de waterschappen ook nog een keer kwijt zien te raken in het model. Die grenzen lopen vaak totaal niet gelijk met gemeentegrenzen. boundary=administrative, admin_level=5 Slecht idee, want sommige waterschappen bevinden zich in 2 provincies. Het admin_level-systeem is hierarchisch opgebouwd; iedere grens die getagd is op niveau 2 (Nederland) is tegelijk een 4-grens (provincie), en iedere provincie-grens is een gemeente-grens. Toch is een waterschapsgrens een 'administrative boundary'. Moeten deze tags sowieso niet alleen op relaties komen te staan? Dan speelt dit probleem volgens mij minder of niet. Toepassingen die de afzonderlijke ways gebruiken raken in de war als we van dat principe afstappen. Dit zegt me even niets... Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen taggen
On Fri, 29 May 2009, Lennard wrote: In Nederland hebben we overigens ook nog de COROP-regio's (NUTS 3), die de provincies weer opdelen. Die zouden beter op admin_level=5 passen dan waterschappen. Dit zijn toch echt geen boundary=administrative grenzen, maar eerder boundary=statistical, nuts_level=3 . Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen taggen
On Fri, 29 May 2009, Lennard wrote: Christiaan Welvaart wrote: Dit zijn toch echt geen boundary=administrative grenzen, maar eerder boundary=statistical, nuts_level=3 . Vertel dat de andere landen maar die NUTS-3 hebben gedefiniëerd binnen hun admin_level's. :-) In België zijn het de arondissementen: admin_level=7 In Duitsland de Landkreise: admin_level=6 In Zweden de Län: admin_level=4 Misschien zijn dat wel bestuurlijke eenheden? Het is niet raar dat NUTS indelingen daarmee samenvallen. Ook in Nederland gebeurt dat met andere niveau's. Maar een puur statistische (artificiele) indeling zoals COROP moet je niet met boundary=administrative taggen lijkt me. Anyway, het COROP-verhaal... wie hier had er al eerder van gehoord? De indeling van de COROP-regio's is de bevolking vast totaal onbekend. Nooit eerder van gehoord idd. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen taggen
On Fri, 29 May 2009, Colin Smale wrote: Bovendien, niet alle woonplaatsen op de blauwe borden zijn woonplaatsen in de zin van een woonplaatsbesluit. Er zijn veel dorpjes of gehuchten met een eigen naam op de bebouwdekomborden die in het woonplaatsbesluit geen zelfstandige woonplaats zijn. Dat betekent dat aan een bebouwde kom grens ook een naam moet kunnen hangen, en zo zit het al in osm (landuse=residential, place=x) denk ik. Moeten die ook een admin_level krijgen? En moet er dan een verschil gemaakt worden tussen postadressen (BAG-alleen woonplaatsen) en route plannen, waar je neem ik aan elke bebouwde kom naam mag gebruiken, want die staat mogelijk aangeven op verkeersborden. Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Woonplaatsen taggen
On Thu, 28 May 2009, Lennard wrote: Blijft over de kwestie van tagging. Ik ben er nog steeds voor om het onder admin_level te scharen. admin_level zelf doet niet zo veel, het gaat om de boundary tag lijkt me. Voor woonplaatsen zou boundary=town kunnen werken (wat moet boundary=civil voorstellen?). Maar boundary=administrative is misschien helemaal niet raar: deze grenzen zijn belangrijk voor dingen als postadressen en carnavalsnamen, en de bekende blauwe bebouwde-kom-borden natuurlijk. Het voorstel voor de admin_level waardes vind ik dan prima. Voor waterschappen gaan er toch al boundaries door elkaar lopen. Overigens moeten we de waterschappen ook nog een keer kwijt zien te raken in het model. Die grenzen lopen vaak totaal niet gelijk met gemeentegrenzen. boundary=administrative, admin_level=5 Christiaan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
