Re: [Talk-transit] JOSM Plugin
On Sat, Aug 22, 2009 at 5:06 PM, Roland Olbricht roland.olbri...@gmx.dewrote: I would like to add to the map the bus routes of Wuppertal. After starting with a sample (4 out of about 50 routes), it turned out to be a tedious task due to poor tool support. Thus, I'm thinking about writing a JOSM plugin to simplify editing. Nice work on setting out to map the bus routes of Wuppertal (do you have a link? I must confess I have no idea where that is). I'm not sure whether it'd be more or less tedious to write a plugin for JOSM, but good luck if you decide to have a go. Personally, I find the online Potlatch editor works pretty well for tagging long distance routes (and if you learn the keyboard shortcuts, it's pretty quick to keep adding the same relation to a way). There doesn't seem to be consenus about what representation to use. There are some, partly contradictive, propositions http://wiki.openstreetmap.org/wiki/NaPTAN http://wiki.openstreetmap.org/wiki/Public_transport http://wiki.openstreetmap.org/wiki/User%3AOxomoa/Public_transport_schema (and probably others) Yes - public transport mapping is still a fairly new activity, and so there are a few different ways that people have conceived of doing it. I've been trying to promote http://wiki.openstreetmap.org/wiki/Public_transport as a place where we can document the different tagging schemas in existence, but documentation is still a little patchy. Please feel free to help out! - I'd like to differentiate between networks for different times of the day. For example, for the Paris bus network there are even distinct maps: http://www.ratp.info/orienter/bus.php The network has services that run only during daytime, services running only in the evening, services running in the evening a different mission than during daytime and services running always the same mission. Interesting! One idea might be to use a network=* tag. Alternatively, there might be some form of hours-of-operation tag that we could either re-use or propose. http://wiki.openstreetmap.org/wiki/Public_transport suggests using service=*, but I don't think this is in wide-spread usage yet (or has even been discussed?). The only thing we probably shouldn't do is to use another relation to group the services together - as that'd be a form of categorisation, which isn't what relations are designed for. - Some of the services run through loops. E.g. ABF---CD || +E---+ they run ABECD in one direction and DCFBECFBA in the other direction. The standard route model with unordered data does not allow to distinguish this from ABECFBECD forth and DCFBA back. As I understand it, the ways SHOULD be order. Also, if we go with the notion of using on-way 'stop points' (ie nodes in the highway representing where the buses stop, rather than the nodes beside the highway representing where passengers wait), then those nodes should be included within the relation too, in order. (This is already done for some train services). That said, I don't think one way or node can belong to the same relation more than once! So you wouldn't be able to map the 'loop' perfectly yet. - I'd like to give some indication about connections between different services. Some services always wait for each other to allow to change quickly. Some services intentionally have coordinated timetables, i.e. the busses of line 627 and 637 partly run in parallel. One is departing at a stop at 00 und 20, the other at 40, so they offer together a ride every 20 minutes. I suspect that might be a little out-of-scope for a map...? Perhaps concentrate on mapping the routes first? Frankie -- Frankie Roberto Experience Designer, Rattle 0114 2706977 http://www.rattlecentral.com ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] JOSM Plugin
On 24 Aug 2009, at 20:18, Péter Connell wrote: Wonder if we need some openjourneyplanner thing - obviously a massive task. ... but who owns bus timetables? The argument is raging as we speak This is a great blog post on the subject which shows how hard the agencies are being pushed at present:- http://news.cnet.com/8301-19882_3-10315749-250.html?part=rsssubj=newstag=2547-1_3-0-5 At ITO we are pushing transport authorities virtually every day to get hold of the data under a commercial agreement where we pay them, but even that is hard! I am sure that in time the deal will be that the information is available without charge. Imo, we can't expect to maintain accurate timetables without access to the official data. It just isn't practical and sustainable to track all the detail and all the changes over time without it. And of course, the range of services which are suddenly available to authorities who release their data is growing by the day. Regards, Peter *strokes beard* ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[talk-ph] donation to OSMF or OSM-Philippines
Thanks in part to OSM project, I am getting some bread out of small mapping projects. As a way of giving back, I try to negotiate with the client that portions of the data collected should be donated to OSM. Some agree and I am processing some of it from a recent mapping trip. Another option would be to donate some cash directly to the community. OSMF have the mechanism for receiving donation, but I personally wanted that this go directly to the OSM Philippines. Prior to creating a donation mechanism would be to set-up the Phil. local chapter. That being said, any particular wishlist the group want donated? GPS, cash, event sponsorship? -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [Talk-si] Dovoljenje za uvoz meje
Sem videl, da si se ze zmenil glede morebitnih konfliktov pri SLO-CRO meji... Super :) lpi 2009/8/23 Stefan Baebler stefan.baeb...@gmail.com Ha, pri ogledu obstoječih relacij [1] sem opazil svežo južno mejo, uvoženo iz wikimedie, s prošnjo po izboljšavi: http://www.openstreetmap.org/browse/way/39438746 Urejeno ob: nedelja, 23. avgust 2009 20:02 + Uredil: mvrban Različica: 1 V paketu sprememb: 2234718 Oznake: admin_level = 2 boundary = administrative left:country = Slovenia name = Border SI-HR note = rough estimate in some places, please refine right:country = Croatia source = WIkimedia recif map In avtorjev vnos v dnevnik: http://www.openstreetmap.org/user/mvrban/diary/7626 lp, Štefan [1] http://www.openstreetmap.org/browse/relation/16483 in http://www.openstreetmap.org/browse/relation/16438 ___ Talk-si mailing list Talk-si@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-si
[OSM-legal-talk] wikitude content
Hi, After checking if something like wikitude could be done using OSM content i found some info that made me wonder if wikitude content could be imported into OSM. http://www.wikitude.org/add-content In the 2nd message on this page you'll read With regards to intellectual property, Wiktude.me will be implemented under a Creative Commons Attribution-Sharealike 3.0 Unported License. Could anyone give an answer wether it is legal to import POI location+information from Wikitude.me ? Doing this would ofcourse be very useful since it would add several thousands of POI's to OSM. regards, -joel ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] wikitude content
--- On Tue, 25/8/09, Joel joelheeth...@gmail.com wrote: Doing this would ofcourse be very useful since it would add several thousands of POI's to OSM. If you do end up importing, make sure you check there is no similar POI already in the DB :) ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, Aug 24, 2009 at 3:39 PM, David Paleinod.pale...@gmail.com wrote: On Mon, 24 Aug 2009 08:53:53 +1000, Roy Wallace wrote: On Sun, Aug 23, 2009 at 8:48 PM, David Paleinod.pale...@gmail.com wrote: Hello, I'd like to start discussion on the deprecation of the Tag:highway=stop in favour of using stop=yes/both/-1. First impression: the value of the tag is extremely ambiguous, and in no way self-explanatory. I don't like it at all. It has the same values as oneway=*. If you use Key:oneway, you know how to use Key:stop. 1) no, it doesn't (yes/both/-1 vs yes/no/-1) 2) the meaning of yes and -1 is different for oneway! (yes means forward as opposed to on the last node; -1 means in the reverse direction as opposed to on the first node) Seriously, stop=-1 is not self-explanatory! Even if the values of oneway matched up (which they don't), it still wouldn't make stop=-1 self-explanatory. Aren't we tagging what we see in the real world? I'm of the opposite opinion, we tag stop *signs* (horizontal or vertical signs), and we're trying to relate those signs to the junction they have effect on. If you want to put a stop *sign* on the map, use a separate node with traffic_sign=*. If you want to describe an attribute of the intersection of ways, it's quite alright to assign this attribute to the way/intersection itself, because it is indeed an attribute of the way/intersection. How about stop=at_last_node, stop=at_first_node and stop=at_first_and_last_node? More verbose, but a lot clearer than yes/-1/both. That can be done too. More concise: stop=first (-1) stop=last (yes) stop=both (both) Hrmm that is more concise, but I think less self-explanatory (remember that not everyone reads the wiki before editing). E.g. stop=both could be misunderstood to mean both directions, or both intersecting ways, etc. Also, need to clarify something...: Let's say way A is drawn from West to East, then at some point becomes (intersects with) way B, which continues to the East. And let's say East-bound travelers have to *stop* at the junction (for some reason), but West-bound travelers don't. This would be tagged as A being stop=at_last_node. Right? For West-bound travelers, at the instant they cross from B to A, this would imply that they should stop, because they're at the last_node of A. Which is not the case. In other words, it would seem to me that the proposal needs clarification in the form of something like: The stop=* tag is applied to a way to specify the node at which the stop sign applies. However, the stop sign only applies when the node is approached from the way that is tagged. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Escalators and Travalators
Stephen Hope wrote: Can I suggest that the documentation for the human conveyor has a section that states clearly that it is not for goods, and pointing to the goods tagging. And maybe the reverse in the other tag. This can and should be done this way. Hopefully, editor preset makers and translators will also take care not to choose misleading descriptions. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Mon, 24/8/09, Roy Wallace waldo000...@gmail.com wrote: stop=first (-1) stop=last (yes) stop=both (both) Hrmm that is more concise, but I think less self-explanatory (remember that not everyone reads the wiki before editing). E.g. stop=both could be misunderstood to mean both directions, or both intersecting ways, etc. What happens at T intersections where there is a stop sign on all ways, and cross intersection with 4 stop signs, the US version of a roundabout effectively. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, Aug 24, 2009 at 5:44 PM, John Smithdelta_foxt...@yahoo.com wrote: What happens at T intersections where there is a stop sign on all ways, and cross intersection with 4 stop signs, the US version of a roundabout effectively. The ways must be split so that they end (or begin) at the intersection. (This is required for most of the relation proposals anyway, IIRC.) Then, each way to which a stop sign applies should be tagged with stop=at_last_node (or stop=at_first_node). Seems simple enough. It's a pity that _last_ and/or _first must be specified, but that is the only way you get away with not making a relation - it encodes way and node information in a single tag. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Mon, 24/8/09, Roy Wallace waldo000...@gmail.com wrote: The ways must be split so that they end (or begin) at the intersection. (This is required for most of the relation proposals anyway, IIRC.) Then, each way to which a stop sign applies should be tagged with stop=at_last_node (or stop=at_first_node). Seems simple enough. It's a pity that _last_ and/or _first must be specified, but that is the only way you get away with not making a relation - it encodes way and node information in a single tag. I liked your suggestion of putting a node just before the intersection and tagging it, making relations and splitting ways sounds like something very convulted just for a stop sign so most people probably won't be bothered. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
Hi Alexander, Nice to see it popular, however... a few of us like to use a twitter search for openstreetmap to see what humans are saying but recently pretty much all of the tweets we receive for this search are from these bots. Would it be possible to reduce the level of spam - one example could be for the bots to use the shorturl (osm.org) or other short url service instead of the full openstreetmap.org url? Cheers, Tim 2009/8/20 Alexander Klink o...@alech.de: Hi everyone, This weekend, I hacked together a quick twitter bot, which now tweets all changesets in a certain are (in my case, Darmstadt, Germany) - see http://twitter.com/osm_darmstadt I've found it quite useful thus far, on the one hand I write better changeset comments, because I know they will be on Twitter, on the other hand, I see what happens in my community. If you want to run a similar bot, you can find the source at http://git.alech.de/?p=osm_twitter_bots.git Alternatively, I can add a bit of code to run more than one bot at a time and run a few of them for you (until I hit the Twitter API limits), I'd only need a name and a bounding box for that. Cheers, Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKjO3arNikioikZhERAi5AAKC5KuRFHQ5uh8ylmIAVIFinU8T8iACg03az 2ueMj6UmU+N7HIlPyKMlnZI= =T0Ab -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changes to Key:access wiki page
Christiaan Welvaart wrote: 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? There is no need to list keys because it can be used for every access-related key. Nevertheless, I'll probably create a more detailed page about conditional tagging in the future which can include base keys. 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. This principle makes understanding and evaluating the tags much easier, imo. To get a value for maxheight, you check all maxheight:* keys and nothing else. The same goes for oneway and all other base keys. 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. 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. In practice, this means that :backward will rarely be useful for bicycle, it makes more sense in combination with maxspeed and sometimes other base keys. 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? There were some suggestions to use brackets instead of colons for this (such as bicycle[backward]=no or hgv[06:00-10:00]=delivery) because conditions are not what colons have been used for before - for example, they don not have a defined order. Probably, though, colons are better anyway because using different syntax for different postfix semantics would only lead to confusion and inconsistent uses... 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). Ok, thanks, I now understand what you mean. I thought it had something to do with the access values (forestry, delivery and so on), because except for destination, they are not mentioned by your description at all. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On 24/08/2009, at 8:53 AM, Roy Wallace wrote: I don't like this, because before is arbitrary. If the stop requirement applies to the intersection, I think it should be applied to the intersection itself (either directly or as a member of a relation). I agree that these kind of things should be related to the intersection or way, rather than an arbitrary node before the intersection. What happens when someone wants to reverse the direction of the way? Currently you need to check the tags on the way, in case one of them is direction-dependent - I don't want to have to start checking all the 'nearby' nodes in case one of them has a tag which is dependent on the direction of the way. Personally, I think that using a relation (and splitting the way if necessary) would be nicer than having to check a bunch of nodes in case one of them has an way-direction-sensitive tag on it. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
On 24 Aug 2009, at 09:35, Tim Waters (chippy) wrote: Hi Alexander, Nice to see it popular, however... a few of us like to use a twitter search for openstreetmap to see what humans are saying but recently pretty much all of the tweets we receive for this search are from these bots. Would it be possible to reduce the level of spam - one example could be for the bots to use the shorturl (osm.org) or other short url service instead of the full openstreetmap.org url? +1 My current search is openstreetmap OR #osm, and it is really annoying to see all these uninsteresting twitters. There currently isn't a shortlink for the browse pages. Instead you'll need to use a third party service. Personally I wouldn't want every edit in an area, just a daily or hourly summary of the number of changes. Shaun Cheers, Tim 2009/8/20 Alexander Klink o...@alech.de: Hi everyone, This weekend, I hacked together a quick twitter bot, which now tweets all changesets in a certain are (in my case, Darmstadt, Germany) - see http://twitter.com/osm_darmstadt I've found it quite useful thus far, on the one hand I write better changeset comments, because I know they will be on Twitter, on the other hand, I see what happens in my community. If you want to run a similar bot, you can find the source at http://git.alech.de/?p=osm_twitter_bots.git Alternatively, I can add a bit of code to run more than one bot at a time and run a few of them for you (until I hit the Twitter API limits), I'd only need a name and a bounding box for that. Cheers, Alex -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) iD8DBQFKjO3arNikioikZhERAi5AAKC5KuRFHQ5uh8ylmIAVIFinU8T8iACg03az 2ueMj6UmU+N7HIlPyKMlnZI= =T0Ab -END PGP SIGNATURE- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Duplicate TIGER ways along county lines
When I'm fixing these, I just delete one of the ways in OSM and make sure that all the other connections are correct. It really doesn't matter about the tiger tags. As I don't know where there are county boundaries, I've just been leaving them as is (though occasionally been having to move them out of the way). Shaun On 24 Aug 2009, at 03:51, dasdje...@comcast.net wrote: Good evening, I have been editing the map around Denver, CO, but so far have avoided fixing duplicate ways straddling county lines. I.e., one physical way is represented by two ways, one for each county. For a correct and visually pleasing map, ease in joining intersecting ways, etc., I think it would be better to have only a single merged way on the map corresponding to the lone physical way. Will that agree with OSM standards? If it will, some tags and values may have to be modified. Assuming merging the ways in this manner is acceptable: How necessary is it to preserve left and right county names (the county line is present and should have this information)? How necessary is it to preserve left and right zip codes in the way data? (These are frequently inaccurate, and I would prefer not to have to research them). Should the two different TLIDs be combined in the TLID tag and separated with a semi-colon? Some county lines are conveniently located along divided highways. In these cases, I have been simply migrating each of the two ways to the correct side of the median while paying careful attention to the way’s direction and the various left and right tags. Thanks for any input. Dave J ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, Aug 24, 2009 at 6:22 PM, John Smithdelta_foxt...@yahoo.com wrote: I liked your suggestion of putting a node just before the intersection and tagging it, making relations and splitting ways sounds like something very convulted just for a stop sign so most people probably won't be bothered. It wasn't my suggestion. I don't like the idea of putting a node just before the intersection, because that is arbitrary. If we're tagging an attribute of the way, tag the way - if we're tagging an attribute of the intersection, tag the intersection. I don't know why you make the comment that making relations and splitting ways is convoluted. One of the main reasons for David's proposal here is to avoid the need for a relation. And splitting ways is already quite a common way to deal with these issues in OSM, is it not (e.g. turn restrictions)? As for whether people will be bothered to tag a way, well, I'm not sure. But I don't think mappers are generally lazy. Prone to misunderstanding and confusion, sure, but not lazy. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Mon, 24/8/09, Roy Wallace waldo000...@gmail.com wrote: It wasn't my suggestion. I don't like the idea of putting a node just before the intersection, because that is arbitrary. If we're tagging an attribute of the way, tag the way - if we're tagging an attribute of the intersection, tag the intersection. So tag it to the side the road where the GPS cords are then. I don't know why you make the comment that making relations and splitting ways is convoluted. One of the main reasons for David's proposal here is to avoid the need for a relation. And splitting ways is already quite a common way to deal with these issues in OSM, is it not (e.g. turn restrictions)? I didn't say that I agreed with that practice either. As for whether people will be bothered to tag a way, well, I'm not sure. But I don't think mappers are generally lazy. Prone to misunderstanding and confusion, sure, but not lazy. Some people aren't interested in the finer points of mapping, especially when you have a blank canvas. Going out of your way to map stop signs in a difficult way isn't high on the priority list when streets aren't mapped yet. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OSMdoc.com - Tagwatch like interface for viewing tag data
Hi! I believe I never officially 'announced' OSMdoc on this mailing list I'd like to do this now: http://osmdoc.com It is a site using a JavaScript interface to view tag usage data. It uses the whole planet and the data can be easily sorted and filtered. That sums it up already. It has some but not all features of Dirk Stoecker's original Tagwatch (http://tagwatch.stoecker.eu/). OSMdoc on the other hand has a few features that the original doesn't have. I'm announcing it today because I just updated the site with fresh data and a few other new things - Changeset Tags are now supported (only six different tags have been used so far) - Data is from the 2009/08/12 planet snapshot (1.029.615.736 Tags) - Keys and Values have a tab that displays possible misspellings. It generates those by calculating the Damerau-Levenshtein distance and displaying every key/value with a distance of 1 (http://en.wikipedia.org/wiki/Damerau-Levenshtein_distance) The site is in a mix of german and english at the moment and several things might not work...correct translations, feature requests, bug reports, criticism, etc. are always welcome! Cheers, Lars ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdoc.com - Tagwatch like interface for viewing tag data
Of course there is a problem right after announcing it. I know what the problem is and I'll fix it later this day. Unfortunately I had to take the application offline for the time being as it caused heavy load on the database. I'll post again when the problem has been fixed. Sorry! Lars ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
John Smith wrote: --- On Mon, 24/8/09, Roy Wallace waldo000...@gmail.com wrote: The ways must be split so that they end (or begin) at the intersection. (This is required for most of the relation proposals anyway, IIRC.) Then, each way to which a stop sign applies should be tagged with stop=at_last_node (or stop=at_first_node). Seems simple enough. It's a pity that _last_ and/or _first must be specified, but that is the only way you get away with not making a relation - it encodes way and node information in a single tag. I liked your suggestion of putting a node just before the intersection and tagging it, making relations and splitting ways sounds like something very convulted just for a stop sign so most people probably won't be bothered. The exact problem here is that the 'STOP' requirement only relates to the junction with another road and is therefore not a tag of the way or the intersection, but rather information relating to approaching one from the other. Adding an extra node does make sense, but probably needs a 'relation' to the intersection as well? In any case the direction through this new node is the critical piece of information? Tagging ways would require that every section of a way is broken up. I'm thinking of some route around here that have several intersections along them, many but not all of which are compulsory stop along that single way. Simply adding nodes on the correct side of each intersection would be somewhat easier to implement, while currently these restrictions are not recorded. The information is only really needed for routing software, where the trip time will be affected by HAVING to slow to a stop for each of those junctions on a route, but in this case, the exact location is not critical, as in practice one physically stops short of the actual intersection anyway. -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
--- On Mon, 24/8/09, Lester Caine les...@lsces.co.uk wrote: Adding an extra node does make sense, but probably needs a 'relation' to the intersection as well? In any case the direction through this new node is the critical piece of information? Tagging ways would require that every section of a way is broken up. I'm thinking of some route around here that have several intersections along them, many but not all of which are compulsory stop along that single way. Simply adding nodes on the correct side of each intersection would be somewhat easier to implement, while currently these restrictions are not recorded. I've seen a lot of talk about stop signs, but in Australia there is also give way signs, which can imped flow of traffic similar to stop signs. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdoc.com - Tagwatch like interface for viewing tag data
It's back online. The old version has been online for the last two hours. But now you can view the new data again. I had to limit it a bit though. You can't filter or sort the values for keys which have more than 100.000 distinct values anymore. This shouldn't be a big thing because it mainly affects the import tags (AND_..., tiger, ...) Lars ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, 24 Aug 2009 17:00:14 +1000, Roy Wallace wrote: On Mon, Aug 24, 2009 at 3:39 PM, David Paleinod.pale...@gmail.com wrote: On Mon, 24 Aug 2009 08:53:53 +1000, Roy Wallace wrote: On Sun, Aug 23, 2009 at 8:48 PM, David Paleinod.pale...@gmail.com wrote: Hello, I'd like to start discussion on the deprecation of the Tag:highway=stop in favour of using stop=yes/both/-1. First impression: the value of the tag is extremely ambiguous, and in no way self-explanatory. I don't like it at all. It has the same values as oneway=*. If you use Key:oneway, you know how to use Key:stop. 1) no, it doesn't (yes/both/-1 vs yes/no/-1) Fair enough. 2) the meaning of yes and -1 is different for oneway! (yes means forward as opposed to on the last node; -1 means in the reverse direction as opposed to on the first node) Think broader: yes might mean apply this in the same direction of the way, while -1 → opposite direction. However, I don't want to nitpick about this ;-) Seriously, stop=-1 is not self-explanatory! Even if the values of oneway matched up (which they don't), it still wouldn't make stop=-1 self-explanatory. Ok, fine. Aren't we tagging what we see in the real world? I'm of the opposite opinion, we tag stop *signs* (horizontal or vertical signs), and we're trying to relate those signs to the junction they have effect on. If you want to put a stop *sign* on the map, use a separate node with traffic_sign=*. If you want to describe an attribute of the intersection of ways, it's quite alright to assign this attribute to the way/intersection itself, because it is indeed an attribute of the way/intersection. Both things are related -- you shouldn't use Key:stop if there's no stop sign in the real world. How about stop=at_last_node, stop=at_first_node and stop=at_first_and_last_node? More verbose, but a lot clearer than yes/-1/both. That can be done too. More concise: stop=first (-1) stop=last (yes) stop=both (both) Hrmm that is more concise, but I think less self-explanatory (remember that not everyone reads the wiki before editing). Well, they must IMHO. The wiki explains the ontology of the tags we're using, and the wiki is the main regulamentation for tags. Otherwise we go wild, and everyone uses what she likes best. E.g. stop=both could be misunderstood to mean both directions, or both intersecting ways, etc. stop=both_sides? Propose something :-) Also, need to clarify something...: Let's say way A is drawn from West to East, then at some point becomes (intersects with) way B, which continues to the East. And let's say East-bound travelers have to *stop* at the junction (for some reason), but West-bound travelers don't. If I understood East-bound and West-bound correctly, you mean: http://imagebin.ca/view/bJWJB6.html ? This would be tagged as A being stop=at_last_node. Right? No, it would be stop=at_first_node (or whatever we decide it to be) assigned to the second segment of B. [1] For West-bound travelers, at the instant they cross from B to A, From the drawing I made above, B has no West-bound travelers. Maybe I misunderstood your description? this would imply that they should stop, because they're at the last_node of A. Which is not the case. In other words, it would seem to me that the proposal needs clarification in the form of something like: The stop=* tag is applied to a way to specify the node at which the stop sign applies. However, the stop sign only applies when the node is approached from the way that is tagged. [1] the use of first_node, first, -1, whatever, means that the stop applies to people coming from the opposite direction the way is drawn. This is basically what you're suggesting here, I suppose? Probably some drawing by you would be best! ;) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
Shaun McDonald wrote: On 24 Aug 2009, at 09:35, Tim Waters (chippy) wrote: Hi Alexander, Nice to see it popular, however... a few of us like to use a twitter search for openstreetmap to see what humans are saying but recently pretty much all of the tweets we receive for this search are from these bots. Would it be possible to reduce the level of spam - one example could be for the bots to use the shorturl (osm.org) or other short url service instead of the full openstreetmap.org url? +1 My current search is openstreetmap OR #osm, and it is really annoying to see all these uninsteresting twitters. There currently isn't a shortlink for the browse pages. Instead you'll need to use a third party service. Personally I wouldn't want every edit in an area, just a daily or hourly summary of the number of changes. Alexander - I think if you urlencode a URL before passing it to twitter, twitter will automatically shorten it using the bit.ly service. Might be something to look into. Then neither openstreetmap.org or osm.org will be used for the URLs. Andy -- Andy PGP Key ID: 0xDC1B5864 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdoc.com - Tagwatch like interface for viewing tag data
2009/8/24 Lars Francke lars.fran...@gmail.com: It uses the whole planet and the data can be easily sorted and filtered. are you sure it uses the whole planet? I get 2 results for amenity=drinking_water, but I have just in the Rome-area already inserted more than 500 of them. Please check if you are really using all data, and not just e.g. a Germany-extract. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging continuous flow intersections
(I suppose your reply was meant to t...@? If not, sorry for posting it) On Mon, 24 Aug 2009 13:32:06 +0100, Matt Williams wrote: 2009/8/24 David Paleino d.pale...@gmail.com: On Sun, 23 Aug 2009 18:11:59 -0500, David Lynch wrote: I suspect that I'd end up creating a set of ways that look something like this, plus a whole bunch of oneway tags and turn restrictions: http://dl1050.dyndns.org:/images/osm/cfi.png Thanks for the suggestion -- but I'd avoid drawing different ways for different lanes in a single carriageway. In some cases it's acceptable to do that. As long as there's either a physical barrier or a hard no-changing-lanes restriction between the lanes in question. There's no physical barrier, and the lanes are divided by continuous lines -- that would be a no-changing-lanes restriction, but I'd still be uncomfortable with drawing two separate ways -- that doesn't reflect real world. Satellite image: http://maps.google.com/?ie=UTF8ll=38.12436,13.355808spn=0.001091,0.002411t=kz=19 (the street from NW is the one from S in my drawing -- http://imagebin.ca/view/SjGkG4.html ) If you zoom in, you can clearly see the horizontal signals (at least at the NW street, there's some shadow hiding those in the SW one). If there are no other suggestions, I'll try to think at something :/ Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
On 24 Aug 2009, at 17:03, Andrew Ayre wrote: Alexander - I think if you urlencode a URL before passing it to twitter, twitter will automatically shorten it using the bit.ly service. Might be something to look into. Then neither openstreetmap.org or osm.org will be used for the URLs. Alternatively would it be worth having the bots add #bot or something similar onto their messages and then filtering them out? John___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSMdoc.com - Tagwatch like interface for viewing tag data
2009/8/24 Martin Koppenhoefer dieterdre...@gmail.com: 2009/8/24 Lars Francke lars.fran...@gmail.com: It uses the whole planet and the data can be easily sorted and filtered. are you sure it uses the whole planet? I get 2 results for amenity=drinking_water, but I have just in the Rome-area already inserted more than 500 of them. sorry for the noise. It seems all right now ;-) http://osmdoc.com/de/tag/amenity/drinking_water I was checking drinking_water as a tag, not as a value ;-) cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
2009/8/24 Andrew Ayre a...@britishideas.com: Alexander - I think if you urlencode a URL before passing it to twitter, twitter will automatically shorten it using the bit.ly service. Might be something to look into. Then neither openstreetmap.org or osm.org will be used for the URLs. it depends on the length, if they're short enough, the original URL is kept. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
Am Montag, 24. August 2009 schrieb John McKerrell: On 24 Aug 2009, at 17:03, Andrew Ayre wrote: Alexander - I think if you urlencode a URL before passing it to twitter, twitter will automatically shorten it using the bit.ly service. Might be something to look into. Then neither openstreetmap.org or osm.org will be used for the URLs. Alternatively would it be worth having the bots add #bot or something similar onto their messages and then filtering them out? You get a list of all bots by looking at the followers of @osm_bots For now, you could block those accounts. Mitja ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging continuous flow intersections
On Mon, Aug 24, 2009 at 12:06 PM, David Paleinod.pale...@gmail.com wrote: There's no physical barrier, and the lanes are divided by continuous lines -- that would be a no-changing-lanes restriction, but I'd still be uncomfortable with drawing two separate ways -- that doesn't reflect real world. Satellite image: http://maps.google.com/?ie=UTF8ll=38.12436,13.355808spn=0.001091,0.002411t=kz=19 (the street from NW is the one from S in my drawing -- http://imagebin.ca/view/SjGkG4.html ) If you zoom in, you can clearly see the horizontal signals (at least at the NW street, there's some shadow hiding those in the SW one). If there are no other suggestions, I'll try to think at something :/ You also referred to http://en.wikipedia.org/wiki/Continuous_flow_intersection I don't remember ever seeing one of these in the wild. I don't think that the intersection that you are looking at is a continuous flow intersection as described in the wikipedia article. It appears to be a simple cross junction of two one way roads. Is that correct? If so I would map it with a single node at two crossing, one-way, ways. Here, in Ontario Canada, this junction would have no special signage, other than the one-way arrows (and do not enter, for the opposite). We have Right turn allowed on red light. http://en.wikipedia.org/wiki/Right_turn_on_red This is abstracted locally to include left turn allowed on red when the junction is one-way to one-way. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging continuous flow intersections
On Mon, 24 Aug 2009 12:42:53 -0400, Richard Weait wrote: On Mon, Aug 24, 2009 at 12:06 PM, David Paleinod.pale...@gmail.com wrote: There's no physical barrier, and the lanes are divided by continuous lines -- that would be a no-changing-lanes restriction, but I'd still be uncomfortable with drawing two separate ways -- that doesn't reflect real world. Satellite image: http://maps.google.com/?ie=UTF8ll=38.12436,13.355808spn=0.001091,0.002411t=kz=19 (the street from NW is the one from S in my drawing -- http://imagebin.ca/view/SjGkG4.html ) If you zoom in, you can clearly see the horizontal signals (at least at the NW street, there's some shadow hiding those in the SW one). If there are no other suggestions, I'll try to think at something :/ You also referred to http://en.wikipedia.org/wiki/Continuous_flow_intersection I don't remember ever seeing one of these in the wild. I don't think that the intersection that you are looking at is a continuous flow intersection as described in the wikipedia article. It appears to be a simple cross junction of two one way roads. Is that correct? If so I would map it with a single node at two crossing, one-way, ways. You can't obviously see the vertical signals from the aerial imagery. In the street coming from NW, there is a continuous flow to left -- that means you can go left even with a Red-light-signal. In the street coming from SW, there is a continuous flow to right -- you can go right regardless of the traffic signal once again. They *are* CFIs. Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging continuous flow intersections
On Sun, 23 Aug 2009 18:11:59 -0500, David Lynch wrote: I suspect that I'd end up creating a set of ways that look something like this, plus a whole bunch of oneway tags and turn restrictions: http://dl1050.dyndns.org:/images/osm/cfi.png Wouldn't that make routers say turn left and at the traffic signals continue stright ahead, and then at the next traffix signals turn slightly left and finally turn left when it should be turn left at the traffic signals? Konrad ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Local Chapters Call Today
There was an attempted Local Chapters Working Group call today, Andrew Turner, Vincent Meurisse and myself called in. We think the call needs to be rescheduled, it appears not many people could make it. Is there a better time for those that are interested? From looking at the wiki the time excluded those in Australia, New Zealand and Asia. Also it was noted that there wasn't a call in number for the Phillippines. http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Meetings/24-August-2009 In light of the recent board elections is there going to be a shift in leadership of the group as well? Thanks, Kate Chapman ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New proposal: Bad data
The new Bad data proposal is a scheme to mark traced aerial photography or maps as out of date or otherwise unreliable so that they can be obscured in editors and users dont copy details into the OSM database reducing its accuracy. http://wiki.openstreetmap.org/wiki/Bad_data ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
Hi, On Mon, Aug 24, 2009 at 10:51:23AM +0100, Shaun McDonald wrote: a few of us like to use a twitter search for openstreetmap to see what humans are saying but recently pretty much all of the tweets we receive for this search are from these bots. Would it be possible to reduce the level of spam - one example could be for the bots to use the shorturl (osm.org) or other short url service instead of the full openstreetmap.org url? +1 My current search is openstreetmap OR #osm, and it is really annoying to see all these uninsteresting twitters. Sorry, didn't think about that. I've changed the bot to use osm.org, my bots will use that right away, I hope the other bot owners will update as well. There currently isn't a shortlink for the browse pages. Instead you'll need to use a third party service. Hmmm, www.osm.org/browse/changeset/$id seems to work fine for me. I already use tweak.tk if the tweet is too long, but I like it better to see the real URL (see the tr.im disaster) if possible. For the search, -changeset works fine as well (because I guess users will typically not tweet about changesets). Personally I wouldn't want every edit in an area, just a daily or hourly summary of the number of changes. I was thinking about that as well, I could make it an option. I guess it would be interesting to see and compare different countries that way as well. I'll probably need to do this via the planet.osm diffs, though, I guess, because it would be a waste to download all the changesets via the API just to get the number of them. Using the planet.osm, several statistics bots would be possible as well, like number of roads added, number of cafés, bus stops, etc. Cheers, Alex signature.asc Description: Digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging continuous flow intersections
On Mon, Aug 24, 2009 at 12:25, Konrad Skerikon...@skeri.com wrote: On Sun, 23 Aug 2009 18:11:59 -0500, David Lynch wrote: I suspect that I'd end up creating a set of ways that look something like this, plus a whole bunch of oneway tags and turn restrictions: http://dl1050.dyndns.org:/images/osm/cfi.png Wouldn't that make routers say turn left and at the traffic signals continue stright ahead, and then at the next traffix signals turn slightly left and finally turn left when it should be turn left at the traffic signals? You pass through one set of signals when you cross the oncoming traffic lanes, and another set when completing the turn onto the cross street, so I would probably describe it as turn slightly left at the first traffic signal, go (distance) and turn left onto (street) at the second signal. I tend to err on the side of tagging every node where traffic might possibly stop for a red light, and there isn't a good way at the moment to indicate that there are two or more nodes tagged with highway=traffic_signal but only one set of signals. -- David J. Lynch djly...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Local Chapters Call Today
Hi Kate + group, There's been a bit of confusion around Local Chapters meetings - I tried to sort out the confusion last week, but clearly did not do a very good job ;-) Sorry if you guys wasted your time today. A lot of the community felt that the best way forward for Local Chapters would be to make comments based on the proposed Local Chapters agreement on the wiki: http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters Anyone who is interested in Local Chapters should add comments to the proposed agreement. The aim is to find all there areas where there are disagreements and then try and solve them one by one. What I've suggested before is: What I propose is that we set a date of the 18th September (4 weeks away) in which we as a group of people interested in Local Chapters can discuss and debate the way forward and then deliver a second draft of the agreement(s) that will allow those Local Chapters who are ready to go to sign up and get going. In the meantime, we'll mainly focus on textual commenting. If we need phone calls, we can arrange them as needed. The good news, especially for the patient and keen Locals like Ivan, is that the OSM-F board agreed last Saturday that we could go ahead and start to form local chapters based on a provisional agreement. The board felt - and I hope this is reflected by the community - that having one master agreement for all local chapters would not work and that the role of the Local Chapters group should be to negotiate an agreement with each local chapter that takes into account local specifics (like how hard it is to set up a non-profit in the USA or why Dutch groups can't have members and so on). Of course, some things will need to be the same for each agreement. Local Chapters will have to be democratic, have a mission statement that falls in line with that of the OSM-F, and so on. We also talked about membership fees. I really like the idea of using a PPP index ( http://en.wikipedia.org/wiki/Purchasing_power_parity) to set a variable rate membership as a way to help inclusiveness. The next question of course, is who's chairing the Local Chapters working group. I was previously the chair, and the OSM-F board have previously agreed that only board members can chair working groups. So the group is chair-less. I'm happy to continue as interim chairman or whatever. AFAIK, Mike Collinson is in the process of setting up a Local Chapters mailing list, which should make communication easier. -- Nick On Mon, Aug 24, 2009 at 6:40 PM, Kate Chapman k...@maploser.com wrote: There was an attempted Local Chapters Working Group call today, Andrew Turner, Vincent Meurisse and myself called in. We think the call needs to be rescheduled, it appears not many people could make it. Is there a better time for those that are interested? From looking at the wiki the time excluded those in Australia, New Zealand and Asia. Also it was noted that there wasn't a call in number for the Phillippines. http://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/Meetings/24-August-2009 In light of the recent board elections is there going to be a shift in leadership of the group as well? Thanks, Kate Chapman ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- -- Nick Black twitter.com/nick_b ___ 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
Christiaan Welvaart wrote: 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. Yes, it can be defined, of course. I believe that the results of an independent evaluation per base key rule comes close to what many people assume about the tag's meaning (its impossible to match all current expectations, unfortunately, because different people have different, sometimes contradicting opinions in absence of clear definitions) and are rather easy to understand. 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. I'm going to put together a comprehensive description of how I think access evaluation w.r.t. conditional tagging could work as soon as I have the time. I hope that this will make things clearer. Tobias Knerr ___ 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] [RFC] Deprecating the use of Tag :highway=stop in favour of Key:stop
Le lundi 24 août 2009 à 15:25, Lester Caine a écrit : Adding an extra node does make sense, but probably needs a 'relation' to the intersection as well? In any case the direction through this new node is the critical piece of information? Tagging ways would require that every section of a way is broken up. I'm thinking of some route around here that have several intersections along them, many but not all of which are compulsory stop along that single way. Simply adding nodes on the correct side of each intersection would be somewhat easier to implement, while currently these restrictions are not recorded. How about simply creating a relation with those two nodes? You have an intersection of two (or more) roads and when you come to that intersection from one particular road (in one particular direction) you have a stop. Then you add a node on that way before the intersection, then create a relation (let's say of type=stop, or any more self-explanatory value) where you have the stop node with role stop_from and the intersection with role stop_at. Such a scheme can be easily interpreted as: when you pass over a node highway=stop that is a member of a relation type=stop with role stop_from, then you must stop at the node of that relation that has the role stop_to. You might eventually add the way to the relation to avoid ambiguity in complex case, the way would have a role like stop_along and be interpreted to stop at the stop_at node only if travelling along that way. What do you think? -- Renaud Michel ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Twitter bots
On 24 Aug 2009, at 18:56, Alexander Klink wrote: Sorry, didn't think about that. I've changed the bot to use osm.org, my bots will use that right away, I hope the other bot owners will update as well. 8-) There currently isn't a shortlink for the browse pages. Instead you'll need to use a third party service. Hmmm, www.osm.org/browse/changeset/$id seems to work fine for me. I already use tweak.tk if the tweet is too long, but I like it better to see the real URL (see the tr.im disaster) if possible. You can drop the www. ;-) I was thinking of a shorter url such as osm.org/b/c/$id for browsing changeset. Then w for ways, n for nodes etc. Shaun smime.p7s Description: S/MIME cryptographic signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, Aug 24, 2009 at 11:25 PM, Lester Caineles...@lsces.co.uk wrote: The exact problem here is that the 'STOP' requirement only relates to the junction with another road and is therefore not a tag of the way or the intersection, but rather information relating to approaching one from the other. That's right. There's two acceptable approaches to dealing with this: 1) use a relation to relate the way and intersection - for this, I see nothing wrong with http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop or 2) use a way and an implicit reference to a node to relate the way and intersection - this is what David is proposing here: http://wiki.openstreetmap.org/wiki/Key:stop The implicit reference to a node is in the form of at_first_node/at_last_node, etc. So IMHO David's proposal is a good way to avoid the use of a relation - if that is what people want. I personally don't mind relations as they're more explicit and not dependent on way direction. Either way, you have to split the way at the junction where the stop sign applies. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Tue, Aug 25, 2009 at 12:23 AM, John Smithdelta_foxt...@yahoo.com wrote: I've seen a lot of talk about stop signs, but in Australia there is also give way signs, which can imped flow of traffic similar to stop signs. Replacing stop with give_way (or similar) should do the trick. The proposal could be extended to include this. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Mon, 24 Aug 2009 23:32:46 +0200, Renaud MICHEL wrote: Le lundi 24 août 2009 à 15:25, Lester Caine a écrit : Adding an extra node does make sense, but probably needs a 'relation' to the intersection as well? In any case the direction through this new node is the critical piece of information? Tagging ways would require that every section of a way is broken up. I'm thinking of some route around here that have several intersections along them, many but not all of which are compulsory stop along that single way. Simply adding nodes on the correct side of each intersection would be somewhat easier to implement, while currently these restrictions are not recorded. How about simply creating a relation with those two nodes? You have an intersection of two (or more) roads and when you come to that intersection from one particular road (in one particular direction) you have a stop. Then you add a node on that way before the intersection, then create a relation (let's say of type=stop, or any more self-explanatory value) where you have the stop node with role stop_from and the intersection with role stop_at. Sorry, this is useless. We could just use highway=stop and teach routing software that they're valid only if coming from a certain direction, decided on a distance-from-nearest-junction basis. This is what we're (I am, at least) trying to avoid: arbitrary placement of real-world nodes -- if we all had 1cm-resolution GPS units, then we would just use highway=stop. IMHO, YMMV. Such a scheme can be easily interpreted as: when you pass over a node highway=stop that is a member of a relation type=stop with role stop_from, then you must stop at the node of that relation that has the role stop_to. No, you must NOT. In this case, you would stop in the middle of the intersection. A stop signal instructs you to stop *before* the intersection. :) Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Local Chapters Call Today
El Lunes, 24 de Agosto de 2009, Nick Black escribió: The good news, especially for the patient and keen Locals like Ivan, is that the OSM-F board agreed last Saturday that we could go ahead and start to form local chapters based on a provisional agreement. /me jumps in joy :-D -- -- Iván Sánchez Ortega i...@sanchezortega.es Un ordenador no es un televisor ni un microondas, es una herramienta compleja. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Tue, 25 Aug 2009 07:54:00 +1000, Roy Wallace wrote: So IMHO David's proposal is a good way to avoid the use of a relation - if that is what people want. I personally don't mind relations as they're more explicit and not dependent on way direction. I don't mind relations either, I use lots of them -- just don't want to pollute the relations namespace where we could accomplish the same effect with a tag. Either way, I'm up to what the community decides/adopts :) David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Tue, Aug 25, 2009 at 1:58 AM, David Paleinod.pale...@gmail.com wrote: Well, they must IMHO. The wiki explains the ontology of the tags we're using, and the wiki is the main regulamentation for tags. Otherwise we go wild, and everyone uses what she likes best. Yes, but STILL - tags should be self-explanatory. It would make life easier for everyone (even those that DO read the wiki). People will make less mistakes if tags are self-explanatory. Self-explanatory tags are also easier to memorise. I'm not suggesting at all that people shouldn't read the wiki. E.g. stop=both could be misunderstood to mean both directions, or both intersecting ways, etc. stop=both_sides? Propose something :-) I already did: stop=at_last_node stop=at_first_node stop=at_first_and_last_node This is, after all, *exactly* what you're trying to denote. If I understood East-bound and West-bound correctly, you mean: http://imagebin.ca/view/bJWJB6.html Unfortunately I can't access that image :( See mine: http://imagebin.org/60947 So for A, stop=at_last_node. We need to make clear that the green car doesn't have to stop when it crosses the last node of A. Hence, maybe something like The stop sign only applies when the node is approached from the way that is tagged. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 60, Issue 157
Date: Tue, 25 Aug 2009 07:54:00 +1000 From: Roy Wallace waldo000...@gmail.com Subject: Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop To: Lester Caine les...@lsces.co.uk Cc: OSM Talk talk@openstreetmap.org Message-ID: 71fcecde0908241454t1e365257h7a1a861e4c008...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 On Mon, Aug 24, 2009 at 11:25 PM, Lester Caineles...@lsces.co.uk wrote: That's right. There's two acceptable approaches to dealing with this: 1) use a relation to relate the way and intersection - for this, I see nothing wrong with http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop or 2) use a way and an implicit reference to a node to relate the way and intersection - this is what David is proposing here: http://wiki.openstreetmap.org/wiki/Key:stop The implicit reference to a node is in the form of at_first_node/at_last_node, etc. Using a relation has some advantages: * it connects the stop requirement to the junction node (you can look at the junction node to see that there is a stop requirement) * if the way leading to the junction is split/reversed, the relation still works (although it will have two way members, so it's slightly broken) With the current editors, it's not hard to add relations, and a stop relation is almost self evident how it works when viewing it, but the tags proposed for the way needs to be looked up to be understandable. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Tue, 25 Aug 2009 08:16:34 +1000, Roy Wallace wrote:
On Tue, Aug 25, 2009 at 1:58 AM, David Paleinod.pale...@gmail.com wrote:
Well, they must IMHO. The wiki explains the ontology of the tags we're
using, and the wiki is the main regulamentation for tags. Otherwise we go
wild, and everyone uses what she likes best.
Yes, but STILL - tags should be self-explanatory. It would make life
easier for everyone (even those that DO read the wiki). People will
make less mistakes if tags are self-explanatory. Self-explanatory tags
are also easier to memorise. I'm not suggesting at all that people
shouldn't read the wiki.
Ok, I misunderstood you, sorry :)
E.g. stop=both could be misunderstood to mean both directions, or both
intersecting ways, etc.
stop=both_sides? Propose something :-)
I already did:
stop=at_last_node
stop=at_first_node
stop=at_first_and_last_node
This is, after all, *exactly* what you're trying to denote.
Yes, I don't particularly like the wording but, hey, I can't get everything
from life! ;)
If I understood East-bound and West-bound correctly, you mean:
http://imagebin.ca/view/bJWJB6.html
Unfortunately I can't access that image :( See mine: http://imagebin.org/60947
So for A, stop=at_last_node. We need to make clear that the green car
doesn't have to stop when it crosses the last node of A. Hence, maybe
something like The stop sign only applies when the node is approached
from the way that is tagged.
Ok, great, that's exactly what I understood from your last mail.
Yes, the stop sign only applies (with respect to the value
at_{last,first}_node) when it is approached from its own way.
In particular, the value at_first_node (in my/Stemby's proposal, -1), should
be used when the way is oneway=no [1], but for any reason we don't want to
change its direction (i.e. R in josm) -- the stop applies to the junction
which the first node of the way takes part to.
Hope this is clearer.
Still, like I said, I don't like the particular wording, I bet we can still
find something better. Sure your wording is much more self-explainatory than
mine.
Kindly,
David
[1] this is obvious -- having stop=at_first_node/stop=-1 in a oneway=yes way
would grant a maplint error (I'd put it even in JOSM's validator plugin)
--
. ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino
: :' : Linuxer #334216 --|-- http://www.hanskalabs.net/
`. `'` GPG: 1392B174 | http://snipr.com/qa_page
`- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174
signature.asc
Description: PGP signature
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
People, please *don't* CC me. I'm subscribed to the list. On Tue, 25 Aug 2009 01:02:30 +0200, Pieren wrote: Tagging a whole way just because you have to stop at the end is a deep modeling mistake. Please, explain why. There is no similarity between the oneway which applies to the way with a stop sign which applies to an intersection. I didn't say it is in similar to oneway. In some previous mail I explained it had the same tagging values as oneway (which seems like we're changing now), and in my last mail I explained one possible usecase which is totally *wrong* and should be detected. Anyway, I haven't thanked you yet for moving the page under Proposed_features/ :) →→ Thank you! Kindly, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Vol 60, Issue 157
2009/8/25 Martin Norbäck mar...@norpan.org: Using a relation has some advantages: * it connects the stop requirement to the junction node (you can look at the junction node to see that there is a stop requirement) * if the way leading to the junction is split/reversed, the relation still works (although it will have two way members, so it's slightly broken) With the current editors, it's not hard to add relations, and a stop relation is almost self evident how it works when viewing it, but the tags proposed for the way needs to be looked up to be understandable. Yep. On the other hand, tagging a way has an advantage: it avoids the need to add a relation. What is everyone's preference? I quite like the relation described at: http://wiki.openstreetmap.org/wiki/Proposed_features/Relation:type%3Dstop In fact, that relation avoids the need to split the way at the junction if the stop sign applies in both directions along the way through the junction. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [RFC] Deprecating the use of Tag:highway=stop in favour of Key:stop
On Tue, Aug 25, 2009 at 9:02 AM, Pierenpier...@gmail.com wrote: Tagging a whole way just because you have to stop at the end is a deep modeling mistake. There is no similarity between the oneway which applies to the way with a stop sign which applies to an intersection. I see what you mean, but the stop sign does NOT apply to just an intersection - it applies to a way(s) AND an intersection. This is because the applicability of the stop sign at an intersection might depend on your direction of approach. Hence the need to either 1) tag both the way and intersection explicitly (with a relation) or 2) tag the way explictly and intersection implicity (using at_*_node). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Maps-l] using default country name
2009/8/23 Peter Körner osm-li...@mazdermind.de: (1) Default tags can be changed. We should remember that default tags can be edited by somebody later and they will no longer be good for other languages. This fact speaks for both sides of the argument. If some feature's name changes (think, a street) you don't want to have to change 180 names in the name:*= tags. In the great majority of cases foreign names are based strictly on the native name. This will mark all all uses of the default name as not ok (in any language) (2) There is some inconsistency in default tags. Sometimes it's the English name, sometimes it's written in the Latin alphabet, local alphabet (e.g. Arabic) or both. I think Iran is spelt in Arabic, Comoros are spelt in both. Some people say Burma, some say Myanmar for various reasons. Yes, that's true. The default name should be how the name is spelled in this country (just as it is with city- and street-names). If there are two major languages in this country, both should be supplied. Additionally Burma is a pretty bad example because it's tagged incorrectly, the name= value should be using the native name and native alphabet, i.e. Burmese script, while right now it uses the english name. It's going to be fixed at one point. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Stream in a tunnel
This way: http://www.openstreetmap.org/browse/way/39456905 is marked as layer = -1, tunnel = yes, waterway = stream. I was expecting it to be rendered by Mapnik as a dashed line and paler to indicate it was underground, but I don't see that. Any ideas why? Andy -- Andy PGP Key ID: 0xDC1B5864 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Stream in a tunnel
Andrew Ayre wrote: This way: http://www.openstreetmap.org/browse/way/39456905 is marked as layer = -1, tunnel = yes, waterway = stream. I was expecting it to be rendered by Mapnik as a dashed line and paler to indicate it was underground, but I don't see that. Any ideas why? Yes. It was rendered as a tunnel, but then overwritten by the non-tunnel variant. I've committed a fix, which will probably show up on the map in a few days. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] XAPI URL for one way by ID?
hi, on API i can GET http://www.openstreetmap.org/api/0.6/way/Id using the same string on XAPI like http://osmxapi.hypercube.telascience.org/api/0.6/way/38427403 results in firefox can't find the file... initially I typed http://www.informationfreeway.org/api/0.6/way/23328268 (other id, ok...) but i was redirected. trying ...way[id=xxx] or Id=xxx didn't help either. so, question: how do i get exactly one way by id from xapi? the wiki page doesn't help me... thanks gerhard gary68 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] OSM Foundation bestuur
Gefeliciteerd Henk! betalen voor osmf lidmaatschap is tegen m'n prinicipes (we doen al genoeg voor osm), anders had je m'n stem gekregen Rob Op 24 augustus 2009 10:25 schreef Lambertus o...@na1400.info het volgende: Gefeliciteerd met je herverkiezing Henk! Alhoewel ik geen OSMF lid ben zou ik wel willen weten wat jou speerpunten voor de OSMF dit komende jaar zullen zijn. Staat dat ergens? Henk Hoff wrote: Mensen, Vandaag is de jaarvergadering (AGM) van de OpenStreetMap Foundation geweest in Londen. Met daarop volgend het vijfde verjaringsfeestje van OpenStreetMap. Het nieuwe bestuur van de Foundation (na stemmen) ziet er als volgt uit (in willekeurige volgorde): Steve Coast Andy Robinson Michael Collinson Mikel Maron Ulf Muller Simone Cortesi Henk Hoff Dat betekent dat Etienne Cherdlu en Nick Black niet herkozen zijn. Er zijn in totaal 177 stemmen uitgebracht (op een ledenaantal van 240), waarvan 161 via e-mail. Diegenen die gestemd hebben: bedankt namens de Foundation. Voor diegenen die ook op mij hebben gestemd: ook een hartelijk dank namens mijzelf. :-) Met vriendelijke groet, Henk Hoff ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Ik vond het voorstel op een andere mailinglijst: dat iedereen met een significante bijdrage automatisch lid is van de OSMF. De drempel tot lid worden is dan lager, alleen mensen die écht interesse voor OSM hebben betrek je op deze manier, mensen zonder de financiele middelen kunnen dan ook hun stem laten gelden (bijv. 3e wereld landen). De verkiezing zal dan democratischer zijn dan wanneer 240 betalende stemmen van de 150.000 geregistreerde gebruikers hun invloed uitoefenen. Misschien dat Henk zich hiervoor kan inzetten? Rob wrote: Gefeliciteerd Henk! betalen voor osmf lidmaatschap is tegen m'n prinicipes (we doen al genoeg voor osm), anders had je m'n stem gekregen Rob Op 24 augustus 2009 10:25 schreef Lambertus o...@na1400.info mailto:o...@na1400.info het volgende: Gefeliciteerd met je herverkiezing Henk! Alhoewel ik geen OSMF lid ben zou ik wel willen weten wat jou speerpunten voor de OSMF dit komende jaar zullen zijn. Staat dat ergens? Henk Hoff wrote: Mensen, Vandaag is de jaarvergadering (AGM) van de OpenStreetMap Foundation geweest in Londen. Met daarop volgend het vijfde verjaringsfeestje van OpenStreetMap. Het nieuwe bestuur van de Foundation (na stemmen) ziet er als volgt uit (in willekeurige volgorde): Steve Coast Andy Robinson Michael Collinson Mikel Maron Ulf Muller Simone Cortesi Henk Hoff Dat betekent dat Etienne Cherdlu en Nick Black niet herkozen zijn. Er zijn in totaal 177 stemmen uitgebracht (op een ledenaantal van 240), waarvan 161 via e-mail. Diegenen die gestemd hebben: bedankt namens de Foundation. Voor diegenen die ook op mij hebben gestemd: ook een hartelijk dank namens mijzelf. :-) Met vriendelijke groet, Henk Hoff ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Gefeliciteerd Henk! Ik heb nog een vraag, want ik begreep van jou dat o.a. Nick Black plannen had om een working group of iets gerelateerd te gaan vormen specifiek voor: user experience en de usability oftewel het verlagen van de drempel en het aantrekken van een groter publiek Is al bekend of iemand dit gaat continueren of blijft Nick hiervoor in beeld? Ik wil hier ook graag in deelnemen! ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Henk, beter laat dan nooit: Van harte gefeliciteerd met je herverkiezing. Welverdiend wat mij betreft, je inzet voor SOTM09 was fenomenaal en dat is hoe ik je (werk) voornamelijk heb meegemaakt. Ik hoop dat er het komend jaar (nog) meer communicatie vanuit de Foundation, bijvoorbeeld over de voortgang van het licentieproces, naar ons toe komt via talk-nl. Dat is toch wel een van de voordelen van een lokale representatie in het bestuur. Ik vind het jammer dat Nick niet herkozen is en hoop dat het negatieve sentiment dat in osmf-talk is gecreeerd door Frederik Ramm daar geen doorslaggevende rol in heeft gespeeld. In het algemeen vind ik het jammer dat de verkiezingen zo overschaduwd zijn door wantrouwen en moddergooien. Maar dat schijnt bij de politiek te horen. Wat vind jij hiervan? Groet Martijn martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes 2009/8/23 Henk Hoff h...@toffehoff.nl: Mensen, Vandaag is de jaarvergadering (AGM) van de OpenStreetMap Foundation geweest in Londen. Met daarop volgend het vijfde verjaringsfeestje van OpenStreetMap. Het nieuwe bestuur van de Foundation (na stemmen) ziet er als volgt uit (in willekeurige volgorde): Steve Coast Andy Robinson Michael Collinson Mikel Maron Ulf Muller Simone Cortesi Henk Hoff Dat betekent dat Etienne Cherdlu en Nick Black niet herkozen zijn. Er zijn in totaal 177 stemmen uitgebracht (op een ledenaantal van 240), waarvan 161 via e-mail. Diegenen die gestemd hebben: bedankt namens de Foundation. Voor diegenen die ook op mij hebben gestemd: ook een hartelijk dank namens mijzelf. :-) Met vriendelijke groet, Henk Hoff ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Ik denk dat het negatieve sentiment vooral wordt gevoed door het niet op alle fronten transparant acteren van de OSMF. Wanneer de foundation strikt voor haar doelstelling gaat en ook duidelijk en helder communiceert over haar activiteiten en afgeleide trajecten afketst of naar de community doorzet dan is er geen reden om modder te gooien. Het onduidelijk of niet communiceren wakkert negatieve gevoelens aan. Het probleem is inderdaad hetzelfde als in de politiek: Wanneer bepaalde zaken gesloten worden behandeld en later blijkt ineens iets te zijn gebeurd zonder dat de voorgeschiedenis openbaar is; dan zijn de poppen aan het dansen. Het grote Nee tegen Europa is hiervan een goed voorbeeld. Peilingen hebben uitgewezen dat het collectief Nee van de Nederlandse bevolking geen nee was tegen één europa, maar tegen de manier waarop de overheid het door onze strot probeerde te duwen. Martijn van Exel schreef: Ik vind het jammer dat Nick niet herkozen is en hoop dat het negatieve sentiment dat in osmf-talk is gecreeerd door Frederik Ramm daar geen doorslaggevende rol in heeft gespeeld. In het algemeen vind ik het jammer dat de verkiezingen zo overschaduwd zijn door wantrouwen en moddergooien. Maar dat schijnt bij de politiek te horen. Wat vind jij hiervan? Groet Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Het ging hier niet om een OSMF-interne aangelegenheid, maar om aantijgingen van Ramm jegens Cloudmade: de dubbele petten van Nick en Steve, en het feit dat er zich plotseling een vrij groot aantal Cloudmade-mensen had geregistreerd als lid van de Foundation. Ramm suggereerde dat hier een opzet in het spel was om de verkiezingen te beinvloeden en gebruikte gegevens die niet openbaar zijn - de ledenlijst van de OSMF - om zijn punt te maken. Dat die gegevens niet openbaar zijn, is overigens wel weer een OSMF-interne aangelegenheid. Dat het zo ontstane sentiment vervolgens verder *gevoed* wordt doordat de communicatie van de OSMF niet optimaal is, sluit ik trouwens niet uit. martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes 2009/8/24 Milo van der Linden m...@opengeo.nl: Ik denk dat het negatieve sentiment vooral wordt gevoed door het niet op alle fronten transparant acteren van de OSMF. Wanneer de foundation strikt voor haar doelstelling gaat en ook duidelijk en helder communiceert over haar activiteiten en afgeleide trajecten afketst of naar de community doorzet dan is er geen reden om modder te gooien. Het onduidelijk of niet communiceren wakkert negatieve gevoelens aan. Het probleem is inderdaad hetzelfde als in de politiek: Wanneer bepaalde zaken gesloten worden behandeld en later blijkt ineens iets te zijn gebeurd zonder dat de voorgeschiedenis openbaar is; dan zijn de poppen aan het dansen. Het grote Nee tegen Europa is hiervan een goed voorbeeld. Peilingen hebben uitgewezen dat het collectief Nee van de Nederlandse bevolking geen nee was tegen één europa, maar tegen de manier waarop de overheid het door onze strot probeerde te duwen. Martijn van Exel schreef: Ik vind het jammer dat Nick niet herkozen is en hoop dat het negatieve sentiment dat in osmf-talk is gecreeerd door Frederik Ramm daar geen doorslaggevende rol in heeft gespeeld. In het algemeen vind ik het jammer dat de verkiezingen zo overschaduwd zijn door wantrouwen en moddergooien. Maar dat schijnt bij de politiek te horen. Wat vind jij hiervan? Groet Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Nederlandstalige walking papers online!
Super Milo! Hij staat er ook tusse op http://www.openstreetmap.nl (als je een betere teksts hebt hoor ik het wel). On Saturday 22 August 2009 21:18:18 Milo van der Linden wrote: http://walking-papers.org/ signature.asc Description: This is a digitally signed message part. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
De OSMF is zich volgens mij goed bewust van het feit dat bewegingen in cloudmade verband met argusogen worden waargenomen. Wat Steve en/of Nick dus hadden kunnen doen was in detail uitleggen waarom er zoveel cloudmade personeel lid ging worden van de foundation met daarbij: - Motivatie voor het lidmaatschap - Intentie voor mate van bijdrage die de betreffende personen zouden kunnen doen binnen de OSMF (bepaalde expertise, zaken die cloudmade al geeft/gaat geven aan de community etc.) - De reden (Ik neem aan dat het vooral is om een financiële impuls in de vorm van de bijdragen van betreffende personen) Hiermee hadden ze op voorhand al het moddergooien kunnen voorkomen en hadden ze de criticasters de mogelijkheid gegeven om hun vragen rechtstreeks naar hen te richten. Nu is het hoogstwaarschijnlijk ontdekt en dan is een conflict snel geboren en aangezien de betrokken personen niet in beeld komen gaat het dan automatisch en plein publique Ook dit issue komt in mijn optiek dus neer op communiceren en had voorkomen kunnen worden. Regel 1 voor het correct omgaan met een community wanneer je een bestuursorgaan vormt: Wees altijd open over je motieven, ook al reflecteren deze niet die van iedereen, het geeft altijd ruimte voor dialoog in plaats van ruzie. Side note: Ik snap trouwens niet waarom de ledenlijst van de OSMF niet openbaar is? Dat de donaties wellicht anoniem worden gehouden vind ik wat anders, maar elk lid is gelijk en kan dus probleemloos worden getoond. Sterker nog, het zou kunnen motiveren om ook lid te worden. Wanneer de OSMF had aangegeven wa Martijn van Exel schreef: Het ging hier niet om een OSMF-interne aangelegenheid, maar om aantijgingen van Ramm jegens Cloudmade: de dubbele petten van Nick en Steve, en het feit dat er zich plotseling een vrij groot aantal Cloudmade-mensen had geregistreerd als lid van de Foundation. Ramm suggereerde dat hier een opzet in het spel was om de verkiezingen te beinvloeden en gebruikte gegevens die niet openbaar zijn - de ledenlijst van de OSMF - om zijn punt te maken. Dat die gegevens niet openbaar zijn, is overigens wel weer een OSMF-interne aangelegenheid. Dat het zo ontstane sentiment vervolgens verder *gevoed* wordt doordat de communicatie van de OSMF niet optimaal is, sluit ik trouwens niet uit. martijn van exel http://schaaltreinen.nl/ twitter / skype: mvexel flickr: rhodes 2009/8/24 Milo van der Linden m...@opengeo.nl: Ik denk dat het negatieve sentiment vooral wordt gevoed door het niet op alle fronten transparant acteren van de OSMF. Wanneer de foundation strikt voor haar doelstelling gaat en ook duidelijk en helder communiceert over haar activiteiten en afgeleide trajecten afketst of naar de community doorzet dan is er geen reden om modder te gooien. Het onduidelijk of niet communiceren wakkert negatieve gevoelens aan. Het probleem is inderdaad hetzelfde als in de politiek: Wanneer bepaalde zaken gesloten worden behandeld en later blijkt ineens iets te zijn gebeurd zonder dat de voorgeschiedenis openbaar is; dan zijn de poppen aan het dansen. Het grote Nee tegen Europa is hiervan een goed voorbeeld. Peilingen hebben uitgewezen dat het collectief Nee van de Nederlandse bevolking geen nee was tegen één europa, maar tegen de manier waarop de overheid het door onze strot probeerde te duwen. Martijn van Exel schreef: Ik vind het jammer dat Nick niet herkozen is en hoop dat het negatieve sentiment dat in osmf-talk is gecreeerd door Frederik Ramm daar geen doorslaggevende rol in heeft gespeeld. In het algemeen vind ik het jammer dat de verkiezingen zo overschaduwd zijn door wantrouwen en moddergooien. Maar dat schijnt bij de politiek te horen. Wat vind jij hiervan? Groet Martijn ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] map subdomein
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rob schreef: map.google.com http://map.google.com map.live.com http://map.live.com map.yahoo.com http://map.yahoo.com ..tile.openstreetmap.com http://tile.openstreetmap.com map of kaart klinkt toch logischer (voor het grote publiek) als subdomein om de kaart te bekijken dan tile kunnen we deze map of kaart (http://map.openstreetmap.nl) alias mappen naar tile.openstreetmap.nl http://tile.openstreetmap.nl ? Done! Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqSi/sACgkQYH1+F2Rqwn1WrgCeKkzTLBsnMtpDq8PuRcI48uQC 230AoIPe+Pmx/ya1JmLkbagvNkOkEWXG =aZYK -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] map subdomein
ik ben ontroerd ;) ligt zeker aan de dns dat dit nog niet werkt hiero ? http://map.openstreetmap.nl/ ps: aandachtspuntje, de favicon van de pagina's op het osm domein slaat ook nergens op.. (iets van vrijschrift?) Rob 2009/8/24 Stefan de Konink ste...@konink.de -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rob schreef: map.google.com http://map.google.com map.live.com http://map.live.com map.yahoo.com http://map.yahoo.com ..tile.openstreetmap.com http://tile.openstreetmap.com map of kaart klinkt toch logischer (voor het grote publiek) als subdomein om de kaart te bekijken dan tile kunnen we deze map of kaart (http://map.openstreetmap.nl) alias mappen naar tile.openstreetmap.nl http://tile.openstreetmap.nl ? Done! Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqSi/sACgkQYH1+F2Rqwn1WrgCeKkzTLBsnMtpDq8PuRcI48uQC 230AoIPe+Pmx/ya1JmLkbagvNkOkEWXG =aZYK -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] map subdomein
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Rob schreef: ik ben ontroerd ;) Beantwoord je andere mail dan ook eens ;) Ik zit boven het bestel knopje te wachten! ligt zeker aan de dns dat dit nog niet werkt hiero ? http://map.openstreetmap.nl/ Hier doet ie het ;) ps: aandachtspuntje, de favicon van de pagina's op het osm domein slaat ook nergens op.. (iets van vrijschrift?) Nee het is de 404 afbeelding. Mocht je nog eerders een nationalitische Nederlandse vlag hebben liggen houd ik me aanbevolen :) Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqSjk8ACgkQYH1+F2Rqwn31qgCgh+u/6uVD7DV+X0LKkEB43eTa 0ZcAmweSxaGOHVP60gcR8AJfO2Z0CuO6 =ewPB -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Side note: Ik snap trouwens niet waarom de ledenlijst van de OSMF niet openbaar is? Dat de donaties wellicht anoniem worden gehouden vind ik wat anders, maar elk lid is gelijk en kan dus probleemloos worden getoond. Sterker nog, het zou kunnen motiveren om ook lid te worden. Omdat mensen zoals bijvoorbeeld mijzelf niet willen dat hun adres misbruikt wordt voor spam e.d.? Openbaar maken van dit soort gegevens zal zeker voor een aantal mensen een drempel vormen. Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
On Monday 24 August 2009 15:18:10 Floris Looijesteijn wrote: Side note: Ik snap trouwens niet waarom de ledenlijst van de OSMF niet openbaar is? Dat de donaties wellicht anoniem worden gehouden vind ik wat anders, maar elk lid is gelijk en kan dus probleemloos worden getoond. Sterker nog, het zou kunnen motiveren om ook lid te worden. Omdat mensen zoals bijvoorbeeld mijzelf niet willen dat hun adres misbruikt wordt voor spam e.d.? Openbaar maken van dit soort gegevens zal zeker voor een aantal mensen een drempel vormen. Gewoon naam is toch verder prima (linkje naar je osm.org profiel of zo misschien). Snap dat adressen niet kunnen maar enkel naam lijkt me geen probleem. Groet, --Roeland signature.asc Description: This is a digitally signed message part. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Henk Hoff schreef: Dus dat mensen uit arme landen minder lidmaatschapsgeld zouden hoeven te betalen als mensen uit rijke landen. Hierover zouden jullie (OSM-F leden) het komende jaar mogelijk een voorstel voorbij kunnen zien komen Als niet-lid zou ik je toch willen wijzen op de Big-Mac index. http://nl.wikipedia.org/wiki/Big_Mac-index Stefan -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqSnXUACgkQYH1+F2Rqwn2IlwCfamIHJI7nYUtB0JqWIPHucps0 hcUAn3MnGLlvXVhe31ufORlM9h/L5Wx3 =uVp0 -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Henk Hoff schreef: 2009/8/24 Stefan de Konink ste...@konink.de: Henk Hoff schreef: Dus dat mensen uit arme landen minder lidmaatschapsgeld zouden hoeven te betalen als mensen uit rijke landen. Hierover zouden jullie (OSM-F leden) het komende jaar mogelijk een voorstel voorbij kunnen zien komen Als niet-lid zou ik je toch willen wijzen op de Big-Mac index. http://nl.wikipedia.org/wiki/Big_Mac-index Dank voor de tip. Sterker nog, hij was ook al even in de discussie in het bestuur ter sprake gekomen ;-) Dit betekent trouwens niet automatisch dat het ook deze index gaat worden GMTA :) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEAREKAAYFAkqSn5UACgkQYH1+F2Rqwn3MTACfUtXQf3zoEB0pz+tYaY7qdwN2 9W4An0ozyj9q/RLms7XZs85EkQOux+j+ =vBHP -END PGP SIGNATURE- ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Waar het mij om gaat is, dat de leden zelf moeten kunnen bepalen wie hun bestuur wordt. Zie ook de verkiezingen van afgelopen weekend: De leden vonden kennelijk niet dat er meerdere personen van één bedrijf in het bestuur moesten zitten. Kortom, de leden kunnen dit best zelf regelen zonder dat we hiervoor regeltjes gaan opstellen. Stel: twee mensen van één bedrijf mag niet. Maar wat dacht je van twee mensen die een persoonlijke relatie met elkaar hebben, of iemand de werkzaam is bij bv Navteq, of iemand die nog nooit een edit heeft gemaakt in OSM? Kortom, waar begin je en waar houdt het op? En trouwens, wie gaat bepalen of het een geldige mits op het verbod is? Moeten we voor die mensen dan ook niet een lijst met eisen hebben? Kortom, wanneer de kandidaten openheid van zaken geven tijdens de verkiezingen, kunnen de leden zelf beslissen of ze een uitzondering willen maken op een morele regel die zelf vinden. OK, dan geen MOETen wat betreft het openheid van zaken. Is dit beter: Het ligt in de lijn der verwachting dat de leden van de foundation een hoge mate van transparantie met betrekking tot de functies en belangen van de kandidaat-bestuurders verlangen; hetgeen tot uiting zou moeten komen in een morele verplichting bij de betrokken kandidaat-bestuurders, om een naar volledigheid reikende openheid te geven van hun nevenfuncties (zowel bezoldigd als onbezoldigd) en nadere belangen die van invloed kunnen zijn op zijn danwel haar functioneren in de door zijn/haar geambieerde functie. Lijkt me toch helder :-) Gr, Henk Op 24 augustus 2009 15:55 schreef ce-test, qualified testing bv - Gert Gremmen (g.grem...@cetest.nl) het volgende: Ik vind dat het bestuur bij voorkeur zo breed mogelijk moet zijn. Ik vind echter niet dat je hiervoor bepalingen in de statuten oid moet opnemen (bv er mag van een bedrijf maar één persoon in het bestuur zitten). Zo'n regel behoeft geen absoluut verbod te zijn, maar kan ook een verbod mits. Een goede argumentatie waarom wel 2 x lid, en/of het duidelijk maken van de belangen vóóraf is de beste methode om het type probleem zoals nu is gebeurt te voorkomen. Dat laatste zijn kunstmatige grepen, die in de praktijk niet werken. Want er is altijd wel weer een of andere loophole om erom heen te kunnen. Wat een onzin, we MOETEN wettelijk een rijbewijs hebben, maar er zijn wel duizend mogelijkheden om auto te rijden zonder rijbewijs. Daarom schaffen we die verplichting er een paraat te hebben nog niet af !!! Regels en wetgeving zijn er mede om de due diligence van de bevolking/bestuursleden te kunnen aantonen, nooit om absoluut te worden nageleefd. Sommigen die dat toch proberen worden (politie: 70km/h 's nachts geen kip op de weg, toch boete) gehaat door de geregelden. (Hadden we geen befehl ist befehl vroeger? Is ook afgeschaft !) Wél moet helder zijn (bij de verkiezingen) wat de belangen etc van elke kandidaat is/zijn. MOET ? : Dus toch een regeltje ? Henk, voor een politicus geen sterke bijdrage. Regards, Ing. Gert Gremmen g.grem...@cetest.nl www.cetest.nl Kiotoweg 363 3047 BG Rotterdam T 31(0)104152426 F 31(0)104154953 Before printing, think about the environment. -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Henk Hoff Verzonden: Monday, August 24, 2009 3:24 PM Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] OSM Foundation bestuur Inmiddels weer terug in NL. En dank voor de felicitaties. Als jullie met vragen en/of opmerkingen zitten, mail/bel me gerust. Toch even ingaan op een paar onderdelen: - Cloudmade vs OpenStreetMap Dat niet iedereen overtuigd is van de goede intenties van Nick en Steve inzake Cloudmade vs OpenStreetMap is ook het bestuur zich van bewust geweest. (ik praat in verleden tijd, aangezien ik nu even vanuit het perspectief van het oude bestuur redeneer). We zijn daar ook prudent mee omgegaan. Om een voorbeeld te noemen: als er ook maar een enigszins een vorm van belangenverstrengeling was bij besluitvorming, heeft Steve en/of Nick zich terug getrokken uit de besprekingen en de besluitvorming. Net als ik me heb teruggetrokken bij het besluit rondom de toewijziging van de State of the Map locatie. Had het negatieve sentiment met meer communicatie opgelost kunnen worden? Lastig te zeggen. Door continue te roepen dat er niets aan de hand is, roep je ook vragen op. Daarnaast: Nick en Steve hebben diverse keren aangegeven dat je ze kon bellen, mailen, skypen, IRC-en, whatever, mocht je meer duidelijk willen hebben. Ik denk dat iedereen, die samen met Steve en Nick hebben gewerkt dit kunnen onderschrijven. Tsja, als je kwaad wilt zien, dan zie je kwaadaardige dingen Even mijn persoonlijke mening hierover: Ik vind dat het bestuur bij voorkeur zo breed mogelijk moet zijn. Ik vind echter niet dat je hiervoor bepalingen in de statuten oid moet opnemen (bv er mag van een bedrijf
Re: [OSM-talk-nl] OSM Foundation bestuur
Hmmm, ik weet niet precies wat ik hier van moet vinden. ;-) Gr, Henk Op 24 augustus 2009 16:51 schreef Lambertus (o...@na1400.info) het volgende: Offtopic: ce-test, qualified testing bv - Gert Gremmen wrote: Henk, voor een politicus geen sterke bijdrage. Wat? Hoezo verwacht jij van een politicus een sterke bijdrage? Dat hoef je in Nederland vooral niet te verwachten! In welk land woon jij, dan ga ik kijken of emigratie een mogelijkheid is? ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Ik wil niet pietluttig doen, maar een naam is ook persoonlijke informatie ;-) Hoe dan ook, we hebben hier te maken met wetgeving die eisen en regels stelt aan het openbaar maken van ledenlijsten. Zie inline. Op 24 augustus 2009 16:16 schreef Milo van der Linden (m...@opengeo.nl) het volgende: Ik heb het niet over het vrijgeven van persoonlijke informatie. Er nog een aantal opties die vindbaar op de foundation site kunnen worden gezet: - Publiceer het aantal leden (Is nu ook niet op de OSMF website te vinden) Dat zou mogelijk kunnen. Ik zal het voorleggen aan onze ledenadministrateur - Publiceer alleen een lijst met voor of achternamen Zie bovenaan. - Publiceer een lijst met osm usernames (kun je meteen afgrendelen dat een osmf lid ook lid van de community dient te zijn) Een OSMF lid hoeft niet per definitie een community lid te zijn. - Publiceer het aantal OSMF leden per land. Wordt al lastig. Dit is afgeleide informatie van persoonlijke gegevens. Dit mag al behoorlijk snel niet. Alleen namen zou volgens mij voldoende zijn. Is de lijst wel inzichtelijk voor leden? Iedereen mag de ledenlijst inzien, mits ze daarvoor een verzoek indienen bij de ledenadministrateur omkleed met redenen. De aanvraag mag alleen worden gehonoreerd indien deze enkel te maken heeft met het lidmaatschap en de controle daarop. Dus geen mailing versturen oid. Leden kunnen dit gratis doen. Aan niet-leden mogen kosten berekend worden. Bovenstaande is zoals het beschreven staat in de Companies Act. We moeten dus ook op deze wijze handelen. Deze richtlijnen zijn mede gebaseerd op privacy wetgeving zoals die geldt voor de UK. Trouwens, probeer eens de officiele ledenlijst van de Nederlandse Wikimedia Foundation te pakken te krijgen ;-) Gr, Henk ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Quoting Henk Hoff toffeh...@gmail.com: Ik wil niet pietluttig doen, maar een naam is ook persoonlijke informatie ;-) Hoe dan ook, we hebben hier te maken met wetgeving die eisen en regels stelt aan het openbaar maken van ledenlijsten. Klopt. Om het effe over een heel andere boeg te gooien, namen publiceren kan ook niet zomaar met stamboomonderzoek. Je hebt hiervoor toestemming nodig. Tenminste, dit geldt alleen voor levende personen, en ik ga ervan uit dat alle OSMF-leden nog in leven zijn ;) - Publiceer een lijst met osm usernames (kun je meteen afgrendelen dat een osmf lid ook lid van de community dient te zijn) Een OSMF lid hoeft niet per definitie een community lid te zijn. Mijn gevoel zegt direct ja, dat moet, maar het is niet handhaafbaar. Wat zegt een kaal useraccount nou? Het is ook mogelijk om op andere manieren aan OSM bij te dragen (development, financieel, etc.). Als iemand de moeite neemt om lid te worden, ga ik ervan uit dat hij wel een mate van betrokkenheid heeft, en dat niet voor eigen gewin doet. - Publiceer het aantal OSMF leden per land. Wordt al lastig. Dit is afgeleide informatie van persoonlijke gegevens. Dit mag al behoorlijk snel niet. Ik weet niet hoe het in de UK is, maar het lijkt mij dat als je er geen persoonlijke gegevens uit kunt distilleren, dan moet dat wel kunnen. Het wordt anders als je gegevens toevoegt waaruit je mogelijk wel informatie kunt afleiden die op individuen betrekking heeft (en niet op landen). Groeten, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OSM Foundation bestuur
Quoting ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: Wél moet helder zijn (bij de verkiezingen) wat de belangen etc van elke kandidaat is/zijn. MOET ? : Dus toch een regeltje ? Het lijkt me eerder dat het in de belang van de kandidaten zelf is dat ze dit doen. Hoe kunnen leden anders een weloverwogen keuze maken wie ze in het bestuur willen hebben? Als je denkt dat je bepaalde belangen onder de pet kunt houden, dan komt dat later ongetwijfeld uit, en dan heb je de poppen aan het dansen. Misschien zou je zoiets wel in de statuten kunnen opnemen, als stok achter de deur. Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] OpenStreetMap Gebruikersdag tijdens Software Freedom Day bij Gendo, Amsterdam?
Beste Talk'ers, Dit jaar organiseer ik weer een Software Freedom Day. Deze keer bij Gendo in Amsterdam. Graag wil ik, net als vorig jaar http://softwarefreedom.nl/2008/index.html , daar ook een ruimte beschikbaar maken voor een OpenStreetMap Gebruikersdag. Wordt dat op prijs gesteld? Zie hier voor meer info: http://softwarefreedomday.eu/2009/index.html -- Met vriendelijke groet, Bas de Lange Software Freedom Day Gendo, Amsterdam http://softwarefreedomday.eu/2009/index.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] OpenStreetMap Gebruikersdag tijdens Software Freedom Day bij Gendo, Amsterdam?
Doe maar Bas, Er zijn vast wel een paar luitjes die Wat willen vertellen. Anders gaan we gewoon mappen. Stefan: Heb jij nog een leuk onderwerp ??? Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Bas Verzonden: maandag 24 augustus 2009 19:32 Aan: OpenStreetMap NL discussion list Onderwerp: [OSM-talk-nl] OpenStreetMap Gebruikersdag tijdens Software Freedom Day bij Gendo, Amsterdam? Beste Talk'ers, Dit jaar organiseer ik weer een Software Freedom Day. Deze keer bij Gendo in Amsterdam. Graag wil ik, net als vorig jaar http://softwarefreedom.nl/2008/index.html , daar ook een ruimte beschikbaar maken voor een OpenStreetMap Gebruikersdag. Wordt dat op prijs gesteld? Zie hier voor meer info: http://softwarefreedomday.eu/2009/index.html -- Met vriendelijke groet, Bas de Lange Software Freedom Day Gendo, Amsterdam http://softwarefreedomday.eu/2009/index.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Newbie intro
John Smith wrote: --- On Sun, 23/8/09, Liz ed...@billiau.net wrote: They still don't agree with us, they still think it's just another smoothness option, except for those from Iceland maybe. Don't get me started on the absolute uselessness of the smoothness tag... Matt ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
2009/8/23 David Clarke gadic...@pnambic.org That's cutting in to our big attractions. So what're we left with, the big potato, merino, trout and oyster? Big gallah in SA somewhere too (around Kimba? I don't remember...) Big lobster *somewhere*. I know I've seen it, but buggered if I know where. Does the Golden Guitar or whatever in Tamworth count? I'm sure there are a heap of others too. I don't think we're running out of big things just yet. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
Big lobster is in Kingston, SE South Australia. 2009/8/25 Jason Stirk jst...@oobleyboo.com 2009/8/23 David Clarke gadic...@pnambic.org That's cutting in to our big attractions. So what're we left with, the big potato, merino, trout and oyster? Big gallah in SA somewhere too (around Kimba? I don't remember...) Big lobster *somewhere*. I know I've seen it, but buggered if I know where. Does the Golden Guitar or whatever in Tamworth count? I'm sure there are a heap of others too. I don't think we're running out of big things just yet. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
On 23/08/2009 11:55pm, John Smith delta_foxt...@yahoo.com wrote: That's cutting in to our big attractions. So what're we left with, the big potato, merino, trout and oyster? A good reference for these big attractions is http://www.bigthings.com.au/. I dont' think we would run out anytime soon. I saw the kerfuffle about Balina's Big Prawn on the 7 PM Project and that it would be moved to a new service station. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] [OSM-talk] Local Chapters Call Today
--- On Tue, 25/8/09, Nick Black nickbla...@gmail.com wrote: The good news, especially for the patient and keen Locals like Ivan, is that the OSM-F board agreed last Saturday that we could go ahead and start to form local chapters based on a provisional agreement. The board felt - and I hope this is reflected by the community - that having one master agreement for all local chapters would not work and that the role of the Local Chapters group should be to negotiate an agreement with each local chapter that takes into account local specifics (like how hard it is to set up a non-profit in the USA or why Dutch groups can't have members and so on). Is the Australian wikipedia chapter's association rules suitable, with appropriate changes, to satisfy OSM-F? http://wikimediafoundation.org/wiki/Resolution:Approval_of_Wikimedia_Australia http://www.wikimedia.org.au/wiki/Statement_of_Purpose http://www.wikimedia.org.au/wiki/Rules ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn?
My Dad knew the guy who made the big lobster. Although that has no relevance to this discussion, I'd just like to claim my non existent fame. regards Paul :) From: talk-au-boun...@openstreetmap.org [mailto:talk-au-boun...@openstreetmap.org] On Behalf Of Cameron Sent: Tuesday, 25 August 2009 11:27 To: Jason Stirk Cc: talk-au@openstreetmap.org Subject: Re: [talk-au] Fwd: [OSM-talk] How to tag giant acorn? Big lobster is in Kingston, SE South Australia. 2009/8/25 Jason Stirk jst...@oobleyboo.commailto:jst...@oobleyboo.com 2009/8/23 David Clarke gadic...@pnambic.orgmailto:gadic...@pnambic.org That's cutting in to our big attractions. So what're we left with, the big potato, merino, trout and oyster? Big gallah in SA somewhere too (around Kimba? I don't remember...) Big lobster *somewhere*. I know I've seen it, but buggered if I know where. Does the Golden Guitar or whatever in Tamworth count? I'm sure there are a heap of others too. I don't think we're running out of big things just yet. ___ Talk-au mailing list Talk-au@openstreetmap.orgmailto:Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au Notice: The information contained in this email message and any attached files may be confidential information, and may also be the subject of legal professional privilege. If you are not the intended recipient any use, disclosure or copying of this email is unauthorised. If you received this email in error, please notify the DEEWR Service Desk by calling (02) 6240 and delete all copies of this transmission together with any attachments. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Vorschlag: Wiki-Artikel für Fahrradkno tenpunkt
Am Montag 24 August 2009 07:39:33 schrieb Adiac: Vorschlag: http://wiki.openstreetmap.org/wiki/DE:Cycle_routes/bicyclejunction Ich bin gerade auf DE:Bicycle gestoßen und ändere meinen Vorschlag in: http://wiki.openstreetmap.org/wiki/DE:Bicycle/bicyclejunction ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Am Sonntag 23 August 2009 20:22:53 schrieb Tobias Wendorff: amenity=cafe cuisine=ice_cream name=Eiscafé ... Ok, danke ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Noch ein kurioses Schild...
Hallo, am 23.08.2009 21:03 schrieb Torsten Leistikow: Moin, etwas eigene Schilderkombinationen findet man beim Mappen ja ab und an. Letztens ist mir folgendes begegnet: in den vergangenen Tagen sind hier viele schöne Kuriositäten durchgerauscht. Schade, dass das nicht im Wiki zusammengefasst ist - man könnte sich auch noch mal dran erfreuen. Gruß nk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Am Sonntag, 23. August 2009 20:08:56 schrieb Tobias Wendorff: Johann H. Addicks schrieb: Was tun wir denn, wenn sowohl das Straßenschild, wie auch die behördliche Liste eine Abkürzung vorsieht? Ausgeschrieben taggen? Nach dem Treffen mit AEROWEST ist meine Meinung zu den behördlichen Daten ein Stück nach unten gerutscht (Smile @ Frederik). Möglichkeiten: 1. auf die ALK schauen (da ist meist alles ausgeschrieben) 2. Amtsblätter durchschauen 3. auf alte Karten schauen (Stadtarchiv) 4. Anwohner fragen Ich würde es in der Regel ausschreiben. Kommt vielleicht auch darauf an, welcher Teil abgekürzt ist bei z.B. Bahnhofstr. gibt es wohl keine zwei Meinungen wie die Straße heißen soll, bei v. Muster Straße aber schon (van oder von?). Im Zweifel nochmal bei der Koumne nachfragen ob Ihre Straße offiziell abgekürzt geschrieben wird. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Hi Adiac, On Sun, Aug 23, 2009 at 08:03:07PM +0200, Adiac wrote: Ich habe im Wiki kein Eiskaffe gefunden. Gibt’s sowas? amenity = ice_cream ist ein proposed feature, dass ich gerne verwenden. Denn es geht da ja primär darum, dass dort Eis verkauft wird, und nicht dass dort Kaffee verkauft wird ... Gruß, Alex signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straß ennamen
Bernd Wurst schrieb: old_name Wird vom aktuellen Namefinder auch gefunden: name:former findet der nicht? Dann muss ich was umtaggen... -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Sven Anders wrote: Kommt vielleicht auch darauf an, welcher Teil abgekürzt ist bei z.B. Bahnhofstr. gibt es wohl keine zwei Meinungen wie die Straße heißen soll, 1) Bahnhofstr. 2) Bahnhofsstr. 3) Am Bahnhof 4) Bahnhof 5) Zum Bahnhof ... Schönen Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Johann H. Addicks schrieb: old_name Wird vom aktuellen Namefinder auch gefunden: name:former findet der nicht? Dann muss ich was umtaggen... Würde mich wundern, wenn er es fände. Ist doch nirgends dokumentiert. Und da old_name seit März 2006 (!) im Wiki beschrieben ist und tausende Verwendungen hat, dürfte die Allgemeinheit hier kaum Änderungsbedarf sehen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wasserschutzgebiet
Am 22. August 2009 17:49 schrieb Norbert Kück o...@nk-bre.net: am 22.08.2009 16:16 schrieb André Riedel: Ich denke das ganze passt in den Gefahrguttransportbereich, ich würde daher hazmat:water=* vorschlagen. In der Beschreibung ist es ausdrücklich erlaubt, verschiedene Abstuffungen einzubauen und ich denk das wäre eine. Die Beschilderung ist nicht zwangsläufig deckungsgleich mit den Wasserschutzgebieten ausgeführt. (Ich kenne einige WSG ohne Schilder und auch Beschilderungen, die nicht mit den Schutzzonen erklärbar sind.) Daher wäre eine Beschränkung auf die Schilder zu kurz gehüpft. Ich möchte mit hazmat:water=no/permissive nicht das Wasserschutzgebiet darstellen, sondern die für den LKW-Verkehr wichtigen zusammenhänge, dass man dort eben mit wassergefährdenden Stoffen nicht langfahren darf oder nur sehr vorsichtig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schreibweisen/Abkürzungen von Straße nnamen
Am Montag, 24. August 2009 08:47:58 schrieb Martin Trautmann: Sven Anders wrote: Kommt vielleicht auch darauf an, welcher Teil abgekürzt ist bei z.B. Bahnhofstr. gibt es wohl keine zwei Meinungen wie die Straße heißen soll, 1) Bahnhofstr. 2) Bahnhofsstr. 3) Am Bahnhof 4) Bahnhof 5) Zum Bahnhof Und ich finde es nicht gut, wenn meine Beiträge aus dem Zusammenhang gerissen werden, wenn ich in einer Offiziellen Liste Bahnhofstr. finde setze ich in OSM name=Bahnhofstraße Ich bekomme ja nun häufiger offizielle Listen von Komunen und in manchen sind einfach alle Straßen mit Str abgekürzt. Ich korrigiere das dann für den Vergleich. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] collection_times - mit perl brauchbar zerlegen
Hi ! hat einer von euch schon einmal das tag *collection_times mit perl so zerlegt das man daraus eine tabelle aufbauen könnte ?? Gruß Jan :-) * ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Vorschlag: Wiki-Artikel für Fahrradkno tenpunkt
Am Montag 24 August 2009 07:39:33 schrieb Adiac: Grund: Ich würde im Anschluss daran zwei JOSM-Vorlagen hinzufügen für den Wegweiser und der Karte. Das habe ich testweise schon gemacht. Vier neue Gruppen stehen in den JOSM-Einstellungen zur Verfügung. Sicherlich nicht perfekt, aber ein Anfang. * bicyclejunction_icn.xml * bicyclejunction_lcn.xml * bicyclejunction_ncn.xml * bicyclejunction_rcn.xml Wenn man alle 4 hinzufügt hat man leider 4 mal Fahrradknotenpunkt untereinander im Menü. Zuerst hatte ich die 4 nicht einzeln, sondern in einer Datei. Mit dem Erfolg, dass das Trac-System die Datei als Spam eingestuft hat (zu viele Links). Bitte um Kritik/Feedback MfG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Eiskaffee?
Am Mo, 24.08.2009, 08:41 schrieb Alexander Klink: amenity = ice_cream ist ein proposed feature, dass ich gerne verwenden. Denn es geht da ja primär darum, dass dort Eis verkauft wird, und nicht dass dort Kaffee verkauft wird ... Kaffee ist das Getränk, Café das Geschäft. Darum geben wir ja auch woanders an, was es dort für Dinge zu kaufen gibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
