Re: [Talk-transit] [Spam] Re: Multiple tracks
Choosing not to render a point because there's something else more important close by is relatively easy. Aggregating adjacent lines is much (much) harder. Identifying the number of lines that are adjacent is much (much) easier for the tagger than for the renderer. But I seem to be repeating myself; you either believe me or you don't. Richard On Tue, Jun 23, 2009 at 7:52 AM, Frankie Roberto fran...@frankieroberto.com wrote: On Mon, Jun 22, 2009 at 5:21 PM, Peter Miller peter.mil...@itoworld.comwrote: Can I suggest that as a start you create the detailed track layout and then we can look at different grouping strategies and see which ones the Mapnik people and routing people will find useful. Whatever you do should work for rail and trams and I see no reason for there not to be generality with roads. Lets not worry too much about the wrapping until we have stuff to wrap. I think this is a good approach. Using a tracks=1ofX tag could end up a complete waste of time if renderers can use the relations to dynamically pick whether to draw one track or more anyway. Mapnik seems to decide how many POIs to render based partly on how many it can fit on the map, so this doesn't seem infeasible. I'd like to see some discussion about strategies for tagging individual tracks though. I've attempted to do it in a few places, but mainly only at stations (where I've also drawn the platforms). Has anyone attempted to draw the switches where two lines meet? How about adding oneway=yes? Level crossings? 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 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Spam] Re: Multiple tracks
On Wed, Jun 24, 2009 at 1:31 PM, Richard Mann richard.mann.westoxf...@googlemail.com wrote: Choosing not to render a point because there's something else more important close by is relatively easy. Aggregating adjacent lines is much (much) harder. Identifying the number of lines that are adjacent is much (much) easier for the tagger than for the renderer. But I seem to be repeating myself; you either believe me or you don't. I do believe you, and I haven't actually tried to implement such an algorithm myself. It's just my instinct that we should be tagging the data and letting the renderers worry about rendering algorithms later. However, I agree that there's a balance to be struck. Do relations solve the problem at all? If a track is part of a route relation, then could a renderer use that as a means of aggregating the tracks together? Are there any Mapnik people we can involve in this discussion? 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
[Talk-transit] NaPTAN and the new PT tagging schema
Hi all, It's about time to push on the import to the rest of the UK, however, we must first consider what we do with the new Public Transport tagging schema. It would make a lot of sense to use this now that a detailed proposal has been put together. The only real differences it would make for us are: * additionally tagging all highway=bus_stop nodes with public_transport=platform, bus=yes * moving NaPTAN's StopAreas from the unified stoparea proposal (relation type=site, site=stop_area) to relation type=public_transport, public_transport=stop_area * NaPTAN allows for cascading StopAreas, I'm of the view that to simplify the import we follow the NaPTAN precedent and import them with the same structure, rather than using a stop_area_group relation. As far as the import is going, I'm still yet to patch the missing fields onto the Birmingham data, which is probably going to be my next task. -- Regards, Thomas Wood (Edgemaster) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Spam] Re: Multiple tracks
On Wed, Jun 24, 2009 at 2:45 PM, Richard Mann richard.mann.westoxf...@googlemail.com wrote: Do relations solve the problem at all? If a track is part of a route relation, then could a renderer use that as a means of aggregating the tracks together? My hunch is that relations probably don't actually help much, unless you could rely on them being done consistently and accurately. Hmm... One idea another OSMer suggested a while back (when the idea of tagging tracks still sounded ridiculous) is to have some way of distinguishing between a 'track' and a railway line (or 'corridor' is perhaps a better word), so that renderers can choose which to display (and so that the data contains both conceptually different things). Not sure how best to implement this. The easiest thing would be to have the middle track double up as the way which represents the line, somehow. The hardest thing might be to have ways which mark both edges of the rail corridor (like how we do riverbanks). 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
[OSM-legal-talk] Privacy and Terms
Dear all One of the things that's resulted from getting help with the license process is that it's been noticed we don't have a lot of the legal furniture, and thus protection and clarity, found frequently elsewhere. We've been offered some fairly standard privacy and terms of use policies: http://wiki.openstreetmap.org/wiki/Privacy_Policy_-_Discussion_Draft http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft We've put them up for your input as step 1. These aren't even recommended by us just yet, but to start a discussion on anything that may be bad (or maybe good - that would be novel!) with them? Best Steve ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
On 24/06/09 06:56, SteveC wrote: http://wiki.openstreetmap.org/wiki/Privacy_Policy_-_Discussion_Draft The Mozilla project has a privacy policy which I would suggest is rather friendlier, while still being lawyer-approved - at least, US lawyers. I'm sure I could arrange for you to be able to use the appropriate bits of it: http://www.mozilla-europe.org/en/about/privacy/ http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft These seem very long indeed. What risks are we mitigating here? If they are significant, why does every website in the world not have to have one of these? Gerv ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
Hi, Gervase Markham wrote: http://wiki.openstreetmap.org/wiki/Terms_of_Use_-_Discussion_Draft These seem very long indeed. What risks are we mitigating here? If they are significant, why does every website in the world not have to have one of these? Yes, I'm also very tempted to dismiss the idea of having these at all. It sounds quite laughable. I could imagine we would have to have these if we were an US corporation but hey, we're in Europe as long as not too many people vote UKIP once Gordon Brown throws the towel. I guess the rationale behind terms like these is that if user A sues you because user B used the web site to hack A's computer, you can always say but B acted against our terms and conditions. But I don't think that user A's case would hold any water before an European court. Except as otherwise permitted, any use by you of any of the OSMF Materials and OSMF Site other than for your personal use is strictly prohibited. Are we talking about osmfoundation.org or openstreetmap.org? Because if it is the latter, which parts of the web site are NOT under either GPL or CC-BY-SA, making any restriction (personal use only) illegal? I could probably find something idiotic in every paragraph if I put my mind to it but I'd rather do something else. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
On Jun 24, 2009, at 4:31 PM, Frederik Ramm wrote: I could probably find something idiotic in every paragraph if I put my mind to it but I'd rather do something else. Some of the stuff is there simply by virtue of having any terms of use at all, e.g. Assignment, Survival, or Claims. Some of the stuff is there because of stupid-ass legislation which violates various laws (e.g. if the site is going to be used by underaged children (which of course it will) we would have to treat them differently (at least according to US law) except of course we have no freaking idea how old they are, so we just tell everyone to lie and pretend that they're of-age which of course breaks the law that you shouldn't induce peaceful honest people to lie.) Some of the stuff is there to help enforce the database license. If we had a license that didn't give us the occasion to sue anybody, we wouldn't need terms like that, but in fact we DO plan to sue SOMEBODY, sooner or later. And it's only reasonable to then be able to say in court Haumph, you used our website on these various occasions; continued use implies that you did IN FACT agree to abide by our distribution license. You can argue whether the terms are effective, but you can't argue against their existence in principle. Some of the stuff is there to make sure that we have the right to redistribute contributions to OSM. This is important and useful. Removal of content is a good term to have in place. I get mailing list subscribers asking me to remove their email address from the archives. I ignore them, thinking Too late! Think before you email! But if someone comes at me with a legal threat, and I have no contributor's agrement to point them to, I'm pretty-much going to have no choice but to remove their address. Prohibited uses just gives us the right to kick fucking assholes in the butt. Sure, self-defense is the right of all civilized people, but remember this: a judge can ALWAYS get up on the wrong side of the bed and rule incorrectly. If you have verbiage in your TC that lets you point out, in appeal, excuse me, but we *did* tell them exactly what would happen if they did that, and we did it, so they have no reason to prevail in a judgement. And if you think that you're safe just because you live in Europe, consider that the OSMF provides services in the USA. It can say to the judge we don't operate in the US; this person has no opportunity to sue us, but who knows what might happen in the future? Maybe one of the principals of the OSMF might fly through the US, or move to the US, or start a US company. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
2009/6/25 Frederik Ramm frede...@remote.org: Yeah, sure, and if I leave the house a brick might fall on my head and I'd be dead. I'm almost sure you wanted to write tile ;-) cheers, Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
2009/6/25 Frederik Ramm frede...@remote.org: For example, if we build strong national chapters that, legally, are separate from OSMF, these could easily between themselves set up all the servers required to replace everything OSMF operates. With such a healthy backup network, it would not even make much sense for anybody to try and kill off OSMF. This includes not giving anything to OSMF that has commercial value unless that is absolutely necessary. In the long term, I hope that we'll be able to switch to a distributed server architecture where OSMF operated assets are but one piece of the puzzle, rather than the head of everything. Hallo Frederik, kennst Du couchdb? http://en.wikipedia.org/wiki/CouchDB Ich habe leider selbst keine Ahnung von Datenbanken, aber die bietet wohl eine gute Möglichkeit, auf vielen verschiedenen Servern gleichzeitíg zu laufen. Keine Ahnung wie performant das ist, wo die Probleme liegen,etc. aber beim sie scheint ähnlich wie das OSM-Modell strukturiert zu sein (Key/Value-Paare). Vielleicht ist das Thema ja in Entwicklerkreisen sowieso schon längst bekannt, aber bei Deinem aktuellen Beitrag kam mir wieder der Gedanke und ich dachte, ich schreib Dir mal. Gruß Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Privacy and Terms
2009/6/25 Martin Koppenhoefer dieterdre...@gmail.com: Hallo Frederik oops, sorry, not for the list. Martin ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-talk] how are runways related to an airport/aerodrome
I'm curious about your uses for this. In what kind of situation would somebody know a runway code but not what airport? if you download OSM data (using the API) within a bounding box, you will get nodes, ways, and relations within that bounding box. One of the ways can be a runway. The airport node can be outside that bounding box. Now in order to know the airport name, the bounding box needs to padded up and the download API needs to be rerun. This is exactly what am doing right now. It's not bad either, because the second API call runs on my local OSM source which contains only the airports. I agree with your other notes. This is a very generic problem. Not sure how others have solved this issue with other entities you mentioned. Thanks Madhav -Original Message- From: Alan Millar [mailto:a...@bolis.com] Sent: Tuesday, June 23, 2009 10:21 PM To: Madhav Vodnala Cc: talk@openstreetmap.org Subject: RE: [OSM-talk] how are runways related to an airport/aerodrome All that runway 'way' XML contains is one tag that says it's a runway. The problem is there is no easy way to correlate a runway to its airport. This is a generalized problem that reaches far beyond just runways. For any given way (of any kind), how do you associate it or characterize it as belonging to a larger area? An airport is a larger area, even if it has only be marked as a node in OSM; that is just a shortcut placeholder for the area. You certainly could use a relation. That seems like a lot of work to me. I would suggest looking at the ways other people have done it for other entities in OSM. How do you know a bike trail belongs to a park? How do you know a street belongs to a town? How do you know a foot path belongs to a university campus? The simple answer for all of them is the geometry. Short of that, the is_in tag is the most common one in use for this sort of thing. But really, matching geometry will be the simplest. You will pretty much always find the aerodrome area or node within 0.0020 degrees lat/lon of the runway, and most often within 0.0012 degrees, based on my experience in looking at them in OSM. It's not a visual problem, it's a math problem, and it's already been solved by others. Sort by distance, it becomes quite obvious which airport the runway belongs to. You can google for the calculations; you don't need to understand them to paste them into your script. (I don't understand the math, but it still works great for me.) For eg. Entering 30L in a search window should bring up SJC as the result. Note there can be multiple runways named 30L. Multiple? You bet. You're going to have a dozen or more. There are only 18 number sets to work with, plus L or R and sometimes C. If the runway is correctly named, it will be 12R/30L. 12R will always be the same runway as 30L. If you search for 30, you're likely to get a hundred matches or more. I've drawn or verified runways on about 3000 airports so far, and I think there are about 5000 or more airports listed in the English wikipedia. That's going to be a long search list. I'm curious about your uses for this. In what kind of situation would somebody know a runway code but not what airport? Perhaps there is other information or other ways to solve the problem that could help. Good luck on the project! - Alan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] osm traces and tags
I'm still missing some things under http://www.openstreetmap.org/traces/ * a simple search field for tags * being able to change/add tags of own trails after upload * tags are case-sensitive (searching Turkey and turkey is not the same!) Does it 'need' to be case-sensitive? Roman ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] The map key isn't static anymore
On Tuesday 23 Jun 2009 23:45:31 Tom Hughes wrote: The map key is now a HTML table instead of a static PNG image as can be seen on the dev server (click Map key): http://api06.dev.openstreetmap.org/ (Should be on the main site soon) It's definitely an improvement but I think it raises three usability issues: 1 - There are so many similar shades of colours that I doubt the average visitor would be able to deduce what map features (for example) each of these green areas matches up to: http://api06.dev.openstreetmap.org/?lat=51.43899lon=-0.07248zoom=15 2 - Features you want in an urban area are sometimes completely missing (i.e. POIs) or mixed in with less important features (e.g. schools, retail areas) 3 - The key isn't entirely up to date with mapnik, so for example an area that's amenity=hospital currently renders the same as a school, whereas the key says that coloured area is (only) a school or university I'm not sure exactly what you do about these issues, but they need the Mapnik stylesheet team and the people who put the key together to have a bit more of a think. Either just show a prioritised list (before, at z18, it gets insanely long) or have collapsible categories, or use the trick of allowing people to click on the map and it tell them what that is. Regards, Tom ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [OSM-dev] Error in OSM site when Exporting to Embedded HTML
This is now fixed in http://trac.openstreetmap.org/changeset/16086 2009/6/23 Jonas Krückel o...@jonas-krueckel.de: Ævar Arnfjörð Bjarmason schrieb: On Mon, Jun 22, 2009 at 8:59 AM, Ivan Garciacapisc...@gmail.com wrote: Hi, I realized that when I click in the EXPORT tab of OSM.org and I choose the Embedded HTML radiobox, it appears a link that says: Click here to select a marker, but when I click later on in the map, no marker is placed, I'm using Firefox 3 in my Kubuntu. Can someone who can debug JS look at this? Firefox error console/Firebug complain about undefined variables but I can't track down what's wrong. I recognized this bug a few weeks ago as I was translating osm.org. It seemed to me that the bug appeared that time, so maybe it has something to do with the translation? I checked de.yml at this time, but there was no bug, so it must be somewhere else. Maybe this is a hint. Jonas ___ dev mailing list d...@openstreetmap.org http://lists.openstreetmap.org/listinfo/dev -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Announcement] talk-vi Vietnam mailing list
There is now a talk-vi Vietnam-specific mapping parties, topics and discussion mailing list available. Thank you to Ivan Garcia for initiating and hosting this forum. The Philippines now has a great map of Manila and recently had a very successful mapping party on nearby Tagaytay so it is great activity picking up in sister ASEAN countries. Good luck to everyone mapping in Vietnam and I hope you get a good turn out for the mapping party in Hanoi Saturday 18 July 2009. Mike For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists Hanoi Mapping party next month http://wiki.openstreetmap.org/wiki/HanoiMappingParty2009 For details about OSM activity in Vietnam: http://wiki.openstreetmap.org/wiki/WikiProject_Vietnam About Vietnam: http://en.wikipedia.org/wiki/Vietnam Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm traces and tags
I'm still missing some things under http://www.openstreetmap.org/traces/ * a simple search field for tags * FIXED: being able to change/add tags of own trails after upload - I forgot the more link for tracks * tags are case-sensitive (searching Turkey and turkey is not the same!) Does it 'need' to be case-sensitive? Roman ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On Wed, Jun 24, 2009 at 1:19 AM, greg...@arenius.com wrote: What do people think? I know that there are a bazillion amenity tags already in use but I think that going forward a better organized system will be worth the effort of implementing it. I think the whole wiki page needs reorganization. I would suggest to move the full list of tags into subpages (one for landuse, one for amenity, etc) and keep on Map Features only the top 5 or 10 most popular tags of each category. Doing this, the wiki page is much smaller but still gives a good idea of each category. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On 24/06/2009 10:27, Pieren wrote: I think the whole wiki page needs reorganization. I would suggest to move the full list of tags into subpages (one for landuse, one for amenity, etc) and keep on Map Features only the top 5 or 10 most popular tags of each category. Doing this, the wiki page is much smaller but still gives a good idea of each category. Please don't do that! If you're not sure what category something comes under, it's really hard to find if it is on a page organised by category. If I want a windmill, say, I can search for windmill as things stand without having to know it is in man_made. Having everything on one page is so much easier as a reference. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On 24/06/2009 00:43, Frederik Ramm wrote: Hi, greg...@arenius.com wrote: What do people think? I think why bother. Clearly what we have is chaotic, but any system you can think of will become chaotic sooner or later with people (ab)using it to their heart's content, so what's the big deal. +1 If you're not sure what something comes under it's easy enough to look it up, and in most cases presets know about it anyway. Personally I think these categorizations have no value anyway, and if I were designing it from scratch, I'd have just a type for each item and properties which are the tags. But I'm not, and like the many proposals that surface on this list to rearrange everything, it may be a bit neater but it is too much of an upheaval for the minimal gain. It's not as if these are any more than internal identifiers. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
--- On Wed, 24/6/09, David Earl da...@frankieandshadow.com wrote: Please don't do that! If you're not sure what category something comes under, it's really hard to find if it is on a page organised by category. If I want a windmill, say, I can search for windmill as things stand without having to know it is in man_made. Having everything on one page is so much easier as a reference. As someone relatively new to OSM I couldn't agree more, it's hard enough trying to fit some squarish pegs into round holes when it comes to cultural/language differences, but being able to search everything on a single page can't be understated as to how useful this is. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
David Earl wrote: On 24/06/2009 00:43, Frederik Ramm wrote: Hi, greg...@arenius.com wrote: What do people think? I think why bother. Clearly what we have is chaotic, but any system you can think of will become chaotic sooner or later with people (ab)using it to their heart's content, so what's the big deal. +1 If you're not sure what something comes under it's easy enough to look it up, and in most cases presets know about it anyway. Personally I think these categorizations have no value anyway, and if I were designing it from scratch, I'd have just a type for each item and A reason to do better categorizations would be to ease conversion to mobile (or online) routeplanners, which already have some sort of categorization in amenities. If you don't do that in OSM than you need a conversion for that. Not saying that this is a compelling argument to do categories in OSM, but it does have a value. Personally I'm also more inclined to why bother. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
A better exercise, I think, would be to create an A4 sized cheatsheet of common POIs and how they should generally be tagged - something that people can print out and laminate to either use themselves or distribute at mapping parties that could be used as an aid for when one is out mapping and wants to tag-as-you-go. I'm not sure but I think someone else may have suggested this previously. k. On Wed, Jun 24, 2009 at 10:53 AM, Maarten Deen md...@xs4all.nl wrote: David Earl wrote: On 24/06/2009 00:43, Frederik Ramm wrote: Hi, greg...@arenius.com wrote: What do people think? I think why bother. Clearly what we have is chaotic, but any system you can think of will become chaotic sooner or later with people (ab)using it to their heart's content, so what's the big deal. +1 If you're not sure what something comes under it's easy enough to look it up, and in most cases presets know about it anyway. Personally I think these categorizations have no value anyway, and if I were designing it from scratch, I'd have just a type for each item and A reason to do better categorizations would be to ease conversion to mobile (or online) routeplanners, which already have some sort of categorization in amenities. If you don't do that in OSM than you need a conversion for that. Not saying that this is a compelling argument to do categories in OSM, but it does have a value. Personally I'm also more inclined to why bother. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- http://short.ie/savenenaghhospital/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Pieren wrote: On Wed, Jun 24, 2009 at 1:19 AM, greg...@arenius.com wrote: What do people think? I know that there are a bazillion amenity tags already in use but I think that going forward a better organized system will be worth the effort of implementing it. I think the whole wiki page needs reorganization. I would suggest to move the full list of tags into subpages (one for landuse, one for amenity, etc) and keep on "Map Features" only the top 5 or 10 most popular tags of each category. Doing this, the wiki page is much smaller but still gives a good idea of each category. Pieren Please don't break up the map features. It is vital for beginners to have one place to turn to to find all the common tags. Cheers Chris ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On Wed, Jun 24, 2009 at 10:13 AM, Ken Guestk...@linux.ie wrote: A better exercise, I think, would be to create an A4 sized cheatsheet of common POIs and how they should generally be tagged - something that people can print out and laminate to either use themselves or distribute at mapping parties that could be used as an aid for when one is out mapping and wants to tag-as-you-go. I'm not sure but I think someone else may have suggested this previously. I think it has, but we don't seem to have such a thing, so talk is cheap. Maybe you'd like to actually create such a sheet? It would be a great contribution. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Hi, I quite like the idea. For people, who think about using OSM data in their project, clarity of tag structure might be an important issue. I think why bother. Clearly what we have is chaotic, but any system you can think of will become chaotic sooner or later with people (ab)using it to their heart's content, so what's the big deal. The question is whether to choose chaos or less chaos. I think it's still a significant difference. Are there any serious reasons why not to bother? Technically I support the idea of key named spiritual, because there are more tags to fit in such group: wayside cross, small shrine, ... Regards, Radomir Cernoch 2009/6/24 greg...@arenius.com: The amenity key is currently used for so many different things that it has no meaning. It has become a catch all category for everything that doesn't have a place elsewhere. I'm proposing breaking it up into more keys to help make things more organized. Proposed keys: *Amenity *Death *Education *Entertainment *Financial *Government *Healthcare *Sustenance *Transportation *Waste With their tags: Amenity: *BBQ *Bench *Drinking_fountain *Emergency_Telephone *Fountain *Shelter *Telephone *Toilet Death: *Graveyard *Crematorium Maybe also things like tombs, catacombs, mortuaries, funeral homes, etc. Could probably also replace landuse=cemetary Education: *School *College *Library *University Entertainment: *Arts_centre *Brothel *Cinema *Nightclub *Theatre *Studio Financial: *ATM *Bank *Bureau_de_change Maybe also check cashing, brokerages, stock exchanges, commodity exchanges, etc Government: *Baby_hatch *Courthouse *Embassy *Fire_station *Police_station *Post_office *Post_box *Public_building *Prison *Townhall I think a lot of other types government buildings could be added here as well. Healthcare: *Dentist *Doctor *Hospital *Pharmacy *Veterinary This key has been proposed and passed a vote (15-4) but no further work has been done with it because the proposer doesn't have time. I'd move it along but I think it should be part of a larger reorganization of amenity. There are a lot of other tags that could be put in this category so I think its an especially important one. Sustenance: *Biergarten *Cafe *Fast_food *Food_court *Pub *Restaurant Transportation: *Bicycle_parking *Bicycle_rental *Bus_station *Car_rental *Car_sharing *Ferry_terminal *Fuel *Parking *Taxi_stands I think there has been discussion about a key somewhat like this but nothing has been officially proposed. Waste: *Recycling *Waste_basket *Waste_disposal Maybe also things like dumps, recycling baskets, etc. That leaves us with a few stray tags which I think can be better placed elsewhere. Hunting_stand can go in leisure. Marketplace can go in landuse. Signpost can go in the proposed information key. Vending_machine can go in the shop key, or failing that, its own key. Which leaves place_of_worship. Maybe in a new spiritual key with things like holy_site, etc? It really doesn't fit well in amenity though. I've copied this proposal into the wiki at http://wiki.openstreetmap.org/wiki/Proposed_Amenity_Reoganization which I'll be working on improving. What do people think? I know that there are a bazillion amenity tags already in use but I think that going forward a better organized system will be worth the effort of implementing it. Cheers, Greg ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Radomir Cernoch +44 750 708 8293 / +420 607 282 031 Email, Jabber: radomir.cern...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On 24/06/2009 11:39, Radomír Černoch wrote: The question is whether to choose chaos or less chaos. I think it's still a significant difference. Are there any serious reasons why not to bother? Yes, because it means changing all the editors, all the renderers and other consumers and relearning what everything is called. When we could be out there productively mapping instead. David ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On Wed, Jun 24, 2009 at 11:32 AM, David Earlda...@frankieandshadow.com wrote: Please don't do that! If you're not sure what category something comes under, it's really hard to find if it is on a page organised by category. If I want a windmill, say, I can search for windmill as things stand without having to know it is in man_made. Having everything on one page is so much easier as a reference. David When the wiki pages are well structured (and named), you can use the search function, type windmill and you find the right page. I simply cannot imagine how far the Map Features page will be extended to list all possible amenities, sports, shops, man_made, etc. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Pieren Pieren wrote: I think the whole wiki page needs to be taken outside and shot. Arguing over the presentation on the wiki isn't really the issue. What the tags are, and how they're documented, are two separate things. But like Ævar says, talk is cheap, and though many of us feel strongly that MediaWiki is a rubbish solution (even discounting its performance issues) none of us have as yet actually produced any code. Any devs out there looking for a project? cheers Richard -- View this message in context: http://www.nabble.com/Proposed-Amenity-Reorganization-tp24176224p24182598.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
gregory at arenius.com writes: Death: *Graveyard *Crematorium I think there is some difference between a graveyard and a churchyard, so the latter should also be a tag. Education: *School *College *Library *University Also need nursery/preschool. -- Ed Avis e...@waniasset.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
--- On Wed, 24/6/09, Pieren pier...@gmail.com wrote: When the wiki pages are well structured (and named), you can use the search function, type windmill and you find the right page. I simply cannot imagine how far the Map Features page will be extended to list all possible amenities, sports, shops, man_made, etc. That example works for easy types, but take say fords, these are commonly (only) known for all my life as cause ways or dips, and what you are searching for, by looking down the list is something that looks close enough or identical but not known by the same name. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On Wed, Jun 24, 2009 at 12:54 PM, Richard Fairhurstrich...@systemed.net wrote: Arguing over the presentation on the wiki isn't really the issue. What the tags are, and how they're documented, are two separate things. But like Ævar says, talk is cheap, and though many of us feel strongly that MediaWiki is a rubbish solution (even discounting its performance issues) none of us have as yet actually produced any code. Any devs out there looking for a project? I'm not talking about the whole wiki, just the Map Features page. This page presents all tags at same level of importance, from the highway=residential instanciated million times to highway=bus_guideway or railway=monorail instanciated ergh.. (don't know.. 3 times ?). I don't understand people saying it is not possible with the search function. How do they use wikipedia ? they have a single page listing all articles listed in alphabetic order ? About synonyms, you can also improve the descriptions to include these terms or use the REDIRECT feature. I also don't like the position why bother, it's chaotic, let them continue. I'm sure we can improve this page a bit more than sort the amenities. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Pieren wrote: I'm not talking about the whole wiki, just the Map Features page. As was I. cheers Richard -- View this message in context: http://www.nabble.com/Proposed-Amenity-Reorganization-tp24176224p24183557.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Pieren schrieb: I would suggest to move the full list of tags into subpages (one for landuse, one for amenity, etc) and keep on Map Features only the top 5 or 10 most popular tags of each category. Doing this, the wiki page is much smaller but still gives a good idea of each category. Less extreme solution: Only move the images for examples and rendering (and element) to the subpages, shorten the text, so it should fit in to one line (at most browsers ;) ) highway=road: A road of unknown classification, temporary tagging. is enough for first search A road of unknown classification. This is intended as a temporary tag to mark a road until it has been properly surveyed. Once it has been surveyed, the classification should be updated to the appropriate value. should be on the subpage. If reorganisated: One should find a solution for easier overview about different language. At now an editor of any language only see his language while editing, because english master version is found at template 1 and the foreign language is defined at template 2 calling template 1, but without seeing its content. It may avoid differences between languages, if an editor of a language can compare his changes to the english version and others while editing. Might be a solution would be: an highway=road-template contains all languages The e.g. german highway-subpage collects - german part from highway=road - german part from highway=... And the (german) highway=road-subpage only collect its template at now descriptions on highway and highway=road may differ, because highway=road don't use global templates ... Heiko Mueck Jacobs ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
On Wed, 24 Jun 2009 11:53:27 +0200 (CEST), Maarten Deen md...@xs4all.nl wrote: A reason to do better categorizations would be to ease conversion to mobile (or online) routeplanners, which already have some sort of categorization in amenities. Please give examples here. Are you sure there is just ONE way to categorize and that not every second application(not just routeplanner) uses another way to categorize things? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
Pieren wrote: On Wed, Jun 24, 2009 at 12:54 PM, Richard Fairhurstrich...@systemed.net wrote: Arguing over the presentation on the wiki isn't really the issue. What the tags are, and how they're documented, are two separate things. But like Ævar says, talk is cheap, and though many of us feel strongly that MediaWiki is a rubbish solution (even discounting its performance issues) none of us have as yet actually produced any code. Any devs out there looking for a project? I'm not talking about the whole wiki, just the Map Features page. This page presents all tags at same level of importance, from the highway=residential instanciated million times to highway=bus_guideway or railway=monorail instanciated ergh.. (don't know.. 3 times ?). I don't understand people saying it is not possible with the search function. How do they use wikipedia ? they have a single page listing all articles listed in alphabetic order ? The nice part about the map_features page is that there is one overview and for a lot of tags there is even a nice picture to see what real-world example fits it. Moving away from that would mean lots of searching in pages with tags that may or may not fit your needs, and using the search with the wrong search key will give you nothing usefull, while browsing through a list will result in finding the correct key. Of course this could be fixed by i.e. making a category for each main key type (highway, waterway, natural, amenity, etc.) and using the category page for the overview of values associated with the key, but a standard wiki-generated category page only lists pages and does not have the information which is now in the table of the map features page. And what is importance here? Don't confuse abundance of use with importance. A bus lane is certainly not used as much as a primary road, but it is not less important. IMHO the map_features page functions as it should: a list of documented features. Regards, Marten About synonyms, you can also improve the descriptions to include these terms or use the REDIRECT feature. I also don't like the position why bother, it's chaotic, let them continue. I'm sure we can improve this page a bit more than sort the amenities. Pieren ___ 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] Proposed Amenity Reorganization
greg...@arenius.com schrieb: The amenity key is currently used for so many different things that it has no meaning. Indeed. But that's no problem, because the key amenity don't bear some information of an object. You can waive amenity and you may only say school=yes without loss of information. Sometimes the key also has some worth for information to distinguish between landuse=residential, highway=residential but for amenity the value bears information, not the key, so changing the keys isn't necessary. It has become a catch all category for everything that doesn't have a place elsewhere. Yes I'm proposing breaking it up into more keys to help make things more organized. Organization is only needed for Map Features and subpages, so it is good enough to sort them in Map-Features in *Amenity *Death *Education *Entertainment *Financial *Government *Healthcare *Sustenance *Transportation *Waste or something like this BEFORE sorting them alphabetically With their tags: Amenity: *BBQ *Bench ... ... and if one value can't be allocated to one group no allocation war is needed at mailing list ;-) only put it double in both parts ;-) Hunting_stand can go in leisure. Might be we are flexible enough to put some leisures to amenity-section of Map Features and vice versa if it makes sense, but changing the key isn't neccesary for my opinion Heiko Mueck Jacobs ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed Amenity Reorganization
I have commented on several points that have been raised. *Death To start with that is the wrong word to be using. I am not sure what you should use. Imagine saying to the wife 'Just need to go to the funeral to bury dad so I will search OSM, category Death then search for the funeral homes' How about rather than re-naming amenity names into Categories maybe we need a new tag called AmenityCategory=Entertainment etc. This would allow for things that transcend multiple categories to be be tagged with both categories. On Organising the page. I think leave it as one page. It is fairly easy to use and it does not improve things by splitting it up. You will just end up with loads of pages which take up more bandwidth and more space in the wiki. Cheat Sheet. I asked for what people want on a cheat sheet and no one replied to me. I am willing to make one up but as I have never been to a mapping party I don't know what you want on there. Jack Stringer ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Tag] Ref in link
Hi all, On this page : http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link it is implicitly written that the ref of a link should be the reference of the road from which the link depends. For example, a motorway_link to/from the motorway A 1 will be referenced as A 1. Generally, this schema doesn't work. Indeed, links depends of TWO roads, and regularly with two roads of the same type. Examples in France : link between the A 11 and the A 10 near Paris, or a lot of links between secondary roads. What do you think about referencing the links with the exit reference ? I do not know how it works in other countries, but in France, every exit usually has a reference. Some will say there is already a tag : highway=motorway_junction. Should we add highway=trunk_junction, highway=primary_junction, highway=secondary_junction, etc. ? I think the tag (highway=motorway_junction) is a patch for the map to be drawn correctly. Xav PS. For Mapnik and every other renderers : what about reducing the size of the links compared to the main roads ? As in Google Maps. It's much more readable. PPS. And what about replacing every : highway=Y_link with : highway=Y junction=link ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [Announcement] talk-tn Tunisia mailing list
There is now a talk-tn Tunisia-specific topics and discussion mailing list available. Thank you to Chedli Ghedira for initiating and hosting this forum. Mike For details on how to subscribe to this and other country, language, and topic-specific OSM mailing lists, see http://wiki.openstreetmap.org/index.php/Mailing_lists For details about OSM activity in Tunisia: http://wiki.openstreetmap.org/wiki/WikiProject_Tunisia (in French) About Tunisia: http://en.wikipedia.org/wiki/Tunisia http://fr.wikipedia.org/wiki/Tunisie Mike ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Thousands of small changesets by Tim Proegler
Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
http://www.mchme.com/#openstreetmap looks like the software they've used. 1753 changesets in less than 20 minutes. Shaun On 24 Jun 2009, at 17:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ 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] Proposed Amenity Reorganization
A reason to do better categorizations would be to ease conversion to mobile (or online) routeplanners, which already have some sort of categorization in amenities. Please give examples here. Are you sure there is just ONE way to categorize and that not every second application(not just routeplanner) uses another way to categorize things? Other applications already have their own translation tables if they are taking OSM data. I was just looking at osm2navit recently for this very issue, because nodes marked as amenity=school were rendering, but areas were not. It will be the same with all the rest of the other software. I think cleaning up the categorization is a good idea, but this isn't a good justification for it. - Alan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
Can we ban it, the stuff its uploading is completely useless. (single nodes with only note tags and no other useful metadata) 2009/6/24 Shaun McDonald sh...@shaunmcdonald.me.uk: http://www.mchme.com/#openstreetmap looks like the software they've used. 1753 changesets in less than 20 minutes. Shaun On 24 Jun 2009, at 17:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tag] Ref in link
Xav wrote: Hi all, On this page : http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link it is implicitly written that the ref of a link should be the reference of the road from which the link depends. For example, a motorway_link to/from the motorway A 1 will be referenced as A 1. Generally, this schema doesn't work. Indeed, links depends of TWO roads, and regularly with two roads of the same type. Examples in France : link between the A 11 and the A 10 near Paris, or a lot of links between secondary roads. What do you think about referencing the links with the exit reference ? I do not know how it works in other countries, but in France, every exit usually has a reference. In Belgium those links all have their own road numbers. The A1 road for example would have a link with reference number A.001.123 (and service roads which aren't accessible have references like A.001.123.S001) -- and those road numbers are signed. So either using the reference from the main road it links to, or using the motorway exit number wouldn't work here. Ben ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
Thomas Wood grand.edgemas...@gmail.com schrieb: Can we ban it, the stuff its uploading is completely useless. (single nodes with only note tags and no other useful metadata) All the nodes I have looked at are for german petrol stations. The script does not seem to check if the station has already been mapped and only setting the note tag is really not much help in sorting this out later. I am also wondering were the data is coming from. 1753 petrol stations covering an area of 5x5 degrees are quite a lot, I think. Christoph 2009/6/24 Shaun McDonald sh...@shaunmcdonald.me.uk: http://www.mchme.com/#openstreetmap looks like the software they've used. 1753 changesets in less than 20 minutes. Shaun On 24 Jun 2009, at 17:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ 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] Thousands of small changesets by Tim Proegler
On 24 Jun 2009, at 18:30, Thomas Wood wrote: Can we ban it, the stuff its uploading is completely useless. (single nodes with only note tags and no other useful metadata) +1 The author of the program obviously has got the wrong idea as to what OSM is about. I have just tried out the program on the test server. It takes any KML, NMEA, GPX, etc file and uploads all the points in that file in a separate changeset as a node in the data, which is is basically useless. Shaun 2009/6/24 Shaun McDonald sh...@shaunmcdonald.me.uk: http://www.mchme.com/#openstreetmap looks like the software they've used. 1753 changesets in less than 20 minutes. Shaun On 24 Jun 2009, at 17:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Regards Steve ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ 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] Thousands of small changesets by Tim Proegler
Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? This looks like some automated mass import of fuel stations (of many different companies) in Germany, all tagged only with note=[name], without any check whether these stations already exist. I don't know the source of this but I suspect (until proof for the opposite fact is supplied) that this user mass-imports copyrighted material into osm. I don't know of any import of such data in Germany. KMLManager sounds like some kml file with a lot of fuel stations from some unknown source was imported. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
Can we ban it, the stuff its uploading is completely useless. (single nodes with only note tags and no other useful metadata) I like that idea maybe if created_by == KMLManager: print go away, you're being a pest ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
On 2009-06-24 18:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Though it might have the side effect off causing changes in the app that KMLManager uploads not that visible in future, I wrote a longish mail to the author of that program. I tried to detail why it's no good idea to upload converted waypoints with just a note tag, why it's bad to upload raw GPS traces as ways. Granted he's not really liable for what users do with that app, but he shouldn't make it to easy to produce crap. And he's at least responsible for how misbehaved KMLManager is on uploading. This for the records so you know he has been contacted and he won't get a dozend mails. I'll let you know of any answer. Regards, Rolf ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Thousands of small changesets by Tim Proegler
I also sent him a mail and have just received a response saying that he'll remove the feature until the problem is resolved. Shaun On 24 Jun 2009, at 19:59, Rolf Bode-Meyer wrote: On 2009-06-24 18:58, S Knox wrote: Does anyone know why Tim Proegler http://www.openstreetmap.org/user/timproegler/edits has made so many small edits under the name of KMLManager in such a short space of time (1 day as a member)? The recent changes page was at one point full of his changesets. Is this legitimate, or a mistake? Though it might have the side effect off causing changes in the app that KMLManager uploads not that visible in future, I wrote a longish mail to the author of that program. I tried to detail why it's no good idea to upload converted waypoints with just a note tag, why it's bad to upload raw GPS traces as ways. Granted he's not really liable for what users do with that app, but he shouldn't make it to easy to produce crap. And he's at least responsible for how misbehaved KMLManager is on uploading. This for the records so you know he has been contacted and he won't get a dozend mails. I'll let you know of any answer. Regards, Rolf ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] JOSM slippy map max_zoom_level workaround
Sorry if this has been talked about to death and I didn't notice, but I
did search a bit and didn't find the answer. I'm also pretty sure I'm
up-to-date on all the code.
I have been curious for a long time why JOSM's slippymap plugin seems to
decrease the max_zoom_level by 4 every time I run it, and only now
decided to chase it down.
The offending code seems to be in SlippyMapPreferences.java:
public static int getMinZoomLvl()
{
String minZoomLvl = Main.pref.get(PREFERENCE_MIN_ZOOM_LVL);
if (minZoomLvl == null || .equals(minZoomLvl))
{
minZoomLvl = + (SlippyMapPreferences.getMaxZoomLvl() - 4);
Main.pref.put(PREFERENCE_MAX_ZOOM_LVL, minZoomLvl);
}
Perhaps that should be a PREFERENCE_MIN_ZOOM_LVL in the pref.put()?
In any case, a quick workaround is to add min_zoom_level to your
.josm/preferences file, e.g:
slippymap.max_zoom_lvl=17
slippymap.min_zoom_lvl=2
Again, I apologize if this is a rerun or out of date.
-Beej
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM 08: Talks Panel debates
SteveC schrieb: So does anyone know if the rest will be put up? BTW: I don't find any list of the Talks Panel debates of the SOTM08. For the SOTM07 the list is in the wiki, but not for 08. IIRC it was present on http://www.stateofthemap.org/ but is not available any more due to the '09 information... Does anybody have a list? Could it be added also the wiki? Thanks in advance. Best regards, Michael. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] SOTM 08: Talks Panel debates
On 25 Jun 2009, at 01:00, Michael Kugelmann wrote: SteveC schrieb: So does anyone know if the rest will be put up? BTW: I don't find any list of the Talks Panel debates of the SOTM08. For the SOTM07 the list is in the wiki, but not for 08. IIRC it was present on http://www.stateofthemap.org/ but is not available any more due to the '09 information... Does anybody have a list? Could it be added also the wiki? Thanks in advance. Try http://2008.stateofthemap.org/ and for the year before http://2007.stateofthemap.org/ Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New media for trailing mapper/driver
Hi, There is an interesting report of new trends in Japanese media. I wanna share it. Sorry only japanese... http://www.itmedia.co.jp/news/articles/0906/23/news039.html It said that many driver, who have camera on board with their car, shared their driving sight video on Niko-Niko Doga, similar service with YouTube, or Ustream live video. It is a links for such a videos. http://www.matome.info/draview/ It is quite interesting and inspired me to think how we can link these videos and our map? They have already started to share their live location on GoogleMap. http://imakoko-gps.appspot.com/static/view.html If we can share videos and their location on our map with its Route, it may make many viewers/drivers enjoyable. IMHO, it can become an improved StreetView! At least I can say, with this movement, a number of GPS logger holder is increasing rapidly in Japan. It is chance for us, japan mappers, to promote OSM! Hiroshi -- Global IT Innovator __~~~ NTT DATA Group Hiroshi Miura Manager, Division of HR strategy of IT architects and specialists, Planning Section, System Platform Sector, NTT DATA Corp. （株）NTTデータ 基盤システム事業本部企画部IT人材戦略担当 三浦広志 〒135-6033 東京都江東区豊洲３−３−９ 豊洲センタービルアネックス 電話：050-5546-2154 FAX：03-5546-8342 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [Tag] Ref in link
What is your suggested ref for links that are an entrance, not an exit? And can you give an example of what you mean by an exit ref? Where I come from, some exits have numbers, but the number is associated with the highway ref, so you'd still need that as well. 2009/6/25 Xav x...@nainwak.com: Hi all, On this page : http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmotorway_link it is implicitly written that the ref of a link should be the reference of the road from which the link depends. For example, a motorway_link to/from the motorway A 1 will be referenced as A 1. Generally, this schema doesn't work. Indeed, links depends of TWO roads, and regularly with two roads of the same type. Examples in France : link between the A 11 and the A 10 near Paris, or a lot of links between secondary roads. What do you think about referencing the links with the exit reference ? I do not know how it works in other countries, but in France, every exit usually has a reference. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] Herinnering: vanavond eerste Amsterdamse MappersBabbel
Dag iedereen in en rond Amsterdam, Even een herinnering: Vanavond is de er een Amsterdamse Mappersbabbel / Stammtisch in de Ponteneur, meer info op de wiki: http://wiki.openstreetmap.org/wiki/Amsterdam#Eerste_Amsterdamse_MappersBabbel Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] Het Nationale georegister is geopend
fyi http://www.computable.nl/artikel/ict_topics/overheid/2978452/1277202/het-nationale-georegister-is-geopend.html ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Herinnering: vanavond eerste Amsterdamse MappersBabbel
In middels afgelopen (rond 10 uur was het grootste deel weer vertrokken). Maar ik denk dat we de eerst MappersBabbel tot een succes kunnen verklaren. De sfeer was erg goed en er werd druk gebabbeld over verscheidene, maar toch vooral OSM gerelateerde, dingen. Er zullen de komende dagen ongetwijfeld verscheidene balletjes op gegooid worden voor ideeen die zijn besproken. Om even iets te noemen (toch alvast een beetje resultaat): * Er komt nog geen talk-ams. Er is simpel weg nog niet eens genoeg verkeer op talk-nl. Wel zullen berichten over Amsterdam getagd worden. In de zin van [Amsterdam] TOPIC om zo een beetje overzicht te houden voor de rest. Dit is eventueel voor andere gebieden ook aan te raden. Indien het te druk word kunnen we altijd nog talk-ams oprichten. De rest laat ik over aan de personen die er beter en langer over na gedacht hebben. Groet, --Roeland On Wednesday 24 June 2009 12:21:52 Floris Looijesteijn wrote: Dag iedereen in en rond Amsterdam, Even een herinnering: Vanavond is de er een Amsterdamse Mappersbabbel / Stammtisch in de Ponteneur, meer info op de wiki: http://wiki.openstreetmap.org/wiki/Amsterdam#Eerste_Amsterdamse_MappersBabb el Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl 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
[OSM-talk-nl] Vraag over xapi en/of JOSM
Hallo, ik had deze week een IRC gesprek met iemand in Hongarije, die problemen had met een navigatie-programma. Het blijkt dat dit programma bij nodes die een place aanduiden ook een is_in tag wil hebben met de naam van het land. Is het mogelijk om een query te bedenken die alle places van een land teruggeven? Het lijkt erop dat de landsgrenzen wel in OSM zitten, maar het formaat van zo'n query, en het nabewerken van de info in JOSM, is niet 1-2-3- duidelijk. Is er iemand die kan uitleggen hoe zo'n query in elkaar zou zitten? Groeten! Christ van Willegen -- 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0 ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] Running stats against GPX files ...
--- On Tue, 23/6/09, Graeme Wilson wandere...@live.com.au wrote: Another idea is to have our own proprietry file format called .osm I reckon that we could have several lines of text at the start to declare things like program version, who made the file, the start and end time of the actual recording for copyright purposes, the number of lines of data in the file, and then the lat and lon to 7 decimal points accuracy. I've been doing some checking into what's possible and it looks like you can compress 20 bytes per point files considerably. The files all contain 2,122 points. The GPX files my app produces.. 247112 test.gpx 12751 test.gpx.gz Straight conversion using gpsbabel which makes bigger gpx files. 299091 test2.gpx 13519 test2.gpx.gz 20 bytes per point files. 44240 test.raw 8305 test.raw.gz Also just as a thought experiment, I thought I'd do a comparison on JSON encoded files, and got the following results. 140877 test.json 9994 test.json.gz For those that don't know JSON files are similar to XML/GPX in that they are human readable, but they aren't any where near as bloated and they parse by apps much faster, some think up to 100x faster, than XML files. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] L?schen kann manchmal wichtig und richtig sein (war Routerh?rtetest )
N'abend, Hier w?rde ich auch gerne l?schen, aber will ja auch nicht anderer Leute Arbeit kaputt machen. Der einfachste Verlauf wird der Beste sein. Die Autoren sollten es ja bemerkt haben, es wird immer eine Route genommen je nach Gegebenheiten, so ist das in der Luftfahrt auch. Schiffahrtsrouten machen in wenigen Fällen wie z.B. Fähren ja noch Sinn, aber da hört es schon bald auch auf. Das angegebene Beispiel zeigt das mit sowas mehr Verwirrung denn Nutzen gestiftet wird. Habe die beiden K?nstler mal angemailt. http://www.informationfreeway.org/?lat=53.65628393lon=7.08234101zoom=13 F?hrlinie Norddeich-Juist in diversen Variationen: Bei Hochwasser, Niedrigwasser, bei Springflut sowie die Route wenn der Kapit?n betrunken ist. Ein typischer Fall, jeder möchte sich verewigen. Es geht häufig gar nicht um den Nutzen an sich. Der sollte aber immer entscheidend sein. Chris Sven S. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Am Dienstag 23 Juni 2009 22:59:57 schrieb Christoph Eckert: ich möchte anmerken, dass mir die Brücke nicht gehört. Ich wende mich nicht dagegen, dass Heiko dort editiert und Änderungen vorgenommen hat. Ich Natürlich nicht. Ich verändere auch ab und zu Dinge, die Andere angelegt haben. Vor gravierenden Lösch- bzw. Umtagaktionen schreibe ich dem Anderen aber üblicherweise vorher oder parallel eine erklärende Mail, ggf. kann man dann darüber diskutieren. möchte vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon eine Menge Verbesserungen zusammengetragen hat. Die Rheinbrücke ist ein Spezialfall, da ist Streit vorprogrammiert. Auch das ist unbestritten. Der Streitfall am konkreten Beispiel entsteht IMHO auch, weil jeder macht was er will. Es keine zentrale Instanz gibt, die Regeln festlegt. Das ist für den lokalen Mapper, der seine Gegend bearbeitet, äußerst angenehm. Er kann mit tags zur Verfügbarkeit von Kuchen am lokalen Bäcker um sich werfen und keinen stört es. Langsam hat OSM aber Maße erreicht wo uns dieses Prinzip beginnt im Weg zu stehen. Heiko möchte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren Daten verbessern. Das ist mehr als wünschenswert. ACK. nicht davor zurückschreckt, auch an kniffeligen Stellen die Finger in die Daten zu stecken, ebenfalls. Denn eine Huch, nein, ich könnte ja was kaputt machen-Mentalität führte sicher nicht dazu, dass das Projekt weiterkommt. NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper den ich in der History sehe angemailt. Warum hast Du das und das so und so erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu? Vor diesem Hintergrund stellt sich die Frage, was wir primär abbilden wollen: Die Topologie (Hier ist ein extra Radweg) oder die STVO (Hier ist ein straßenbegleitender Radweg). Da ich das Projekt viel mehr als Natürlich die Topologie. Schon mal vor dem Hintergrund das OSM weltweit funktionieren soll und die STVO nur lokal gilt. Das ein Renderer oder Router dann lokale Gegebenheiten, die er an den Ländergrenzen erkennt, berücksichtigen wird ergibt sich später von alleine. eine Relation zwischen dem Radweg und der Straße abgebildet werden sollte, Das sehe ich anders. Topologisch hat der Radweg mit der Straße nichts gemeinsam, die Gemeinsamkeit ist ein Konstrukt der STVO. Besser wäre die Editoren würden Linienbündel an Kreuzungen oder beim Verschieben usw. besser unterstützen, damit man die vielen Kreuzungspunkte nicht händisch pflegen muß. Ich bin daher auch kein Freund davon, einen Weg zu zerhaken, nur um eine Geschwingigkeitsbeschränkung (oder auch eine einfache Brücke) zu modellieren. Warum nicht? Man kann die zerhackstückten Teile, wenn man logische Informationen die zu mehreren Teilen des Weges gehören (name, ref), in eine Relation stecken. Mapnik Osmarender, openrouteservice.org, gosmore oder Navit heute mit unseren Daten zurechtkommen oder nicht, ist zweitrangig. Das lernen die schon noch. Und zwar umso schneller, je einheitlicher das Radwegemapping umgesetzt wird. ACK. Tschaui, Jörg signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Gemeindegrenzen
Ich will das Thema mal etwas grundsätzlich angehen. Es gibt in DE 12.112 Gemeinden und ebenso viele Gemeindegrenzen. Nun kann man natürlich jede Gemeinde einzeln anschreiben und sie bitten, uns doch die Gemeindegrenze zur Verfügung zu stellen. Dabei ist in jedem Einzelfall zu klären, wer das entscheidet, welche Entscheidungsgrundlage gilt, wie man das technisch macht, in welchem Format die Daten geliefert werden, wie wir diese importieren, aufbereiten, zu Relationen umformen und verknüpfen. Also 12.112 mal viele Stunden Arbeit für die Gemeindemitarbeiter und für uns (für jede Stunde pro Gemeinde = 7 Mannjahre) [1] Gibt es nicht eine Möglichkeit, diese Daten für ganz DE zu bekommen? Auf Bundesebene? von infasGEOdaten (von denen wir ja auch die Landkreisgrenzen haben)? von den Landesvermessungsämtern? Aus sonst irgend einer zentralen politischen oder kommerziellen Quelle? Gruss, Markus [1] Der Workflow ist aktuell höchst aufwändig: a) Anruf bei der Gemeinde, positive Antwort, DXF exportiert, Tobias wandelt in OSM. Aber nun sind es 6000 einzelne Vektoren und doppelt Punkte. b) Anruf bei der Gemeinde, positive Antwort, aber der Mitarbeiter weiss nicht wie man Daten exportiert. Er übt einen Tag erfolglos. c) Anruf bei der Gemeinde, man muss erst mal politisch diskutieren. Ergebnis: wir sollen uns an das Vermessungsamt wenden. Wenn man diesen Weg weiter beschreiten wollte, bräuchte man eine nachvollziehbare Anleitung für OSMer und Gemeindemitarbeiter, mit einem effizienten Workflow. In Englisch hat Lennard (NL) eine solche Anleitung erstellt - aber das ist immer noch viiel zu komplex und aufwändig. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen
On Wednesday 24 June 2009 10:23:52 Markus wrote: Gibt es nicht eine Möglichkeit, diese Daten für ganz DE zu bekommen? Auf Bundesebene? von infasGEOdaten (von denen wir ja auch die Landkreisgrenzen haben)? von den Landesvermessungsämtern? Aus sonst irgend einer zentralen politischen oder kommerziellen Quelle? In Sachsen-Anhalt hat beispielsweise das Landesvermessungsamt die Daten und stellt die Koordinaten der Gemeinden als XML-File zum Download (wenn auch als Ergaenzung fuer ihr Programm CD-ROM Top50 Sachsen-Anhalt). Wie es mit der rechtlichen Situation zum Import der Koordinaten aussieht, habe ich noch nicht weiter untersucht. Schoene Gruesse, Thomas. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerh?rtetest - Topologie oder STVO?
Am Mittwoch, 24. Juni 2009 08:58:35 schrieb talk-de-requ...@openstreetmap.org: Moin, Genau so sehe ich das auch. Auch ich verfolge den Thread aufmerksam weil mich das Radrouting derzeit am Meisten besch?ftigt. Und das Heiko, ohne den Mapper der den Radweg angelegt hat zu kontaktieren, einfach dessen Arbeit l?scht finde ich auch nicht ok. ich m?chte anmerken, dass mir die Br?cke nicht geh?rt. Ich wende mich nicht dagegen, dass Heiko dort editiert und ?nderungen vorgenommen hat. Ich m?chte vorsichtshalber auch darauf hinweisen, dass Heiko in Karlsruhe schon eine Menge Verbesserungen zusammengetragen hat. Die Rheinbr?cke ist ein Spezialfall, da ist Streit vorprogrammiert. Aber ich sehe es so wie Sven, Martin und Du: Speziell an der Rheinbr?cke bin ich der Meinung, dass es bei getrennten Wegen bleiben sollte. Und das sollte Heiko respektieren. Wenn die Diskussion hier nicht dazu f?hrt, dass in Potlatch fleissig die Taste ?u? gedr?ckt wird, war sie, ?h, vergebens :) . Unabh?ngig von obigem Streitfalle m?chte ich gern ein paar Dinge loswerden. Openstreetmap ist IMO prim?r eine gewaltige Geodatenbank. Heiko m?chte, soweit ich ihn verstehe, gerne die Radwegesituation in unseren Daten verbessern. Das ist mehr als w?nschenswert. Dass er dabei nicht davor zur?ckschreckt, auch an kniffeligen Stellen die Finger in die Daten zu stecken, ebenfalls. Denn eine Huch, nein, ich k?nnte ja was kaputt machen-Mentalit?t f?hrte sicher nicht dazu, dass das Projekt weiterkommt. Vor diesem Hintergrund stellt sich die Frage, was wir prim?r abbilden wollen: Die Topologie (Hier ist ein extra Radweg) oder die STVO (Hier ist ein stra?enbegleitender Radweg). Da ich das Projekt viel mehr als Geodatenbank und weniger als nur ein (Sta?en)kartenprojekt auffasse, komme ich zu dem Schlu?, dass prim?r die Topologie und sekund?r die STVO abgebildet werden sollte. Wahrscheinlich wollen OSM viele gerade als Straßenkartenprojekt sehen. Vermutlich war das gerade zu Beginn von OSM so und daraus resultiert dann auch der Name: Openstreetmap. Und die Motivation in das Projekt einzusteigen ist vielfach die Karte zu ergänzen, weil sie auf der gerenderten Karte fehlt oder aber in der Navikarte, mit der man seine ersten Erfahrungen gemacht hat. Später erfährt man im Umgang und in der Praxis, das OSM für mehr gedacht ist als nur für die üblichen Karten und Navigationsaufgaben. Das ist vielleicht ein prinzipeilles Problem, das diese beiden Ansätze schwer bis unmöglich zu vereinen sind. Vielleicht sollte man sie trennen. Unsere Daten verfeinern sich immer mehr. Manche beschreiben das mit Zum?llen der Datenbank. Da muß man wohl ins Detail gehen. Ich habe diesen Ausdruck schon benutzt und will auch erklären was ich damit meine: Das Anlegen von Wege, beispielsweise. Es wird mit unseren Geräten und unseren Methoden nur eine relative Genauigkeit geben. GPS ist heute auf im besten Fall 3m genau, das wird auch durch Gallileo nicht so viel besser (außer man verwendet spezielle Antennen, DGPS und soweiter). Wenn ich auf diesen relativ ungenauen Spuren weiterarbeite und das tun wir, dann kann sich der Fehler schnell vergrößern. Wald Häuser und dergleichen führen auch bei SirfIII Empfängern zu Verfälschungen. Trotzdem meinen manche es würde Sinn machen alle 5m von Hand einen Knotenpunkt für einen Weg setzen zu müssen. Doppelte POI's sind ebenso etwas was man als zumüllen ansehen könnte. Ich sehe dem relativ gelassen entgegen. Im Falle eines stra?enbegleitenden Radweges hei?t das, dass jemand auch den Gr?nstreifen zwischen Fahrbahn und Radweg einzeichnen k?nnen soll. Eine gute Sache, trotz der Fragen (speziell bez?glich des Renderings) die das aufwirft. Es stellt sich am Ende nicht die Frage was ist mapbar, sondern wieviel und welche Information ist noch hilfreich. Vielfach hat unsere Karte weiße Flecken, aber an anderen Stellen ist sie schon so unübersichtlich, das man sich in ihr nicht mehr zurechtfindet. Da wird dann gerne das Argument gebracht, das ist Sache der Vorverarbeitung oder des Renderers. Aber wie umständlich sollen Regeln für Renderer werden, wer sieht da noch durch. Und selbst wenn, das Schema verändert sich laufend, wie man es dann auch rendert, es ist immer nicht so wie man es sich eigentlich wünscht. Genauso ist das mit Karten für Navigationsgeräte. Ich pers?nlich komme daher zu dem Schluss, dass in einer Geodatenbank die Topologie wichtiger ist als die STVO, die wie eine Glasglocke ?ber die Topologie gest?lpt ist. Relationen sind eine umst?ndlich zu handhabende Sache. Das ist das größte Problem mit ihnen, die Idee finde ich soweit sehr gut. Das gilt auch für OSM, sehr gute Idee aber wenig strukturiert und sehr umständlich anzuwenden, selbst für Leute die das schon Jahre machen. Dennoch tendiere ich aus obigen Gr?nden dazu, dass die STVO durch eine Relation zwischen dem Radweg und der Stra?e abgebildet werden sollte, so ?hnlich wie das ja auch bei Abbiegeverboten gehandhabt wird.
Re: [Talk-de] Routerh?rtetest - Topologie oder STVO?
Am 24. Juni 2009 10:54 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Wahrscheinlich wollen OSM viele gerade als Straßenkartenprojekt sehen. Vermutlich war das gerade zu Beginn von OSM so und daraus resultiert dann auch der Name: Openstreetmap. Und die Motivation in das Projekt einzusteigen ist vielfach die Karte zu ergänzen, weil sie auf der gerenderten Karte fehlt oder aber in der Navikarte, mit der man seine ersten Erfahrungen gemacht hat. Später erfährt man im Umgang und in der Praxis, das OSM für mehr gedacht ist als nur für die üblichen Karten und Navigationsaufgaben. Das ist vielleicht ein prinzipeilles Problem, das diese beiden Ansätze schwer bis unmöglich zu vereinen sind. sehe ich nicht so. Vielleicht sollte man sie trennen. -1 aus meiner Sicht, aber es steht ja jedem frei, einen Fork zu machen, die Daten stehen zur Verfügung. Das Anlegen von Wege, beispielsweise. Es wird mit unseren Geräten und unseren Methoden nur eine relative Genauigkeit geben. GPS ist heute auf im besten Fall 3m genau, das wird auch durch Gallileo nicht so viel besser (außer man verwendet spezielle Antennen, DGPS und soweiter). oder man importiert Daten oder erhebt sie auf andere Art und Weise. Es stellt sich am Ende nicht die Frage was ist mapbar, sondern wieviel und welche Information ist noch hilfreich. diese Frage kann sich jeder selbst stellen, und die Daten eintragen, die er für hilfreich hält. Fehler im Sinne von doppelten POIs, zusätzlichen Nodes in _geraden_ Straßen, etc. sollte man m.E. auch beseitigen, aber zusätzliche Informationen eben nicht, auch wenn man sie selbst nicht benötigt. Das ist der entscheidende Punkt der Motivation: Verwendbarkeit! Verwendbarkeit ist die beste Werbung und die beste Vorraussetzung dafür das unser Projekt weiterlebt. Ich glaube ehrlich gesagt kaum, dass ein solcher Vorschlag zur Modellierung von Radwegen zu Zusatztags an Trunks raten w?rde. Aber ich lasse mich da gerne vom Ergebnis eines Workshops ?berraschen. Es sei denn, Heiko w?re der einzige Teilnehmer ;-) . Speziell an Trunks vielleicht nicht sonst halte ich es für effizient und einfach durchzuführen und ausreichend genau in vielen Fällen. kannst Du ja auch so halten, aber auf die Gefahr hin, mich zu wiederholen: wenn andere das (mit gutem Grund) anders sehen, halte ich es nicht für akzeptabel, deren Daten zu löschen, weil man selbst der Ansicht ist, sie seien zu genau. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] L?schen kann manchmal wichtig und richtig sein (war Routerh?rtetest )
Am 24. Juni 2009 08:22 schrieb Sven Sommerkamp s_sommerk...@gmx.de: Ein typischer Fall, jeder möchte sich verewigen. ist m.E. eher die Ausnahme, habe sowas noch nie vorher gesehen. Es geht häufig gar nicht um den Nutzen an sich. Der sollte aber immer entscheidend sein. Den Nutzen kann man noch gar nicht abschätzen. Entscheidend ist: handelt es sich um eine Information, die bisher nicht oder schlechter in der db ist, dann verfeinere/ergänze ich die Daten an dieser Stelle. Als OSM angefangen hat, waren alle Straßen nicht nutzbar, da das umgebende Netz gefehlt hat, und es keine Routingprogramme dafür gab. Hätte man dehalb nicht an Routing denken sollen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
On 2009-06-23 20:05, Markus wrote: Damm und Einschnitt gibt es bereits Ich hab's grad gesucht, aber das Wiki kennt weder Damm noch Einschnitt? Kannst Du das bitte dort verlinken? http://wiki.openstreetmap.org/wiki/DE:Key:embankment http://wiki.openstreetmap.org/wiki/Key:cutting Beide Dateien sind nicht verlinkt. Die Begriffe Damm und Einschnitt kommen darin nicht vor. Bei http://wiki.openstreetmap.org/wiki/DE:Key:embankment stimmt auch das languages-Menü nicht. So können die Texte nicht gefunden werden. Wie kommst Du darauf? Sowohl embankment als auch cutting sind mit deutschsprachiger Beschreibung schon länger in den Mapfeatures gelistet und verlinken auf die jeweiligen keys (zwar die englischsprachigen Seiten, aber die deutschsprachige Seite is dort immerhin verlinkt). Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Am 23.06.2009 22:16, Ulf Lamping: Bernd Wurst schrieb: Mein Vorschlag (der gar nicht von mir kommt sondern den ich nur wiederholt habe) klärt die Situation ohne Seiteneffekte (außer ich find das doof). Ein oneway=no ist eine (aus meiner Sicht seltsame) Sonderlocke mehr, die ohne Not das ohnehin schon nicht einfache Tagging weiter verkompliziert. Ich halte das für einen negativen Seiteneffekt. Ich unterstütze Michael und Ulf in ihrer Kritik an der eher jungen Einbahn-Implikation von Autobahnauf-/abfahrten. Diese Ausnahme von der OSM-Regel bringt wenig Mehrwert (geht es den Befürwortern um die Datenbank-Ersparnis?) und schafft eher Unschärfe. Ich habe bisher jedenfalls das in meinen Augen redundante, weil im Standard enthaltene oneway=no immer entfernt und als Relikt von JOSMs Funktion Weg-Umkehren - Tags umdrehen angesehen. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Am 23.06.2009 23:19, Schorschi: Da man auf auf und abfahren nicht drehen darf (Meist steht direkt an der Kreuzung das Autobahnschild) empfiehlt es sich die beiden wege getrennt zu erfassen. Dann erledigt sich das auch mit dem oneway=no hm, das gilt aber immer bei Straßen mit durchgezogenem Mittelstreifen, oder? Sollen deshalb jetzt solche Straßen alle mit getrennten Wegen erfasst werden? Das halte ich für wenig sinnvoll. Auch hier halte ich das Abweichen von dem Standard als Lösung eines in meinen Augen nicht vorhandenen Problems für die falsche Lösung. Das Argument, dass verhindert werden soll, dass Router einen auf Autobahnauffahrten routen sollte man eher durch eine vollständige Erfassung etwa mit Nutzung von Abbiegerelation lösen. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Wed, 24 Jun 2009 12:07:07 +0200, Claudius claudiu...@gmx.de wrote: Auch hier halte ich das Abweichen von dem Standard als Lösung eines in meinen Augen nicht vorhandenen Problems für die falsche Lösung. Welcher Standard? Das Argument, dass verhindert werden soll, dass Router einen auf Autobahnauffahrten routen sollte man eher durch eine vollständige Erfassung etwa mit Nutzung von Abbiegerelation lösen. Das hat nichts miteinander zu tun. Auf der Autobahn-Auffahrt darfst du nicht rückwärts fahren. Wie willst du das mit einer Abbiege-Relation an einer Kreuzung abbilden? Zumal nur wenige Router Abbiege-Relationen beachten können (kein einziger die vollständige Spezifikation) aber praktisch alle Einbahnstrassen auswerten können. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
Hallo Rolf, Ich hab's grad gesucht, aber das Wiki kennt weder Damm noch Einschnitt? So können die Texte nicht gefunden werden. Wie kommst Du darauf? Wie gesagt: ich suchte nach damm und einschnitt. Ergebnislos bleibt auch die Suche nach: - Graben - Furche - Senke - Böschung - Schwelle - Absatz Mit Wall findet man (wohl wegen en:wall = de:Mauer): Stadtmauer und ähnliches. Sowohl embankment als auch cutting sind mit deutschsprachiger Beschreibung schon länger in den Mapfeatures gelistet und verlinken auf die jeweiligen keys (zwar die englischsprachigen Seiten, aber die deutschsprachige Seite is dort immerhin verlinkt). Hm, mit den gängigen Begriffen finde ich den Eintrag nicht. Und obwohl dort die Begriffe Damm, Deich, Wall, Graben, Staumauer vorkommen, werden sie von der Suche nicht gefunden. Ich finde, solange Höhen in OSM nicht erfasst werden, sollten wir wenigstens solche Geländesprünge erfassen und darstellen können. Zusammengehörige Dinge sollten immer gegenseitig verlinkt sein. Dazu gehören hier ausser Böschung, Graben, Hügel und Senke, beispielsweise auch Staumauer, Stützmauer, Deich, Damm, Wellenbrecher, Klippe, Felsband, Grat, etc. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Hallo Claudius. Am Mittwoch, den 24.06.2009, 12:05 +0200 schrieb Claudius: Ich habe bisher jedenfalls das in meinen Augen redundante, weil im Standard enthaltene oneway=no immer entfernt und als Relikt von JOSMs Funktion Weg-Umkehren - Tags umdrehen angesehen. Ist nachdenken wirklich so anstrengend? JOSM dreht zwar Tags, aber er macht sicherlich aus nichts ein oneway=no. Gruß, Bernd -- Press any key to continue or any other key to quit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
marcus.wolsc...@googlemail.com schrieb: Auch hier halte ich das Abweichen von dem Standard als Lösung eines in meinen Augen nicht vorhandenen Problems für die falsche Lösung. Welcher Standard? daß nichts implizit vorhanden ist. Wie geschrieben mußten früher jegliche Eigenschaften immer (!) explizit angegeben werden mußten. Dies finde ich auch heute noch die beste Methode: was ich beim Taggen nicht angebe, gibt es nicht als Eigenschaft. Weil sonst hat man 17 Ausnahmeregeln und man weiß irgendwann nicht mehr muß ich das jetzt angeben oder nicht oder man beachtet versehentlich eine implizite Eigenschaft nicht was z.B. zu Routing Fehlern führt. Wie geschrieben stellt diese Umstellung m.E. die OSM-Welt unnötigerweise auf den Kopf... :-( MfG Michael. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
On Mon, Jun 22, 2009 at 05:38:56PM +0200, Martin Koppenhoefer wrote: was haltet Ihr von waterway=dam ? Wird bisher nirgends gerendert. Ich könnte mir auch vorstellen, das in den OSM-Inspector-Wasser-Layer einzubauen. waterway=dam wurde schon immer im OSM-Inspector angezeigt. Ist im Layer Waterways-Other. Man muss allerdings ziemlich nah ranzoomen. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Am 24.06.2009 12:25, marcus.wolsc...@googlemail.com: On Wed, 24 Jun 2009 12:07:07 +0200, Claudiusclaudiu...@gmx.de wrote: Auch hier halte ich das Abweichen von dem Standard als Lösung eines in meinen Augen nicht vorhandenen Problems für die falsche Lösung. Welcher Standard? Das Argument, dass verhindert werden soll, dass Router einen auf Autobahnauffahrten routen sollte man eher durch eine vollständige Erfassung etwa mit Nutzung von Abbiegerelation lösen. Das hat nichts miteinander zu tun. Auf der Autobahn-Auffahrt darfst du nicht rückwärts fahren. Wie willst du das mit einer Abbiege-Relation an einer Kreuzung abbilden? Das Rückwärtsfahren wird doch durch die Einbahnstraßenrelation eingeschränkt bereits. Und dann braucht es nur noch ein Abbiegeverbot von der Abfahrt auf die Auffahrt und fertig. Zumal nur wenige Router Abbiege-Relationen beachten können (kein einziger die vollständige Spezifikation) aber praktisch alle Einbahnstrassen auswerten können. Du sagst also, dass wir die für die Router einfachere Taggingvariante verwenden sollen? Ist die Unterstützung für Abbiegerelationen denn so schwer? Mal abgesehen davon: Was würde es denn dem Router bringen, wenn ich den gemeinsamen Abschnitt der Autobahnauf-/abfahrt mit oneway=no taggen würde. Er könnte doch immer noch von der Abfahrt auf die Auffahrt routen. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Am 24.06.2009 12:39, Bernd Wurst: Hallo Claudius. Am Mittwoch, den 24.06.2009, 12:05 +0200 schrieb Claudius: Ich habe bisher jedenfalls das in meinen Augen redundante, weil im Standard enthaltene oneway=no immer entfernt und als Relikt von JOSMs Funktion Weg-Umkehren - Tags umdrehen angesehen. Ist nachdenken wirklich so anstrengend? JOSM dreht zwar Tags, aber er macht sicherlich aus nichts ein oneway=no. Stimmt. Den Eingangskommentar finde ich trotzdem unangebracht. Claudius ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
On 2009-06-24 12:35, Markus wrote: Sowohl embankment als auch cutting sind mit deutschsprachiger Beschreibung schon länger in den Mapfeatures gelistet und verlinken auf die jeweiligen keys (zwar die englischsprachigen Seiten, aber die deutschsprachige Seite is dort immerhin verlinkt). Hm, mit den gängigen Begriffen finde ich den Eintrag nicht. Und obwohl dort die Begriffe Damm, Deich, Wall, Graben, Staumauer vorkommen, werden sie von der Suche nicht gefunden. Ach so, mit Suchen meinst Du die Suchfunktion im Wiki? Gut, dann kann das durchaus sein. Ich gehe immer so vor, dass ich mir zuerst die Mapfeatures aufrufe und dann mit der Browsersuchfunktion im Seitentext suchen lasse. Und da werde ich mit Damm durchaus fündig. Ich finde, solange Höhen in OSM nicht erfasst werden, sollten wir wenigstens solche Geländesprünge erfassen und darstellen können. Da hast Du meine volle Unterstützung. Bei Damm fällt mir immer der Main-Donau-Kanal ein. Um dessen Damm richtig einzuzeichnen ist embankment=yes allerdings unzureichend. Woran sollte ich das Tag heften? An das riverbank-polygon geht nicht, an den waterway=canal-way ebenfalls nicht. Die beiderseitigen Betriebswege müssen ja auch drauf, usw. Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
On 2009-06-23 16:52, Markus wrote: Datei in JOSM geladen zeigt 4 Polygone: Das konnte mir der nette Mitarbeiter vom Bauamt beantworten: Ein Gemeindegebiet, in dem ein gemeindefreier Staatsforst liegt, der von einer zur Gemeinde gehörigen Bundesstrasse durchtrennt wird, und im Staatforst liegen noch zwei Grundstücke der Gemeinde. Das gemeindefreie Gebiet sollte aber nicht nur aus einem Polygon bestehen wenn es von dem Gemeindegebiet auf dem die Straße läuft (ich denke Du meinst die St 2240) durchtrennt wird. Er konnte mir auch sagen, dass die Gemeindegrenze seehr genau ist. Nun bräuchte ich eine Anleitung wie ich 1. die einzelnen Linien zu einem Grenzpolygon zusammenfüge Ich fürchte Handarbeit. In JOSM zwei Punkte markieren und Knotenpunkte vereinigen. Zwar könnte man auch ein Tool schreiben, ob sich das für eine Datei lohnt ist die Frage. Und sicher ist die Automatik auch nur wenn zwei Punkte exakt die gleiche Koordinate haben. 2. wie das mit den Multipolygonen für so verschachtelte Grenzen funktioniert. Ich finde [[DE:Grenze_zeichnen]] erklärt das ganz gut. Das Hauptgebiet des gemeindefreien Gebiets Schönberg wie auch das kleine Gebiet am Autobahnkreuz sind vollständig im Gemeindegebiet enthalten und somit role=inner in der Relation der Gemeinde und role=outer in der Relation des gemeindefreien Gebietes. Die Enklave der Gemeinde unten an der Ecke St 2240 und LAU 19 ist role=outer in ersterer Relation und role=inner in letzterer. Ich weiß aber nicht, was das daneben an der Grenze zu Röthenbach sein soll. Nochmal ein Teil des gemeindefreien Gebietes das einen Teil Gemeinde einschließt? 3. wie ich der bestehenden Landkreisgrenze sage, dass sie falsch ist und dass zumindest an den Abschnitten wo sie sich fast mit der Gemeindegrenze deckt besser die Punkte der Gemeindegrenze, aber die Attribute von der alten Landkreisgrenze nehmen soll. Handarbeit. An zwei Punkten auftrennen und das Stück Gemeindegrenze einfügen. Diesen neuen Teil der Grenze nicht als Gemeinde-, sondern Kreisgrenze mit admin_level=6 taggen. Das Sourcetag sollte überall an der Gemeindegrenze, den neuen Gemeindepolygonen und dem neuen Stück Kreisgrenze Deine Quelle enthalten, nicht die des Kreisgrenzen-Imports. Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gemeindegrenzen
Am Mi, 24.06.2009, 10:23 schrieb Markus: Also 12.112 mal viele Stunden Arbeit für die Gemeindemitarbeiter und für uns (für jede Stunde pro Gemeinde = 7 Mannjahre) [1] OSM muss ja nicht morgen fertig sein... Gibt es nicht eine Möglichkeit, diese Daten für ganz DE zu bekommen? Klar, das BKG verkauft die Daten hochgenau, allerdings nicht kompatibel zu unserer Lizenz - und sie dürfen es nicht, auch wenn sie es wollten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] was ist ein footway?
Hallo Ich weiß zwar nicht, ob der allgemeine highway=footway-Wildwuchs darauf zurückzuführen ist. Aber ich hätte auf jeden Fall gerne eine Vereinheitlichung dessen was das Wiki zu diesem Tag sagt. Momentaner Stand: [[DE:Map_Features]] sagt zu highway=footway: Allgemeiner Fußweg, hauptsächlich für Fußgänger. (Ein offizieller Fußweg mit Beschilderung wird von highway=path, foot=designated genauer beschrieben). [[DE:Tag:highway=footway]] aber: Für ausgewiesene (designated) Fußwege. In Deutschland sind diese Wege meist ausgeschildert, insbesondere solche die ansonsten nicht eindeutig als ausgewiesener Fußweg erkannt werden können (also praktisch alle die nicht direkt neben der Straße als typischer Gehweg verlaufen). Ersteres bedeutet doch highway=footway ist gleich highway=path, foot=yes (wobei foot=yes an sich auch überflüssig ist). Letzteres jedoch es ist gleich highway=path, foot=designated. Wenn schon was im Wiki steht, sollten doch wohl auch alle Angaben stimmig sein. Auf Grund der sehr häufigen Verwendung für nicht beschilderte Wege wäre ich für die Interpretation wie in den Mapfeatures. Was ich auch nicht finden konnte ist, wie es (zumindest in Deutschland) rechtlich aussieht wenn Fahrradfahrer Wege benutzen die nicht extra beschildert und auch kein Gehweg (also kein Teil der Verkehrsfläche einer Straße) sind. Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist ein footway?
Rolf Bode-Meyer schrieb: Hallo Ich weiß zwar nicht, ob der allgemeine highway=footway-Wildwuchs darauf zurückzuführen ist. Aber ich hätte auf jeden Fall gerne eine Vereinheitlichung dessen was das Wiki zu diesem Tag sagt. Momentaner Stand: [[DE:Map_Features]] sagt zu highway=footway: Allgemeiner Fußweg, hauptsächlich für Fußgänger. (Ein offizieller Fußweg mit Beschilderung wird von highway=path, foot=designated genauer beschrieben). [[DE:Tag:highway=footway]] aber: Für ausgewiesene (designated) Fußwege. In Deutschland sind diese Wege meist ausgeschildert, insbesondere solche die ansonsten nicht eindeutig als ausgewiesener Fußweg erkannt werden können (also praktisch alle die nicht direkt neben der Straße als typischer Gehweg verlaufen). Ersteres bedeutet doch highway=footway ist gleich highway=path, foot=yes (wobei foot=yes an sich auch überflüssig ist). Letzteres jedoch es ist gleich highway=path, foot=designated. Wenn schon was im Wiki steht, sollten doch wohl auch alle Angaben stimmig sein. Auf Grund der sehr häufigen Verwendung für nicht beschilderte Wege wäre ich für die Interpretation wie in den Mapfeatures. Was ich auch nicht finden konnte ist, wie es (zumindest in Deutschland) rechtlich aussieht wenn Fahrradfahrer Wege benutzen die nicht extra beschildert und auch kein Gehweg (also kein Teil der Verkehrsfläche einer Straße) sind. Rolf Ein allgemeiner (nicht speziell für Füßgänger ausgeschilderter) Weg ist (für Deutschland zumindest) eigentlich nur ein highway=path. Weil auf einem Path darf quasi alles drauf, was auch drauf kann (Fußvolk, Räder, Mofas, Pferde...), was anhängig von Zusatzattributen wie width=* surface=* etc... ist.. Ein ausgeschilderter Fußweg (path+ foot=designated) ist in Deutschland erst einmal _nur_ fürs Fußvolk es sei denn es wird durch Zusatzschilder freigegben (z.B. bicycle=yes). Fürs Fahrradrouting ist es also sehr relevant. Ein Radfahrer darf über einen path geleitet werden, über einen highway=footway aber nurmit Ausnahme. Generell aber nicht. (Für Fußgänger gilt das gleiche andersrum übrigens für cycleways auch) Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Wed, 24 Jun 2009 12:50:37 +0200, Claudius claudiu...@gmx.de wrote: Am 24.06.2009 12:25, marcus.wolsc...@googlemail.com: Du sagst also, dass wir die für die Router einfachere Taggingvariante verwenden sollen? Ist die Unterstützung für Abbiegerelationen denn so schwer? Ja ist es. Denn das sind Einschränkungen/Kosten-Funktionen an Knoten statt Kanten was die meisten Routing-Algorithmen incl. den beliebten Dijstra und A* nicht vorsehen. Mal abgesehen davon: Was würde es denn dem Router bringen, wenn ich den gemeinsamen Abschnitt der Autobahnauf-/abfahrt mit oneway=no taggen würde. Er könnte doch immer noch von der Abfahrt auf die Auffahrt routen. Mein Beispiel war von der Autobahn in die Auffahrt, zurück bis zur Abfahrt und dort wieder auf die Autobahn. Das ist ein ganz anderer Fall. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist ein footway?
On 2009-06-24 14:35, Mario Salvini wrote: Ein allgemeiner (nicht speziell für Füßgänger ausgeschilderter) Weg ist (für Deutschland zumindest) eigentlich nur ein highway=path. Weil auf einem Path darf quasi alles drauf, was auch drauf kann (Fußvolk, Räder, Mofas, Pferde...), was anhängig von Zusatzattributen wie width=* surface=* etc... ist.. Ein ausgeschilderter Fußweg (path+ foot=designated) ist in Deutschland erst einmal _nur_ fürs Fußvolk es sei denn es wird durch Zusatzschilder freigegben (z.B. bicycle=yes). Fürs Fahrradrouting ist es also sehr relevant. Ein Radfahrer darf über einen path geleitet werden, über einen highway=footway aber nurmit Ausnahme. Generell aber nicht. Genau deshalb bin ich draufgekommen. In der Praxis scheint sowohl gerne jeder Weg auf dem ein Fahrrad fahren kann als cycleway bezeichnet zu werden, aber noch häufiger jede Art geteerter Weg (zumindest in Ortschaften) als footway, auch wenn kein Schild dransteht. Router führen dann natürlich brav außenrum. Die Interpretation von footway als das was die Mapfeatures-Übersicht sagt wäre da besser weil es praktisch nicht so oft falsch wäre. Andererseits ist footway als path + foot=designated das einzig sinnvolle, da es kein Zwischending zum reinen path gibt was es sonst meinen könnte. Gut man könnte sich vielleicht path + access=no + foot=yes basteln, da dürfen dann zwar nur Fußgänger drauf, aber ausgeschildert ist es auch nicht. Aber was sollte das sein? Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Tue, Jun 23, 2009 at 11:19:35PM +0200, Schorschi wrote: Subject: Re: [Talk-de] Routing Fehler A3-B58 Da man auf auf und abfahren nicht drehen darf (Meist steht direkt an der Kreuzung das Autobahnschild) empfiehlt es sich die beiden wege getrennt zu erfassen. Dann erledigt sich das auch mit dem oneway=no hm, das gilt aber immer bei Straßen mit durchgezogenem Mittelstreifen, oder? Sollen deshalb jetzt solche Straßen alle mit getrennten Wegen erfasst werden? Das halte ich für wenig sinnvoll. Ich glaube nicht das du sobald du am Autobahnschild vorbeigefahren bist, wenden, oder rueckwaerts fahren darfst. Dafuer bedarf es auf der Auffahrt selber keiner durchgezogenen mittellinie oder? Das bedeuted das in den allermeisten faellen ab der Kreuzung zur Auffahrt (Denn dort steht allermeistens das Schild) die Fahrbahn getrennt fuer beide Richtungen gezeichnet werden muesste. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Das bedeuted das in den allermeisten faellen ab der Kreuzung zur Auffahrt (Denn dort steht allermeistens das Schild) die Fahrbahn getrennt fuer beide Richtungen gezeichnet werden muesste. Die Standard Trompete zeichne ich schon immer getrennt. Jeweils ein Link für rauf und runter mit Oneway. Und der Link beginnt und endet bei mir mit Beginn und Ende von Beschleunigungs- bzw. Verzögerungsstreifen. Empfinde ich so als bestmögliche Wiedergabe der Situation mit den derzeitig verfügbaren Mitteln. Manche zeichnen ja nur den getrennten Teil der Trompete seperat, der Rest wird dann in einem Link vereinigt, mit 2 Lanes und ohne Oneway. Die Links gehen dann sofort auf die Piste. Für mich nicht gerade hübsch. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Wednesday, 24 June 2009 14:44:23 +0200, marcus.wolsc...@googlemail.com marcus.wolsc...@googlemail.com writes: On Wed, 24 Jun 2009 12:50:37 +0200, Claudius claudiu...@gmx.de wrote: Am 24.06.2009 12:25, marcus.wolsc...@googlemail.com: Du sagst also, dass wir die fuer die Router einfachere Taggingvariante verwenden sollen? Ist die Unterstuetzung fuer Abbiegerelationen denn so schwer? Ja ist es. Denn das sind Einschraenkungen/Kosten-Funktionen an Knoten statt Kanten was die meisten Routing-Algorithmen incl. den beliebten Dijstra und A* nicht vorsehen. Ist es das wirklich? (Ich meine die _schwere_ Unterstuetzung ... wegen Knoten statt Kanten ...) Wenn man Durchfahrtsbeschraenkungen (wie Einbahnstrasse etc.; fuer eine Kante geltend) und Abbiegerelationen (wie Linksabbiegen verboten, nur geradeaus etc.; fuer eine Kantenfolge mit 2 und mehr Kanten geltend) als Kosten umsetzt, gebe ich dir recht. Diese Dinge sind aber _harte_ Ausschlusskriterien, d.h. im Dijkstra sorgen die Durchfahrtsbeschraenkungen und Abbiegerelationen schon beim Erweitern des Suchbaums, dass ich diese und jene Kante gar nicht erst als Folgekante in Betracht ziehe (a la Gewicht=unendlich). Damit bleibe ich doch weiterhin kanten-orientiert und verwende die Knoten nur dazu herauszufinden, welche Kante mit welche verbunden ist. Bei Abbiegerelationen hat ein Router halt das Problem, dass sich diese auf eine Kantenfolge beziehen, d.h. ich nicht einfach nur die Eigenschaften einer einzelne Kante anschauen kann, um die Kante auszuschliessen (bzw. zu bewerten). Und das Nachschlagen/Mitfuehren von erlaubten/verbotenen Kantenfolgen erhoeht den Aufwand schon deutlich (ist aber nicht schwer). Daher sollten Mapper eine Kante mit oneway=yes/1/-1 auf keinen Fall durch die aequivalente Darstellung mit einer Menge von Abbiegebeschraenkungen von anderen Kanten in diese Kante ersetzen. Mal abgesehen davon: Was wuerde es denn dem Router bringen, wenn ich den gemeinsamen Abschnitt der Autobahnauf-/abfahrt mit oneway=no taggen wuerde. Er koennte doch immer noch von der Abfahrt auf die Auffahrt routen. Mein Beispiel war von der Autobahn in die Auffahrt, zurueck bis zur Abfahrt und dort wieder auf die Autobahn. Das ist ein ganz anderer Fall. ... dann doch lieber ein paar zusaetzliche oneway=yes spendieren, bevor man solch ein Routing-Ergebnis erhaelt ;-) (Wobei man bei deinem beschriebenen Beispiel dieselbe Kante in derselben Richtung mehrfach befaehrt, was fast immer unsinnig ist und nur bei komplizierteren Abbiegebeschraenkungen vorkommen duerfte.) Gruss, -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist ein footway?
Hallo Rolf, Fürs Fahrradrouting ist es also sehr relevant. Genau deshalb bin ich draufgekommen. In der Praxis Man könnte doch einfach unterscheiden zwischen: - physikalisch-materiell (Unterbau, Deckschicht, Oberfläche, Breite) - Funktion (Hauptverbindung, Nebenverbindung, Anbindung, Anzahl Spuren) - erlaubt für (alles was auf den Schildern/in der StVO steht) Eine fixe Verknüpfung von Form und Funktion und Schildern kann m.E. nicht funktionieren. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
Hallo Rolf, Nun bräuchte ich eine Anleitung wie ich 1. die einzelnen Linien zu einem Grenzpolygon zusammenfüge Ich fürchte Handarbeit. Ausgeschlossen: die Grenze besteht aus 6000 doppelten Punkten. Und es gibt 12.112 Grenzen... Zwar könnte man auch ein Tool schreiben Ja das würde sich lohnen. 2. wie das mit den Multipolygonen für so verschachtelte Grenzen funktioniert. Ich finde [[DE:Grenze_zeichnen]] erklärt das ganz gut. Ist ja auch von mir... Aber als Workflow für 12.112 Gemeinden ist das m.E. unbrauchbar. Lennard hat aus der DFX (vermutlich in Handarbeit!) eine OSM gemacht und die 4 Polygone in ein Multipolygon gepackt. Verwirrend finde ich, dass er 2 outer hat: 1. Stadt Lauf: outer 2. kleiner Staatswald: inner 3. grosser Staatswald: inner 4. kleines Gemeindegebiet im grossen Staatswald: outer Und Du sagst ja, dass das kleine Gemeindegebiet im grossen Staatswald zusätzlich noch ein inner in einer zusätzlichen Multirelation grosser Staaatswald bekommen soll? Ob das irgendeiner der Renderer oder Router versteht? Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
Am 24. Juni 2009 11:35 schrieb Markus liste12a4...@gmx.de: Hallo Rolf, Wie gesagt: ich suchte nach damm und einschnitt. Ergebnislos bleibt auch die Suche nach: - Graben - Furche - Senke - Böschung - Schwelle - Absatz die Frage ist bei diesen ganzen Woertern, ob man sie ueberhaupt als Synonym gebrauchen kann, m.E. nein. Furche, Senke Schwelle und Absatz sind keine Woerter, die ich mit Damm oder Einschnitt in Verbindung bringen wuerde. Boeschung und Graben koennte in manchen Faellen dagegen zutreffen. Das spezifische an cutting und embankment ist ja die kuenstliche Herstellung, bei aehnlichen natuerlichen Formen verwendet man andere Woerter. Wenn ich Tunnel suche will ich ja auch nicht Durchgangshoehle finden, oder? Gruss Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist ein footway?
On Wed, Jun 24, 2009 at 02:08:20PM +0200, Rolf Bode-Meyer wrote: Subject: [Talk-de] was ist ein footway? Hallo Ich weiß zwar nicht, ob der allgemeine highway=footway-Wildwuchs darauf zurückzuführen ist. Aber ich hätte auf jeden Fall gerne eine Vereinheitlichung dessen was das Wiki zu diesem Tag sagt. Momentaner Stand: [[DE:Map_Features]] sagt zu highway=footway: Allgemeiner Fußweg, hauptsächlich für Fußgänger. (Ein offizieller Fußweg mit Beschilderung wird von highway=path, foot=designated genauer beschrieben). [[DE:Tag:highway=footway]] aber: Für ausgewiesene (designated) Fußwege. In Deutschland sind diese Wege meist ausgeschildert, insbesondere solche die ansonsten nicht eindeutig als ausgewiesener Fußweg erkannt werden können (also praktisch alle die nicht direkt neben der Straße als typischer Gehweg verlaufen). Ersteres bedeutet doch highway=footway ist gleich highway=path, foot=yes (wobei foot=yes an sich auch überflüssig ist). Letzteres jedoch es ist gleich highway=path, foot=designated. Wenn schon was im Wiki steht, sollten doch wohl auch alle Angaben stimmig sein. Auf Grund der sehr häufigen Verwendung für nicht beschilderte Wege wäre ich für die Interpretation wie in den Mapfeatures. Was ich auch nicht finden konnte ist, wie es (zumindest in Deutschland) rechtlich aussieht wenn Fahrradfahrer Wege benutzen die nicht extra beschildert und auch kein Gehweg (also kein Teil der Verkehrsfläche einer Straße) sind. Ich mache es eher so nach bauchgefuehl - Path ist alles was nicht aktiv angelegt sondern durch nutzung/trampeln hergestellt wurde. Alles was angelegt wurde im sinne von gepflastert/geteert/geschottert tagge ich je nach beschilderung oder dominanter benutzung als highway=footway oder cycleway und packe typischerweise (solange nicht wirklich die Beschilderung etwas anderes sagt) ein foot/bicycle=yes dabei. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
On Wed, Jun 24, 2009 at 03:45:08PM +0200, Mirko Küster wrote: Die Standard Trompete zeichne ich schon immer getrennt. Jeweils ein Link für rauf und runter mit Oneway. Und der Link beginnt und endet bei mir mit Beginn und Ende von Beschleunigungs- bzw. Verzögerungsstreifen. Empfinde ich so als bestmögliche Wiedergabe der Situation mit den derzeitig verfügbaren Mitteln. So mache ich das auch - die Diskussion zum thema ab/auffahrt und oneways die ein routing verhindern deutet aber daraufhin das eben nicht alle das so machen sondern gerne einfach mal das ding mit der durchgezogenen linie oder dem nicht mehr wenden duerfen ignorieren (der einfachheit halber). Wenn man dann noch implizite oneways oder allzu eifrige mapper mit oneway fimmel dazu nimmt ist halt schon der Kindergarten im Brunnen was das routing angeht ... Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] waterway=dam / OSM Inspector / water
Hallo Martin, Wenn ich Tunnel suche will ich ja auch nicht Durchgangshoehle finden, oder? *lach* Klar, war ja auch nur ein Beispiel für Jugend forscht, also was man als Benutzer für Klimmzüge versucht, wenn man im Wiki etwas nicht findet... Eine Wiki-Seite, die Geländeerhebungen und -Vertiefungen jeglicher Art übersichtlich darstellt, und erklärt wie sie sinnvoll attributiert werden, wäre hier hilfreich. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routing Fehler A3-B58
Wenn man dann noch implizite oneways oder allzu eifrige mapper mit oneway fimmel dazu nimmt ist halt schon der Kindergarten im Brunnen was das routing angeht ... Man kann so vieles implizieren... ganz lustig wird es dann z.B. bei gänzlich unbeschilderten Wegen, wo irgendwelches Landesrecht gilt, was doch in der Praxis keiner kennt. Ausser Fachleuten und Leuten wie uns die sich damit befassen, liest das keiner, weiß oftmals nichtmal von dessen Existenz. Da haben wir z.B. die implizierte Maxspeed 100 auf Landstraßen. Schon da scheiterts bei vielen Autofahrern die dann irgendwas bis 130 implizieren. Muss man nur mal googeln, das erleuchtet. Die trage ich desshalb auch immer mit ein. Nicht nur um Klarheit zu schaffen. So sehen andere Mapper auch das jemand zu diesem und jenem Zeitpunkt vor Ort war und alles erfasst hat. Steht nichts ist es zweideutig. Entweder wurde nicht erfasst oder da vertraut einer auf reines implizieren. Im Zweifelsfall gilt zweiteres und der eine oder andere fährt dann sinnlos Kontrolle. Klare Angaben gehen bei mir soweit wie möglich verwendbar immer vor implizieren. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
On 2009-06-24 16:09, Markus wrote: Ich fürchte Handarbeit. Ausgeschlossen: die Grenze besteht aus 6000 doppelten Punkten. Und es gibt 12.112 Grenzen... Wenn jede, oder auch nur 10 solcher großen Grenzen, in diesem Format kommen, ja. Ist das Standard bei Gemeinden (oder woher Du die hast)? Guck Dir mal Detleft Lösung an, was er schreibt liest sich doch gut. 2. wie das mit den Multipolygonen für so verschachtelte Grenzen funktioniert. Ich finde [[DE:Grenze_zeichnen]] erklärt das ganz gut. Ist ja auch von mir... Na dann weißt Du doch wie es funktioniert. Ich sehe das Problem nicht. Aber als Workflow für 12.112 Gemeinden ist das m.E. unbrauchbar. Na wieso unbrauchbar. Der aufwendige Teil ist doch das Zeichnen bzw. Zusammenkleben der ways. Und das ist doch unabhängig vom Tagging oder der Einordnung in Relationen. Ansonsten läuft es raus auf Selektion von mehreren Flächen, erstellen Relation, taggen. Wenn es hier Unterstützung von den Editoren, also wohl JOSM gäbe wäre es zwar nett, aber so aufwendig ist auch ohne nicht. Die 12.112 Gemeinden werden ja wohl weder beim selben Mapper noch innerhalb einer Woche aufschlagen. Lennard hat aus der DFX (vermutlich in Handarbeit!) eine OSM gemacht und die 4 Polygone in ein Multipolygon gepackt. Verwirrend finde ich, dass er 2 outer hat: 1. Stadt Lauf: outer 2. kleiner Staatswald: inner 3. grosser Staatswald: inner 4. kleines Gemeindegebiet im grossen Staatswald: outer Ja, so würde ich es auch machen. Und Du sagst ja, dass das kleine Gemeindegebiet im grossen Staatswald zusätzlich noch ein inner in einer zusätzlichen Multirelation grosser Staaatswald bekommen soll? Effektiv hast Du doch zwei Gebiete, Gemeinde Lauf und gemeindefreies Gebiet Schönberg. Also würde ich jedem ein Multipolygon geben. Und in das des gemeindefreien Gebiets wird auch die Grenze der Enklave als inner aufgenommen, die Außengrenzen der Staatswälder als outer - also genau umgekehrt wie im Lauf-Polygon. Ob das irgendeiner der Renderer oder Router versteht? Warum nicht? Guck' Dir beispielsweise den OSM3S an (http://78.46.81.38/#section.reverse_gazetteer) und gebe eine Koordinate in Brunn (Exklave von Nürnberg) an. Oder eine Koordinate des Gemeindefreien Gebiets (Enklave in Nürnberg) beim Gewerbepark. Kommt das richtige raus. Eine Enklave in einer Exklave fällt mir keine ein, aber das sollte auch kein Problem sein. Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] was ist ein footway?
On 2009-06-24 17:20, Florian Lohoff wrote: Ich mache es eher so nach bauchgefuehl - Path ist alles was nicht aktiv angelegt sondern durch nutzung/trampeln hergestellt wurde. Alles was angelegt wurde im sinne von gepflastert/geteert/geschottert tagge ich je nach beschilderung oder dominanter benutzung als highway=footway oder cycleway und packe typischerweise (solange nicht wirklich die Beschilderung etwas anderes sagt) ein foot/bicycle=yes dabei. Sorum geht's natürlich auch, das stimmt. Wobei ich mich dann auch frage, was für eine Art Weg ist denn ein cycleway + foot=yes? Rolf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
Und es gibt 12.112 Grenzen... 12.038 wenn ich die von mir bereits eingepflegten abziehe. Welchen Stand hat die Zahl überhaupt? Am 1.6 wurden im Nachbarkreis einige Gemeinden zusammengelgt, so schon in OSM. Da schon erfasst musste ich da nur welche Rausnehmen und Relationen anpassen. Wenn jeder mal in seinem Kreis ansetzt ist das kein Hexenwerk. Es braucht auch nicht immer die Gemeinden. Es reichen teilweise historische Karten. Die Grenzen sind uralt und änderten sich eigentlich nur beim zusammenlegen von Gemeinden, was man sieht und eben berücksichtigen muss. Grenzänderungen durch Gebietstausch sind eher selten. Gruß Mirko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] DXF-Datei Gemeindegrenze - OSM
Am Mi, 24.06.2009, 18:12 schrieb Mirko Küster: Wenn jeder mal in seinem Kreis ansetzt ist das kein Hexenwerk. Vermutlich ist es eh sinnvoller sowas über die Kreise abzuwickeln - dann könnte man sich einen Großteil der Arbeit ersparen :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Routerhärtetest - Topologie oder STVO?
Moin, NACK. Wie ich oben schon schrieb, ich hätte Dich bzw. den relevanten Mapper den ich in der History sehe angemailt. Warum hast Du das und das so und so erfasst, ich finde das wäre hier und hier besser, was sasgt Du dazu? es spricht ja nichts dagegen, dass Du das so machst. Es soll aber auch ohne möglich sein. Denn sonst führt das dazu, dass jemand eine Verbesserung vornehmen könnte, es dann aber dann doch bleiben lässt, weil es ihm zu aufwändig ist, die Sache, die er _jetzt_ in wenigen Minuten erledigen könnte, erst tagelang abstimmen zu müssen. Cheers, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
