Re: [OSM-talk] What is amenity=food_outlets in map features?
2009/3/29 Ulf Lamping ulf.lamp...@googlemail.com: Hi! Someone added amenity=food_outlets to the map features and even after reading the comment An area with several food outlets I'm quite unsure what this could be. Is this a collection of several amenity=fast_food or a kind of vending_machine or ...? Can someone explain this a bit? Regards, ULFL P.S: A photo would also be nice and may explain it even better ... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk I'm guess its a an area with several different resterants and or fast food outlets together, Say a McDonalds, Burger King, Frankey and Benny's, etc etc. usually found near a cinema, or in one corner of a large Shopping Centre like Bluewater, or even China Town in central London (at a pinch). Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Cycle map: trunk-roads in mountains
Can you spot it? http://www.openstreetmap.org/?lat=31.4122lon=-7.3859zoom=12layers=00B0FTF ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - Voting - Miniature Golf
Hi Please go vote for the Miniature golf tag: http://wiki.openstreetmap.org/wiki/Proposed_features/Miniature_Golf Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 OJ W ojwli...@googlemail.com: Can you spot it? http://www.openstreetmap.org/?lat=31.4122lon=-7.3859zoom=12layers=00B0FTF That's what you get for not building epic bridges, tunnels, and other contour defying structures :-P Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 OJ W ojwli...@googlemail.com: Can you spot it? http://www.openstreetmap.org/?lat=31.4122lon=-7.3859zoom=12layers=00B0FTF LOL, not at all - it needs more than a slight colour adjustment... -- Łukasz [DeeJay1] Jernaś ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
El Domingo, 29 de Marzo de 2009, Dave Stubbs escribió: 2009/3/29 OJ W ojwli...@googlemail.com: Can you spot it? http://www.openstreetmap.org/?lat=31.4122lon=-7.3859zoom=12layers=00B0 FTF That's what you get for not building epic bridges, tunnels, and other contour defying structures :-P No, that's what you get for colouring trunks green instead of red pedanticas it should be/pedantic. I'll just file this one next to the don't paint motorways the same colour as rivers one. Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es ¿Que sentido tiene correr cuando estamos en la carretera equivocada? signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] turn restriction relations: via
I've been implementing turn restriction support for some (still unpublished) software recently -- and, of course, have also added every restriction I could find to OSM. While the concept of restriction relations generally works well, there is one thing in particular I'm not really happy with: the effort that is required to handle via members. Can/should I assume * that there will always be exactly one finite sequence per restriction that includes all via members? * that via ways will be split to connect with each other and with from/to only at start/end nodes (this is recommended for from/to, but not mentioned anywhere for via ways)? * that a relation using via nodes will always contain all nodes as via nodes one would travel along * that a restriction will include either via ways or via nodes, but not both? Making these assumptions wouldn't prevent the description of any real-life-situation. It would, however, make evaluating restrictions (as well as understanding the effects of a restriction as a mapper) more easy. I also wondered whether it is really necessary to allow both (multiple) nodes and ways as via members, as each possibility alone can perfectly handle all situations and there is no significant difference in mapping effort either. So why don't we restrict the via role to ways (except maybe for the popular single-via-node case)? Tobias Knerr PS: I'm perfectly aware that there is no authoritative documentation, that I can implement and map whatever I want etc. I'm just interested in other people's opinions. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 Iván Sánchez Ortega i...@sanchezortega.es: El Domingo, 29 de Marzo de 2009, Dave Stubbs escribió: 2009/3/29 OJ W ojwli...@googlemail.com: Can you spot it? http://www.openstreetmap.org/?lat=31.4122lon=-7.3859zoom=12layers=00B0 FTF That's what you get for not building epic bridges, tunnels, and other contour defying structures :-P No, that's what you get for colouring trunks green instead of red pedanticas it should be/pedantic. Ha! Trunk roads should be green. I have the stone tablets to prove it. :-) Here's the solution: get the local authority to add a cycle lane, tag the road as having a cycle lane. Then the road will be blindingly obvious. Anyway, having actually been down that road in a manically driven minibus I can honestly say I wouldn't recommend cycling down it... but then I wouldn't really want to cycle/drive in morroco at all. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Cycle map: trunk-roads in mountains
2009/3/29 Dave Stubbs osm.l...@randomjunk.co.uk: Here's the solution: get the local authority to add a cycle lane, tag the road as having a cycle lane. Then the road will be blindingly obvious. The roads in that area tend to have an all-purpose additional lane on both sides, comprising a gravel surface (with about 10mm stones) which is used by cyclists, pedestrians, goods vehicles (i.e. mules), and as an overtaking lane. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=cyclefootway
-Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of Mike Harris Sent: 28 March 2009 15:05 To: 'Chris Hill'; 'Stephen Hope'; talk@openstreetmap.org Subject: Re: [OSM-talk] highway=cyclefootway By the way - in England and Wales, cyclists are normally allowed to use public bridleways (but the highways authority has no obligation to maintain the way to a standard that makes it possible to cycle) unless explicitly forbidden by a very localised regulation. Cyclists must also give way to cyclists and horse riders. [Snip] I guess you meant that cyclists are meant to give way to pedestrians and horse riders. Cyclists having to give way to other cyclists would lead to deadlock :-) Gregory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Let me first give a bit of an introduction to the algorithms for other readers on the list. At first glance Dijkstra finds the shortest route to any node n from a given node a, but exactly how (from the North, South etc) node n was reached is not specified. So turning restrictions cannot be handled. One solution is to look at http://en.wikipedia.org/wiki/Line_graph but it does not really handle complicated restrictions like this one: A single carriage way S crosses a double carriage way consisting of ways A and B at nodes D and E. Traveling down A you are not allowed to use S to make a u-turn into B. A simple solution to this problem is not to think of Dijkstra vertices as OSM nodes, but to think of them as state-machine states, for example I'm at D traveling backwards along S. And the above mentioned restriction would require having than 2 times as many possible states as there are segments. That's all the ussual states (I'm at ... traveling forwards / backwards along ... without having triggered any restrictions) as well as states like I'm at D traveling backwards along S after triggering restriction R. This last state will mean that : S is in R's via If W1, W2,...,Wk,S is the list of ways that I traveled along then there exists a i such that Wi=R.from and Wi+1,...,Wk are all in R.via. I guess there are even a few real world examples where we will need states where more than one restriction was triggered. Like a small service way leaving the abovementioned junction from E that you may not enter coming from A. It means the code will not be very fast, but given how rare these things are, speed's not an issue. Based on this description I can't see why we should require that via ways like S should be split into optimal ways, i.e. at D and E. The program will run faster, but the mapper is ultimately responsible from spotting ambigueties and splitting ways so that they don't occur. Regards, Nic ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] tag template status section
Hi, From the wiki description, it seems that all tags .. keys/values should have the basic template. The last part of the template box is status and just shows up as 'undefined' .. How do i change that status, so it could be more meaningful? http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dworks Thanks, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
On Sun, Mar 29, 2009 at 1:50 PM, Tobias Knerr o...@tobias-knerr.de wrote: I've been implementing turn restriction support for some (still unpublished) software recently -- and, of course, have also added every restriction I could find to OSM. While the concept of restriction relations generally works well, there is one thing in particular I'm not really happy with: the effort that is required to handle via members. One question, does anyone have an implementation of turn-restrictions that have via as more then an optional specifier for a list of nodes to limit the effect of the restriction to only intersections where from and to meet at one of the via-nodes? (either via being a start- , end- or middle- node of to and from)? We may have specified something that is just too complex to be implemented and debugged in every or the routers we have. PS: I found the idea of Nic to be easy to implement when he mentioned it before. It took me less then 2 days to convert a well documented and structured Dijkstra -implementation to work as he described and observed no visible performance loss so far. (You may try for yourself by using Traveling Salesman and calculating the same route while having either MultiTargedDijkstraRouter or TurnRestrictedMultiTargedDijkstraRouter in the options-dialog. No restart is required after changing the option.) Marcus http://travelingsales.sourceforge.net ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] tag template status section
Cool, thats step 1. .. thanks for fixing. For the 2nd part, should it be standard for all proposed tags to have draft/proposed/voting/post-vote cleanup. also on this template?? For the 3rd part, i think noting the following sections for the template would be helpful to users. And perhaps the voting section should also be included?? so then people know that the key/value was actually voted on... and what the results were.. (so if the status is 'rejected' then people would be able to learn why instantly. and the suggested alternates would be shown. ** ==How to Map == ==Extended Usage == ==Examples == (chart with) Picture/Description TagsMapnik Osmarender ==See Also== ==Voting == *** Cheers, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Nic Roets schrieb: Based on this description I can't see why we should require that via ways like S should be split into optimal ways, i.e. at D and E. The program will run faster, but the mapper is ultimately responsible from spotting ambigueties and splitting ways so that they don't occur. Avoiding ambiguous restrictions is indeed the main reason for the assumptions I suggested. However, splitting the 'via' ways isn't really necessary for that purpose. That I thought it was is probably a consequence of thinking in the box of my own implementation (which creates ordered forbidden sequences to represent restrictions). Apparently, ignoring order solves any problems associated with that, though I still have to try whether that works (I guess it will.) I'm not exactly sure what the semantics of an only_* with several via members would be, though. Should it require that you use at least one via member or every via member? Despite via splitting not being necessary for proper relation handling, I still think that a relation using via nodes will always contain all nodes as via nodes one would travel along is essential. Otherwise, there would inevitably be some problems: If, in your example, the via information was represented by via nodes on S instead of via way(s), that restriction would also forbid turning left from A onto S, following S without turning into B, then using other roads to return to the double carriageway and following B back to the restriction's to part. This is obviously not intended. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Hi Someone else started a proposal for a gym, I need it in my area. So I'm finishing it off: http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Please RFC. Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Hi Tobias Marcus On Sun, Mar 29, 2009 at 8:06 PM, Tobias Knerr o...@tobias-knerr.de wrote: I'm not exactly sure what the semantics of an only_* with several via members would be, though. Should it require that you use at least one via member or every via member? I implemented only_* as something that's disallowed i.e. a restriction. The obligation interpretation only came later. Perhaps we can specify that complex vias may not have only_*'s and require people to implement their ideas with no_'s ? Despite via splitting not being necessary for proper relation handling, I still think that a relation using via nodes will always contain all nodes as via nodes one would travel along is essential. Otherwise, there would inevitably be some problems: If, in your example, the via information was represented by via nodes on S instead of via way(s), that restriction would also forbid turning left from A onto S, following S without turning into B, then using other roads to return to the double carriageway and following B back to the restriction's to part. This is obviously not intended. Tobias Knerr I think we should require that complex vias must always include all the ways that are traveled. One question, does anyone have an implementation of turn-restrictions that have via as more then an optional specifier for a list of nodes to limit the effect of the restriction to only intersections where from and to meet at one of the via-nodes? (either via being a start- , end- or middle- node of to and from)? Not me. Regards, Nic ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=cyclefootway
Whoops! Yes - cyclists are supposed to give way to pedestrians and horse riders. Fingers faster than brain - sorry! Mike Harris -Original Message- From: Gregory Williams [mailto:gregory.willi...@purplegeodesoftware.co.uk] Sent: 29 March 2009 15:09 To: talk@openstreetmap.org Subject: Re: [OSM-talk] highway=cyclefootway -Original Message- From: talk-boun...@openstreetmap.org [mailto:talk- boun...@openstreetmap.org] On Behalf Of Mike Harris Sent: 28 March 2009 15:05 To: 'Chris Hill'; 'Stephen Hope'; talk@openstreetmap.org Subject: Re: [OSM-talk] highway=cyclefootway By the way - in England and Wales, cyclists are normally allowed to use public bridleways (but the highways authority has no obligation to maintain the way to a standard that makes it possible to cycle) unless explicitly forbidden by a very localised regulation. Cyclists must also give way to cyclists and horse riders. [Snip] I guess you meant that cyclists are meant to give way to pedestrians and horse riders. Cyclists having to give way to other cyclists would lead to deadlock :-) Gregory ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Adrian Moisey schrieb: Hi Someone else started a proposal for a gym, I need it in my area. So I'm finishing it off: http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Why not simply use: leisure=sports_centre sport=work_out (or gymnastics or ...) Regards, ULFL ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] turn restriction relations: via
Nic Roets wrote: I implemented only_* as something that's disallowed i.e. a restriction. The obligation interpretation only came later. Perhaps we can specify that complex vias may not have only_*'s and require people to implement their ideas with no_'s ? While I don't see a problem with this requirement in theory, I doubt that the idea would be a very popular, partly because the traffic signs (rendering hints) and the relation semantics have been merged by using that strange only_/no_-prefix solution. Despite via splitting not being necessary for proper relation handling, I still think that a relation using via nodes will always contain all nodes as via nodes one would travel along is essential. Otherwise, there would inevitably be some problems: If, in your example, the via information was represented by via nodes on S instead of via way(s), that restriction would also forbid turning left from A onto S, following S without turning into B, then using other roads to return to the double carriageway and following B back to the restriction's to part. This is obviously not intended. I think we should require that complex vias must always include all the ways that are traveled. Does way mean way primitives here, as opposed to nodes? Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Am Sonntag 29 März 2009 schrieb Ulf Lamping: Adrian Moisey schrieb: Hi Someone else started a proposal for a gym, I need it in my area. So I'm finishing it off: http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Why not simply use: leisure=sports_centre sport=work_out (or gymnastics or ...) Regards, ULFL wh have a key for sports facilites, so why not sport=gym? signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is amenity=food_outlets in map features?
I'm guessing a food court. That's the term I've always heard, anyway. http://en.wikipedia.org/wiki/Food_court Stephen 2009/3/29 Ulf Lamping ulf.lamp...@googlemail.com: Hi! Someone added amenity=food_outlets to the map features and even after reading the comment An area with several food outlets I'm quite unsure what this could be. Is this a collection of several amenity=fast_food or a kind of vending_machine or ...? Can someone explain this a bit? Regards, ULFL P.S: A photo would also be nice and may explain it even better ... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] What is amenity=food_outlets in map features?
Someone added amenity=food_outlets to the map features and even after reading the comment An area with several food outlets I'm quite unsure what this could be. Is this a collection of several amenity=fast_food or a kind of vending_machine or ...? In the US we have a thing called food court. There is a central common seating area, and around the edge there are places selling food, typically fast food type. Each has a counter that would almost join the next one's counter - think of a mcdonald's where only the counter part and behind of the restaurant exists. There may also be some kiosk/stands that are self-contained in the middle. These are typically places you don't want to go and don't want to buy food at, but are convenient. They are found in shopping malls, airports and some train stations. There are also areas in airports with multiple restaurants near each other and individual seating. To be a food court (in my view), there has to be a shared seating area among the restaurtants, with the restaurants not having seating. From the US point of view I would tag the entire common area 'amenity=food_court', and tag some of the individual restaurants 'amenity=fast_food'. Some of the places sell coffee and pastries and are more properly amenity=cafe. The public can't go in the individual restaurants in a food court. http://commons.wikimedia.org/wiki/File:Union_station_dc_food_court.jpg http://pdphoto.org/PictureDetail.php?pg=8061 http://www.yelp.com/biz_photos/qoHkEmKspps3ZCwor3xLug?select=TNc3qREb5TJ_tr1AicIatg http://www.flickr.com/photos/flaneur/409846061/in/set-72157594581857903/ http://www.flickr.com/photos/mr_t_in_dc/2085996881/in/pool-canon-eos-450d pgpk3bYXuOC0T.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Allowed ? GSoC'09
Rajan + list, This one is from written with my CloudMade keyboard ;-) Just to be clear the Personal Use parts of the CloudMade TCs refer to the site contents and use of the website - cloudmade.com, rather than any of the APIs and web service. You, and everyone else are welcome to use CloudMade's APIs, web services and the documentation provided on the site in personal, public or business uses. Which CloudMade libraries are you particularly interested in using? The Ruby, Python and Java libs are all open source (L-GPL) and we're happy to support anyone who'd like to develop libraries in other languages. Libraries TCs (L-GPL) - http://www.cloudmade.com/products/libraries_apis/terms_of_use Website TCs - http://cloudmade.com/terms_conditions Web Maps Lite (Jacascript library) TCs - http://developers.cloudmade.com/projects/web-maps-lite/terms Hope this clarifies things for you. Nick On Sat, Mar 28, 2009 at 7:13 AM, Frederik Ramm frede...@remote.org wrote: Hi, rajan vaish wrote: Hi,I am working on my proposal for GSoC'09 right now and for the routing implementation tasks ,I intend to use Libraries/APIs of CloudMade ( http://developers.cloudmade.com/ ) which works on OSM as well.Am I allowed to use the same ? I don't see why not. It is true that CloudMade say you may use their site solely for your personal use, whereas Google say any software you produce must be licensed under an OSI approved license (i.e. you cannot produce software licensed as only for personal use). But you can simply pass on this restriction to the users of your software: The software you make is free for use/inspection/modification by anybody as per the OSI compliant license you choose, but if people then use your software to access the CloudMade site then they may only do so for their personal use. As you correctly point out, the situation is similar to GSoc students writing software that interacts with Google Maps. Whether or not the OSM project accepts and endorses a proposal for a GSoC project that will only work using the services of CloudMade (which are outside the control of the OSM project) is of course another matter, but I guess if it is something seriously cool then nobody will ask many questions. I believe that CloudMade used to have a developer sponsorship programme of their own where they handed out grants for the development of OSM-related software, so that might be another avenue for you to follow up (but you should really ask them directly as it has been a while since this was last mentioned). Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- -- Nick Black twitter.com/nick_b ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - shop=pet
Hi It seems that a way to tag shops that sell pets and pet supplies is desirable and the clear way to do that is with shop=pet. There are some sub-tags in the proposal, too. Please review it at http://wiki.openstreetmap.org/wiki/Proposed_features/pet_shop and share your thoughts and suggestions. -P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Tagging dangerous areas
This isn't a formal proposal so much as presenting an idea. When i was booking a hotel recently for travel, a friend who knew the area advised me that it was a dangerous neighborhood. That allowed me to find a different hotel in a safer area and possibly save myself some unpleasantness. This kind of word-of-mouth knowledge is the kind of thing open projects can excel at providing. The problem, of course, is a metric for something as subjective as dangerous neighborhood. It it dangerous at 12:00 or at 01:00? Is it unsafe to park a bike/car there? Would some tagging system to indicate dangerous area be desirable, and how would it best be implemented? Cheers P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Tagging dangerous areas
On Mar 29, 2009, at 10:42 PM, NL wrote: Is it unsafe to park a bike/car there? We should mark areas of high bicycle theft, but we'd need a map to display it. -- 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 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] [tagging] Feature Proposal - RFC - h==highway
Request for comments on creating the key:h and making it synonymous with key:highway. As i understand things, this has four huge benefits: -reduce data entry time when editing OSM (e.g. 6/7ths less characters to type) -reduce data entry errors when editing OSM (current obvious errors from tagwatch europe: highlight, hightway, highwaY, highwat, higwhway, and the champion, higway, with 1478 entries) -reduce OSM data storage space (over 6M highways just from http://tagwatch.stoecker.eu/Europe/En/tags.html; simple naive estimate 6M*6 bytes=36MBytes uncompressed data reduction) -reduce bandwidth for transfers to/from OSM What do you think? Cheers, P ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] [tagging] Feature Propoasl - RFC - Gym
Hi Someone else started a proposal for a gym, I need it in my area. So I'm finishing it off: http://wiki.openstreetmap.org/wiki/Proposed_features/Gym Why not simply use: leisure=sports_centre sport=work_out (or gymnastics or ...) Regards, ULFL wh have a key for sports facilites, so why not sport=gym? There are no tags for 'sport=work-out' or 'sport=gym'. Also, a Gym isn't a sports_centre, its an actual building designed for Gymning. http://en.wikipedia.org/wiki/Gym Adrian ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] openbaar vervoer routes
Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Dat valt zeker onder de categorie: awesome! Vanavond eens kijken of wij dat ook draaien krijgen :D --Roeland On Sunday 29 March 2009 13:23:44 Floris Looijesteijn wrote: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Floris Looijesteijn wrote: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. Dat lijken alleen tram routes right? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Ook bus... Lijn 40 en Metro (50,51,53,54) Maar qua bus is er nog wel wat te doen inderdaad. --Roeland On Sunday 29 March 2009 13:30:10 Stefan de Konink wrote: Floris Looijesteijn wrote: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. Dat lijken alleen tram routes right? Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Roeland Douma wrote: Ook bus... Lijn 40 en Metro (50,51,53,54) Maar qua bus is er nog wel wat te doen inderdaad. Gaarne combineren met m'n eerdere RFE ;) Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Op 29 maart 2009 13:23 heeft Floris Looijesteijn geschreven: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. In Den Haag is het resultaat een stuk minder :-( http://öpnvkarte.de/?lat=52.0822lon=4.3086zoom=13 Dit ene rode streep is bus 14, en dan heb je het wel zo'n beetje gehad. Ik wil best helpen een aantal lijnen te mappen, maar dan zal ik eerst gaan uitzoeken hoe je zo'n routes moet taggen. Gegroet, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
In JOSM is het best goed te doen tegenwoordig. Zie ook: http://wiki.openstreetmap.org/wiki/Relation:route#Public_Transportation of eigenlijk die hele pagina. Ik zal leiden binnenkort eens wat busroutes gaan geven groet, floris Op 29 maart 2009 13:23 heeft Floris Looijesteijn geschreven: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. In Den Haag is het resultaat een stuk minder :-( http://öpnvkarte.de/?lat=52.0822lon=4.3086zoom=13 Dit ene rode streep is bus 14, en dan heb je het wel zo'n beetje gehad. Ik wil best helpen een aantal lijnen te mappen, maar dan zal ik eerst gaan uitzoeken hoe je zo'n routes moet taggen. Gegroet, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
Die lijn 14 heb ik een tijd geleden ingetikt. We hebben van district haaglanden alle gps traces van de bussen en trams in DH en omstreken Hter beschikking (geen haltes). Totdat ik of iemand anders de situatie rond CS goed in kaart heeft gebracht (flink ingewikkeld!) Is het project stilgelegd. Gert Gremmen -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Frank Fesevur Verzonden: zondag 29 maart 2009 18:46 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] openbaar vervoer routes Op 29 maart 2009 13:23 heeft Floris Looijesteijn geschreven: Gister in Essen werd er een mooi kaartje gebruikt die ik nog niet eerder gezien had: http://öpnvkarte.de/?lat=52.3689lon=4.9065zoom=14 Zoals je ziet doet ie het ook in Amsterdam. In Den Haag is het resultaat een stuk minder :-( http://öpnvkarte.de/?lat=52.0822lon=4.3086zoom=13 Dit ene rode streep is bus 14, en dan heb je het wel zo'n beetje gehad. Ik wil best helpen een aantal lijnen te mappen, maar dan zal ik eerst gaan uitzoeken hoe je zo'n routes moet taggen. Gegroet, Frank ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] openbaar vervoer routes
ce-test, qualified testing bv - Gert Gremmen wrote: Die lijn 14 heb ik een tijd geleden ingetikt. We hebben van district haaglanden alle gps traces van de bussen en trams in DH en omstreken Hter beschikking (geen haltes). Totdat ik of iemand anders de situatie rond CS goed in kaart heeft gebracht (flink ingewikkeld!) Is het project stilgelegd. Ik wil er best wat aan bijdragen (lang leve OV kaart) maar daarvoor wil ik eerst de op IRC al vele male beschreven 'applicatie' online hebben. Dat zou betekenen dat je 'haltes' als dynamische PIO's op de kaart ziet, ga je over een halte heen dan krijg je de hele route als overlay te zien, door vervolgens te dubbelklikken blijft de overlay te zien en kun je een andere route aan klikken om er bij te voegen. Door aan deze informatie weer dynamische PoI's te koppelen die treinen, bussen etc. representeren krijg je een mogelijkheid om direct visueel te zien wanneer het zin heeft om naar een bus te rennen of rustig aan te doen. Milo, is met het eerste stuk (de dynamische haltes) begonnen. Stefan ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Christoph Eckert wrote: http://dodger.webfactional.com/de/tag/landuse/ Hier klcikte ich oben auf values, und farm fehlt hier. Doofe Frage, aber Du weißt, dass Du oben rechts nen Filter hast? (Oder weiterblättern kannst...) Zum N800/N810: MicroB ist im Prinzip ein Mozilla-Browser und keine komplette Eigenentwicklung. In den alten Versionen war es übrigens die Opera-Engine... ...gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Garry wrote: Vielleicht ein Beispiel dafür warum stillgelegte Strecken angezeigt werden sollten... Ohne mich da jetzt einmischen zu wollen, aber stillgelegt verstehe ich anders. Was Du beschreibst ist ein construction (oder repair, or temporary_unavailable) oder sowas. stillgelegt=abandoned=aufgegeben = Da war mal Bahnverkehr, jetzt aber nicht mehr. Vielleicht liegen sogar noch Gleise, aber da fährt kein Zug mehr! Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Garry wrote: Vielleicht ein Beispiel dafür warum stillgelegte Strecken angezeigt werden sollten... Ohne mich da jetzt einmischen zu wollen, aber stillgelegt verstehe ich anders. Was Du beschreibst ist ein construction (oder repair, or temporary_unavailable) oder sowas. stillgelegt=abandoned=aufgegeben = Da war mal Bahnverkehr, jetzt aber nicht mehr. Vielleicht liegen sogar noch Gleise, aber da fährt kein Zug mehr! Gerrit Garry meint, so denke ich, schon das richtige. Allerdings wird railway=disused nicht von allen Renderern angezeigt. Railwy=rail und disused=yes wird aber von allen angezeigt. In den Mapfeatures wird zweites ja auch empfohlen. Trotzdem wäre hier ein repair, oder ähnliches angebrachter, als ein disused. Denn Baustellen sind ja nicht stillgelegt... Paul ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Markus schrieb: Hallo Tobias * der chaotischen Semantik von : * der daraus und aus der unklaren Reihenfolge resultierenden umständlichen Auswertbarkeit Wie könnte die Alternative aussehen? Gruss, Markus Alternative Lane-Relation - http://wiki.openstreetmap.org/wiki/Proposed_features/lane_and_lane_group eindeutige Syntax. eindeutige Zuordnung. Einfache Eingabe mit dem Lane-Tool für JOSM. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue Garmin map vorerst für Sachsen a m Start
Torsten Leistikow schrieb: Ich habe mir inzwischen mal deinen Master-Style angeschaut. Dabei sind mir ein paar Sachen aufgefallen: 1. Bei den Linientypen werden in Mapsource (bei mir Version 6.11.6) nur 00-0f, 10-16, 18-1f und 20-2b angezeigt. Die anderen Typen bis 3f ignoriert Mapsource. Danach wiederholt es wieder die Typen, d.h. statt 04 wird 00 angezeigt. Versteh ich irgendwie nicht so ganz. 04 liegt doch zwischen 00 und 0f oder seh ich das verkehrt? Wertet Mapsource eigentlich das Typfile aus? Wenn nicht, dann ist alles klar. Ansonsten muss ich sagen spinnt Mapsource eben einfach. Wieso sollte bei 2b Schluss sein? Die bits hat man einmal zur Verfügung und dann wärs logisch, wenn das wenigstens bis 2f geht oder so. Die Garmingeraete verhalten sich da zwar anders, aber nach Moeglichkeit sollte man sich wohl auf die o.a. Typen konzentrieren. Leider gibt es sehr wenig Linientypen, so dass man sich nur schwer auf ein paar wenige konzentrieren kann... 2. Bei den Punktsymbolen haben die Garmingeraete nun wieder ihre Besonderheiten, wenn man eine eigene Typ-Datei benutzt. So tauchen viele deiner Symbole auf meinem Nuevi erst ab einer Zoom-Stufe von 50m auf. Gute Erfahrungen hab eich bisher mit den folgenden POI-Nummern gemacht: 4000-401f, 4100-411f, 5000-501f, 5100-511f, 6000-601f und 6100-611f. Die Bereiche 1000-101f und 1100-111f funktionieren theoretisch auch, nur benutzt mkgmap diese fuer die Markierung von Ortschaften. Zu den problematischen Nummern gehoeren leider auch welche, ueber die die POI Suche laeuft. Da muss man sich dann leider entscheiden, ob einem die Kartenansicht oder die Suchfunktion wichtiger ist. Wieder was gelernt. Muss mal sehen, ob ich das irgendwie in Zukunft berücksichtigen kann. Punkttypen stehen ja zum glück massig zur Verfügung. 3. Gut geholfen hat mir deine Idee, mehrere Karten mit verschiedenen Inhalten uebereinander zu stapeln. Aufgrund der in 2. geschilderten Problematik habe ich meinen Kartensatz jetzt wie folgt aufgebaut (niedrigste draw-priority zuerst): - ein Search-Layer, der nur die POIs fuer die Suchfunktion enthaelt. Dazu benutze ich einfach die points aus dem default-Style von mkgmap. - ein Main-Layer, der das routingfaehige Strassennetz, die Areas und die Punktsymbole fuer die Anzeige enthaelt. - ein SRTM-Layer, der Transparent noch die Hoehenlinien darueber legt. Joah der Plan hat mir auch ganz gut gefallen, aber das wird erst noch so richtig problematisch, wenn man große Gebiete versucht. Nicht nur das Mapauswahlmenü wird hammer unübersichtlich (wegen der vielen einzelnen Kacheln) sondern das Garmin kann ja leider nur eine begrenzte Anzahl an einzelnen Karten zugleich benutzen. Alles irgendwie unschön... Unter http://demuur.gmxhome.de/mapfeatures_example_v003.zip findest du meine selbstgebaute OSM-Beispieldatei, die orientiert an der Mapfeatures-Liste alle OSM-Elemente nebeneinander enthaelt. Einfach in einem Texteditor die Koordinaten so anpassen, dass sie bei dir in der Naehe liegen, die fuer deinen Geschmack fehlenden Elemente ergaenzen, und schon hat man eine Beispielkarte, in der man auf einen Blick seinen Style pruefen kann. Klingt gut! Werd ich bei Gelegenheit mal testen. Heut lockts mich aber mal wieder raus zum richtigen mappen *g* Grüße Christoph signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue Garmin map vorerst für Sachsen a m Start
Hallo, Christoph Wagner schrieb: Die Garmingeraete verhalten sich da zwar anders, aber nach Moeglichkeit sollte man sich wohl auf die o.a. Typen konzentrieren. Leider gibt es sehr wenig Linientypen, so dass man sich nur schwer auf ein paar wenige konzentrieren kann... Das ist genau bei meinen Karten der Fall, ich mache das so, eben aus Kompatibilitätsgründen. Wieder was gelernt. Muss mal sehen, ob ich das irgendwie in Zukunft berücksichtigen kann. Punkttypen stehen ja zum glück massig zur Verfügung. Was passiert eigentlich mit definierten Punkttypen, die bei den Garmins nicht vorgesehen sind, wenn kein Typfile da ist? zeigt er die als Standardpunkte? Joah der Plan hat mir auch ganz gut gefallen, aber das wird erst noch so richtig problematisch, wenn man große Gebiete versucht. Nicht nur das Mapauswahlmenü wird hammer unübersichtlich (wegen der vielen einzelnen Kacheln) sondern das Garmin kann ja leider nur eine begrenzte Anzahl an einzelnen Karten zugleich benutzen. Alles irgendwie unschön... So etwas funktioniert nur, wenn Du die Layer in einzelne Kartensätze verpackst, die man dann insgesamt aus und einschalten kann. Die Garmins können insgesamt etwa 2000 Kacheln auf einmal in einer gmapsupp.img verwalten, egal wieviel Kartensätze es sind. (siehe meine EU-Karte: 1949 Kacheln) -- Viele Grüße Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Hallo Martin, oder für einen 25 cm hohen Bordstein: border=curb border:height=0,25 oder für eine Mauer border=wall border:width=0,5 border:height=5 Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu zu fügen. Bisher wurden Bordsteinhöhen auch noch nicht getaggt? Grüße, Astrid -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Wie kriegt man Apps und Tags supported by Apps in das System? ;) Marcus 2009/3/28 Lars Francke lars.fran...@gmail.com: Hallo zusammen, ohne große Worte: http://dodger.webfactional.com Daten sind vom 22.3 oder 23.3. aber ich arbeite an täglichen Updates. An was ich noch arbeite sieht man teilweise schon an den nicht funktionierenden Links. Kritik, Wünsche und Vorschläge sind immer herzlich willkommen aber ich habe das bisher hauptsächlich für mich selbst benutzt und mich kurzfristig dazu entschieden das online zu stellen und dafür zu erweitern und aufzupolieren. Das ist daher eine sehr frühe Version in einem wilden Mix aus Englisch und Deutsch. Der Name ist auch eher...temporär und wenn jemand ne Idee hat her damit. Ich wollte nur nicht TagWatch verwenden, da das ja schon von einem anderen Programm besetzt ist. Ich freue mich über jeden Kommentar und hoffe, dass es für den ein oder anderen hilfreich ist. Lars PS: Das ist das erste mal in meinem Leben, dass ich CSS oder HTML für irgendwas sinnvolles benutzt habe. Ich denke das sieht man ;-) Man verzeihe mir. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Toll Collect Sensoren auf der Autobahn
Ich habe einmal den Tag gesehen. Ich bin mir aber nicht sicher ob es ihn wirklich gibt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Grenzrelationen in Rostock im Bereich der Unterwarnow
Am 28. März 2009 01:58 schrieb Stephan Wolff s.wo...@web.de: Die gestrichelte Linie an der Warnow verschwindet, wenn du die Rostock-Relation über die Ostsee führst. Wer zeichnet jetzt die gestrichelte Linie? Der way mit id=29412926 (boundary=administrative, admin_level=7) oder die Rostock-Relation-26226 (boundary=administrative, type=boundary)? Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Orte ausschneiden
Wie kann man einen durch ein Multipolygon definiertes Gebiet ausschneiden? Wenn ich es richtig sehe, braucht Osmosis ein .poly File als Eingabe... Kann man das irgendwie konvertieren? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Orte ausschneiden
Hallo Ulf, Am Sonntag 29. März 2009 14:57:20 schrieb Ulf Möller: Wie kann man einen durch ein Multipolygon definiertes Gebiet ausschneiden? Wenn ich es richtig sehe, braucht Osmosis ein .poly File als Eingabe... Kann man das irgendwie konvertieren? Schau dir mal http://wiki.openstreetmap.org/wiki/User:Geo-francis, speziell den Abschnitt Scripte zum Erstellen einer poly-Datei an. Grüße, Carsten -- Hier ist mein öffentlicher GPG-Schlüssel: http://daswaldhorn.funpic.de/gpg.html = www.stopptdievorratsdatenspeicherung.de 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] Toll Collect Sensoren auf der Autobahn
Hi, Ich habe einmal den Tag gesehen. Ich bin mir aber nicht sicher ob es ihn wirklich gibt. Wenns ihn nicht wirklich gibt, ligts an dir ihn zu erstellen :) Grüsse Raphael PS: Die Sensoren heissen übrigens Baken. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Habe mal ein Tool geschrieben, welches die Regeln aus Mapnik und Osmarender exportiert. Sinnvoller wäre es aber andersrum: Aus dem OSM-Inhalt müssten regeln erstellt werden. Wenn 100.000 Döner-Stops getaggt wurden, sollten sie _meiner Meinung nach_ auch dargestellt werden. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Aber Streckenabschnitte werden ja _zum Bauen_ vorübergehend komplett gesperrt. Wenn zB keine Weiche auf dem restlichen Teilabschnitt kommt. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue Garmin map vorerst für Sachsen a m Start
Christoph Wagner schrieb: Danach wiederholt es wieder die Typen, d.h. statt 04 wird 00 angezeigt. Versteh ich irgendwie nicht so ganz. 04 liegt doch zwischen 00 und 0f oder seh ich das verkehrt? Nee, das war ein Tippfehler bei mir. Statt 40 zeigt Mapsource die Linie 00 an, usw. Wertet Mapsource eigentlich das Typfile aus? Im Prinzip schon. Ansonsten muss ich sagen spinnt Mapsource eben einfach. Wieso sollte bei 2b Schluss sein? Die bits hat man einmal zur Verfügung und dann wärs logisch, wenn das wenigstens bis 2f geht oder so. Naja, wenn man Garmin-Karten baut, dann sollten die auch auf Garmin-Geraeten und am besten auch auf Garmin-Software laufen. Nur weil der Datenbereich die Bits hergibt, hat man da erstmal gar nichts von, wenn es am Ende nicht ausgewertet und angezeigt wird. Letztendlich sind die Geraete sicherlich das Wichtigere. Aber in Mapsource geht es deutlich schneller, neue Sachen zu probieren. Die Garmingeraete verhalten sich da zwar anders, aber nach Moeglichkeit sollte man sich wohl auf die o.a. Typen konzentrieren. Leider gibt es sehr wenig Linientypen, so dass man sich nur schwer auf ein paar wenige konzentrieren kann... Ich habe jetzt nicht nachgezaehlt, aber so etwa 45 Stueck sollten in etwa zur Verfuegung stehen. So viel mehr Linien kann man fuer eine Karte kaum brauchen, wenn man die auf den kleine Displays noch erkennen und unterscheiden koennen soll. Wieder was gelernt. Muss mal sehen, ob ich das irgendwie in Zukunft berücksichtigen kann. Punkttypen stehen ja zum glück massig zur Verfügung. Naja, s viele sind das auch nicht, von denen ich sicher weiss, dass sie sowohl in Mapsource als auch auf dem Nuevi ordentlich funktionieren. Bisher habe ich aber immer noch freie gefunden. Joah der Plan hat mir auch ganz gut gefallen, aber das wird erst noch so richtig problematisch, wenn man große Gebiete versucht. Nicht nur das Mapauswahlmenü wird hammer unübersichtlich (wegen der vielen einzelnen Kacheln) sondern das Garmin kann ja leider nur eine begrenzte Anzahl an einzelnen Karten zugleich benutzen. Alles irgendwie unschön... Also mit meinem Grossraum Deutschland habe ich bislang keine Probleme. Sowohl auf dem Nuevi als auch auf dem Etrex funktioniert das mit den 3 Layern. Dank Splitter funktioniert jetzt ja das Routing auch ueber Kachelgrenzen hinweg, aber quer durch Deutschland packt es ohne Zwischenpunkte noch nicht. Ok, es gibt wichtigeres. Klingt gut! Werd ich bei Gelegenheit mal testen. Heut lockts mich aber mal wieder raus zum richtigen mappen *g* Ich war heute angenehm ueberrascht, wieviel sich seit letzten Herbst getan hat. Mein Fahrradrevier ist zwar noch lange nicht komplett erfasst, aber einfach so nebenbei sammelt man da keine Strassen mehr, da muss man schon mal gezielt vom ueblichen Weg abweichen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] neue Garmin map vorerst für Sachsen a m Start
Carsten Schwede schrieb: Was passiert eigentlich mit definierten Punkttypen, die bei den Garmins nicht vorgesehen sind, wenn kein Typfile da ist? zeigt er die als Standardpunkte? Unterschiedlich. Entweder wird gar nichts angezeigt (womit man ja gut leben koennte), oder aber es werden irgendwelche Symbole aus dem eingebauten Satz angezeigt (was schon deutlich stoerender ist). Die Symbol-Nummer-Zuordnung ist bei den Garmins ja nicht eineindeutig, so dass da recht schnell ziemlicher Muell bei raus kommt. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Moin, Wenn 100.000 Döner-Stops getaggt wurden, sollten sie _meiner Meinung nach_ auch dargestellt werden. Straßenlampen und Hundehäufchen auch?!? ;) ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Kommt aud die Karte an, aber RAILWAY=PLATFORM vermisse ich schon. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
Moin! Ja wie man sieht ist da bei den Anwendungen noch nichts losich fand die Idee aber gut. Zum Teil wird das ja schon auf der MapFeatures-Seite bzw. im TagWatch verwendet aber ich denke das ist ausbaufähig. Ich konzentriere mich aber erstmal auf den Tags-Teil. Ein paar Neuigkeiten seit meiner ersten E-Mail gestern: - Man kann nun von einem Schlüssel auf eine Detailseite für einen Wert verlinken und die Werte auf der Schlüsselseite sind anklickbar. Aber auf der Detailseite gibt es noch nicht viel sinnvolles zu sehen - Schlüssel: http://dodger.webfactional.com/en/tag/landuse/ - Wert: http://dodger.webfactional.com/en/tag/landuse/farm - Sortieren von Werten geht nun auch (nach Name, und den Zählerständen) vorher war das nur bei den Keys moeglich, standardmäßig wird alles nach der gesamtanzahl sortiert - Man kann nun per /en oder /de zwischen englisch und deutsch umschalten. Andere Sprachen sind problemlos moeglich. Standard ist deutsch zur Zeit. - http://dodger.webfactional.com/en/tags/ - http://dodger.webfactional.com/de/tags/ - Ich habe eben grad die auch benutzt-Tabelle gefüllt. Problem ist nur, dass das noch nicht sortiert ist nach Relevanz aber das hole ich nach. Und es geht nur auf der Ebene Schlüssel-Schlüssel ich muss mal überlegen ob es sinnvoll und machbar ist das auch auszudehnen, die Tabelle der Beziehungen (nur zwischen den Schlüsseln) hat ca. 35 Millionen Zeilen wenn ich das auf Werte runterbreche dürfte das ganz gut nach oben gehen. Ich bin mit einigen Dingen noch nicht zufrieden. Zum Beispiel die Begriffe Tag, Key, Value (bzw. Tag, Schlüssel, Wert) und ob die für jeden verständlich sind. Tag benutze ich zur Zeit austauschbar für eine key:value-Kombination oder nur einen key. Auch weiß ich nicht ob ich die Begriffe übersetzen sollte oder da einheitlich bei englisch bleibe...aber gut das sind Kleinigkeiten. Ich denke mal für das aktuelle Publikum ist das kein Problem :) Abgesehen davon habe ich an den täglichen Updates gearbeitet (mit Trends und Grafiken und so) und durfte feststellen, dass meine lokale PostgreSQL-DB scheinbar nicht synchron ist mit dem tatsächlichen Stand. Da werden zum Beispiel in einem Diff Tags entfernt, die laut meiner Tagwatch-DB gar nicht da sein dürften so das der Zähler in den negativen Bereich rutschen würde. Ich überlege nun das einfach aufzuschieben bis 0.6 kommt oder ob ich die DB aus einer aktuellen planet.osm komplett neu baue. Weiterhin gilt: Kritik, Wünsche, etc. immer herzlich willkommen. Gruß, Lars ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Experimentelles neues 'TagWatch' bzw. Tagstatistiken
2009/3/29 Lars Francke lars.fran...@gmail.com: Moin! Ja wie man sieht ist da bei den Anwendungen noch nichts losich fand die Idee aber gut. Zum Teil wird das ja schon auf der MapFeatures-Seite bzw. im TagWatch verwendet aber ich denke das ist ausbaufähig. Ich konzentriere mich aber erstmal auf den Tags-Teil. Ich schlage für die verschiedenen Anwendungen je eine Kategorie im Wiki vor TagsUsedBy:appname und alle Tag:name -Seiten die diese Anwendung spricht in diese Kategorie packen. Somit wäre das a) nur einmal und am richtigen Ort dokumentiert b) sieht jeder, wenn er sich im Wiki über ein Tag informiert wer damit etwas anfangen kann. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM bei Stiftung Warentest erwähnt
Im aktuellen Heft der Stiftung Warentest werden GPS-Empfänger getestet, dabei wird auch OSM als Quelle für kostenloses Kartenmaterial erwähnt... Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bürgersteige und Eigenschaften
Am 29. März 2009 12:28 schrieb Astrid Müller astridmuelle...@gmx.de: Hallo Martin, oder für einen 25 cm hohen Bordstein: border=curb border:height=0,25 oder für eine Mauer border=wall border:width=0,5 border:height=5 Bordsteine über den Schlüssel border zu taggen finde ich eine gute Idee und besser als mit dem Tag Sloped_curb=yes. Somit ist der Schlüssel allgemeiner gehalten und man hat die Möglichkeit einzelne Werte wie Höhe und Breite hinzu zu fügen. Danke. Weitere Kommentare zum Vorschlag Übergangs-/Border-relation (s.Post oben)? Ist sowas einfach auswertbar mit Routing-Programmen? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Zugang/Haupteingang Freibad etc.
Hallo, ich frage mich gerade wie ich ein Freibad _so_ taggen soll, dass einerseits die gesamte Fläche (ein Straßenblock) als solches gerendert wird (also als Area), andererseits die Routingalgorithmen den Besucher zum Haupteingang und nicht an die nächstgelegene Stelle des Zaunes lotsen? Zusätzlich einen Wegpunkt/POI am Haupteingang setzen? Das Adressen-Tag allein scheint mir nicht ausreichend, dazu müsste der Nutzer ja die Adresse des Schwimmbads kennen. Danke - und auf eine baldige Freibadzeit ;) Gruß Ralf ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugang/Haupteingang Freibad etc.
Am 29. März 2009 18:16 schrieb RalfGesellensetter r...@gmx.de: Hallo, ich frage mich gerade wie ich ein Freibad _so_ taggen soll, dass einerseits die gesamte Fläche (ein Straßenblock) als solches gerendert wird (also als Area), andererseits die Routingalgorithmen den Besucher zum Haupteingang und nicht an die nächstgelegene Stelle des Zaunes lotsen? Zusätzlich einen Wegpunkt/POI am Haupteingang setzen? Das Adressen-Tag allein scheint mir nicht ausreichend, dazu müsste der Nutzer ja die Adresse des Schwimmbads kennen. Danke - und auf eine baldige Freibadzeit ;) Gruß Ralf mittlerweile gibt es ja barrier=entrance, das man z.B. in Zäunen und Mauern verwenden kann. Das könnte man auch allgemein verwenden, und z.B. mit mkgmap an den Eingängen jeweils automatisch einen POI für die Navigation erstellen lassen. Feste POIs (Nodes) zusätzlich zu Flächen habe ich früher gemacht, aber das ist nicht sonderlich überzeugend, funktioniert dann zwar in der Navi-Suche, aber sieht beim Rendern schlecht aus (doppelte Namen) und ist auch datenstrukturmäßig nicht gut. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zensiertes Gebiet?
Am 28. März 2009 13:00 schrieb RalfGesellensetter r...@gmx.de: Am Donnerstag 26 März 2009 schrieb Detlef Reichl: Das Gebiet ist markiert als military=danger_area Da drin würde ich auch nicht unbedingt mappen wollen. Okay, sieht so nur seltsam aus -- vielleicht sollte die Fläche einfach (oliv?)grün schraffiert werden? ich bleibe dabei: Umrisslinie (evtl. auch Gebiet schraffiert), aber das eigentliche Gebiet nicht (vollständig) überdecken, d.h. WENN es dort einmal Wege, Wälder etc. in OSM geben sollte, dann sollte man die auch erkennen können. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Kaianlage - Dock
Am 28. März 2009 16:09 schrieb Markus liste12a4...@gmx.de: Hallo Peter, Woher hast Du den Begriff type=swimdock? Das war mein Trivial-Englisch. Einfacher wäre: type=# dann könnte man die sprachspezifischen Varianten in der DB ablegen. Leo meint zu Schwimmdock floating dock. Wikipedia ist auch immer ein guter Ansatzpunkt für die Recherche von Fachwörtern: Dock may refer to: In transportation * Dock (maritime), an area of water for building or repairing or loading and unloading ships or ferries. See also: o Dry dock, a narrow basin that can be flooded and drained to allow a load to come to rest on a dry platform o Impounded dock, a large basin in which the water is impounded by gates or locks allowing ships to remain afloat at low tide, see Docklands o Ferry slip, a specialized docking facility that receives a ferryboat o Harbor o Jetty o Marina o Pier, a raised walkway over water, supported by widely spread piles or pillars o Pontoon, a buoyant device, used to support docks or floating bridges o Quay o Wharf, a fixed platform, commonly on pilings, where ships are loaded and unloaded * Loading dock or Cargo bay, an unloading area for trucks to deliver cargo * Space rendezvous, if it includes docking * Stevedore, a worker who loads and unloads ships, also known as a docker or longshoreman Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sperrgebiet (Re: Zensiertes Gebiet?)
Am 28. März 2009 18:27 schrieb Toni Erdmann toni.erdm...@web.de: Johann H. Addicks schrieb: RalfGesellensetter schrieb: Okay, sieht so nur seltsam aus -- vielleicht sollte die Fläche einfach (oliv?)grün schraffiert werden? Warum oliv? Grün haben wir doch nun wirklich schon mehr als reichlich auf der Karte. Shell hat dafür transparente, breite diagonale Schraffur in Violett. Mmh! Verstehe das Problem nicht ganz. military=danger_area wird doch schon seit längerem gerendered. Man muss es allerdings auch entsprechend taggen. Mapnik http://openstreetmap.org/?lat=48.03797lon=11.7367zoom=15layers=B000FTF Das Problem ist, dass man dadurch sämtliche Informationen zur Oberfläche (Befestigt, Wald, See) verdeckt. Ein fetter Umriss oder eine Schraffur sind m.E. einem Filling unbedingt vorzuziehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Zugang/Haupteingang Freibad etc.
RalfGesellensetter schrieb: Hallo, ich frage mich gerade wie ich ein Freibad _so_ taggen soll, dass einerseits die gesamte Fläche (ein Straßenblock) als solches gerendert wird (also als Area), andererseits die Routingalgorithmen den Besucher zum Haupteingang und nicht an die nächstgelegene Stelle des Zaunes lotsen? Zusätzlich einen Wegpunkt/POI am Haupteingang setzen? Das Adressen-Tag allein scheint mir nicht ausreichend, dazu müsste der Nutzer ja die Adresse des Schwimmbads kennen. Das könnte vielleicht helfen: http://wiki.openstreetmap.org/wiki/Relations/Proposed/Site http://wiki.openstreetmap.org/wiki/Relations/Proposed/Buildings Grüße René ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sperrgebiet (Re: Zensiertes Gebiet?)
Martin Koppenhoefer schrieb: Am 28. März 2009 18:27 schrieb Toni Erdmann toni.erdm...@web.de: Johann H. Addicks schrieb: RalfGesellensetter schrieb: Okay, sieht so nur seltsam aus -- vielleicht sollte die Fläche einfach (oliv?)grün schraffiert werden? Warum oliv? Grün haben wir doch nun wirklich schon mehr als reichlich auf der Karte. Shell hat dafür transparente, breite diagonale Schraffur in Violett. Mmh! Verstehe das Problem nicht ganz. military=danger_area wird doch schon seit längerem gerendered. Man muss es allerdings auch entsprechend taggen. Mapnik http://openstreetmap.org/?lat=48.03797lon=11.7367zoom=15layers=B000FTF Das Problem ist, dass man dadurch sämtliche Informationen zur Oberfläche (Befestigt, Wald, See) verdeckt. Ein fetter Umriss oder eine Schraffur sind m.E. einem Filling unbedingt vorzuziehen. das geht doch auch ... Mapnik http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=B000FTF Osmarender http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=0B00FTF Und Seen, Wald, ... (zur Not) als 'inner' eines Multipolygon. Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sperrgebiet (Re: Zensiertes Gebiet?)
Am 29. März 2009 19:05 schrieb Toni Erdmann toni.erdm...@web.de: Das Problem ist, dass man dadurch sämtliche Informationen zur Oberfläche (Befestigt, Wald, See) verdeckt. Ein fetter Umriss oder eine Schraffur sind m.E. einem Filling unbedingt vorzuziehen. das geht doch auch ... Mapnik http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=B000FTF Osmarender http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=0B00FTF es geht nicht, bzw. nur solange, bis der Ort gemappt ist, d.h., wenn alles Wald ist, oder alles ist _irgendwas_ (also z.B. befestigt, Wald, See, ...) dann ist es bei der derzeitigen Darstellung immer ein entweder/oder, mit Umriss/Schraffur (wie allgemein üblich in Karten) stellt sich das Problem nicht. Und Seen, Wald, ... (zur Not) als 'inner' eines Multipolygon. es geht eben nicht, Du schreibst ja selbst zur Not, mit einem Multipolygon schließt Du die Flächen aus dem Gebiet aus. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Google Maps hat nachgerüstet
Am 27. März 2009 13:36 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Hermann Schwaerzler schrieb: Hmm ... lass mal überlegen... die gleichen fakten etwa gleich genau vermessen? oder was meinst du? http://sautter.com/map/?zoom=17lat=48.14293lon=11.58007layers=B000TFFF Die Wege im Hofgarten sind so identisch, dass man auf eine gemeinsame Datenquelle schließen könnte. Sehe ich nicht so. Sie sind ja leicht unterschiedlich (liegen nicht immer 100% übereinander), und solche historischen, symmetrischen und regelmäßigen Anlagen sind ziemlich einfach abzumalen (und da es rechte Winkel, Geraden und Kreise sind, wird dem Mapper auch nicht viel Abstraktionsvermögen abverlangt), da ist es doch klar, dass auch ein ähnliches Bild rauskommt. Abgesehen davon sind in OSM mehr Wege drin, daher zielt der Vorwurf wohl eher ein die andere Richtung, aber auch das halte ich nicht für haltbar. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] (kein Betreff)
barrier=entrance ist irgendwie widersprüchlich... barrier:access=yes mmh Wie werden denn Gebäudeeingänge gekennzeichnet? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Vielleicht ei Tag für Betrieb durch Bauarbeiten eingeschränkt? Railway=Construction ? Ist zwar eigentlich für den Aufbau, könnte doch hier aber auch passen, oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (kein Betreff)
Am 29. März 2009 19:36 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: barrier=entrance ist irgendwie widersprüchlich... Habe ich auch mal gedacht, sehe ich aber mittlerweile nicht mehr so: a. der Eingang/Durchgang durch die Barriere sollte m.E. auch logisch zur Barriere gehören. b. die meisten Eingänge sind ja auch Barrieren, solange sie geschlossen sind. barrier:access=yes mmh macht die Sache m.E. nur unnötig komplizierter. Manche Züge sind halt schon abgefahren, da kann man nicht mehr einsteigen ;-), bin z.B. auch nicht restlos glücklich mit barrier=city_wall, weil man damit eine der bedeutsamsten Strukturen für die Stadt (für die Entwicklung der Form wichtiger als die meisten Straßen) mit so nem Zeugs wie Gartenzäunen und Hecken in Verbindung bringt (und eben nur einen Charakter herausstellt), aber hey, man gewöhnt sich an alles. Wie werden denn Gebäudeeingänge gekennzeichnet? barrier=entrance? gibt auch die entrance=yes Idee auf Nodes. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
2009/3/29 Tobias Wendorff tobias.wendo...@uni-dortmund.de: Mal rein hypothetisch: Gäbe es eine Anwendung, die Navigation mit OSM-Daten konkurrenzfähig anbieten könnte? Die bisherigen Navigationsungen laufen entweder nicht auf einem PNA oder sind schlucht von der Bedienung grottig. Dann schreib Feature-Requests und mach Vorschläge, damit unsere selbst geschriebenen Navis besser werden. Was ist denn grottig und wie wäre es besser? PS: Ich suche ein neues GPS. Momentan habe ich ein Auge auf das BT-Q1300 (-165dBm, 105eur) geworfen, aber das kann kein TMC. Anforderungen: * weniger als -159dBm, besser -165dBm * mit Kabel oder Kabel alternativ zu Bluetooth nutzbar * TMC (um TMC-Unterstzützung für Traveling Salesman zu programmieren) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Aber es gibt ja eigentlich keinen Hinweis auf die weiterbestehende Nutzungsmöglichkeit. railway:tracks=2 Was ist, wenn nur ein Track construckted wird? railway:track:left = construction ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
Tobias Wendorff schrieb: Mal rein hypothetisch: Gäbe es eine Anwendung, die Navigation mit OSM-Daten konkurrenzfähig anbieten könnte? Die bisherigen Navigationsungen laufen entweder nicht auf einem PNA oder sind schlucht von der Bedienung grottig. Worauf willst Du hinaus? Die OSM-Daten sind noch zu lückenhaft, insbesondere in Bezug auf Routingfähigkeit um konkurrenzfähig gegen ein kommerzielles Produkt mit Navteq/Teleatlasdaten zu sein. Aber auf Geräten wie den Garmins die beides darstellen können sind sie schon heute eine oftmals hilfreiche Ergänzung. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gebäude Wichtigkeit/Höhe/Form (wa s: Google Maps hat nachgerüstet)
Am 27. März 2009 13:37 schrieb Johann H. Addicks addi...@gmx.net: Am 26. März 2009 22:31 schrieb Ulf Möller use...@ulfm.de: Die Gebäudehöhen sind eigentlich gar nicht so detailliert erfasst, aber machen Eindruck... findest Du? Ohne Dachformen und dermaßen grob kann man m.E. auch gut darauf verzichten. Wenn wir das Proposal von 2007 bezüglich des Building-Tags (mehr als nur 'building=yes') nutzen würden, dazu noch Etagenanzahl/Gebäudehöhe plus Dachform und Ausrichtung, dann würden sich sicher auch die Bonner mit ihrem OSM-Flugsimulator freuen. Siehe: http://wiki.openstreetmap.org/wiki/Proposed_features/Building und http://wiki.openstreetmap.org/wiki/Proposed_features/Building_attributes Für Dachform und -ausrichtung gibts da doch noch gar keine Vorschläge, oder täusche ich mich? Als Architekt finde ich auch die 3 vorgeschlagenen Grundformen ein bisschen dünn: Pyramide, Turm und Dom. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Suche TMC-Empfänger
Hallo, kennt jemand einen günstigen, TMC-empfänger der sich an einen typischen Bluetooth+USB -Laptop anschließen lässt? Irgendwas, was in NMEA eingebettetes TMC spricht wäre super. Da ich mir gleichzeitig einen 5Hz -165dBm GPS-Empfänger zulegen will wäre ein Gerät was beides in dieser Empfindlichkeit kann super aber bisher habe ich nichts jenseits von -159dBm 1Hz mit TMC gefunden. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
Wenn ich mir Oberfläche von kommerziellen Navis anschaue, finde ich kaum Parallelen zu OSM Software. Ich weiß nicht, was man GUI-technisch mit JAVA machen kann. Navis haben ja z.B. Grafikeffekte, wenn man mit dem Pointer oder dem Finger auf einen Buchstabe drückt. Das ist zwar alles KlickiBunti, aber es vereinfacht die Eingabe und den Spaß bei der Nutzung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Fwd: Bushaltestellen vs. Recyclingstellen
Am 27. März 2009 13:37 schrieb Tobias Wendorff Martin Koppenhoefer schrieb: das meiste wäre wohl eher schwieriger (mapping) bis unmöglich (routing) - wenn sie _nur_ Flächen wären. Wenn sie beides wären (analog Flüssen), dann könnte man (abgesehen vom Aufwand) das Beste aus beiden Welten haben. Bei den Plätzen habe ich schon mal angefangen ;-) In ATKIS Co. findet man daher Fahrbahnflächen und Fahrbahnen ... ja, das wäre genau das, was wir evtl. auf Dauer auch haben sollten. Aber wo siehst Du das Problem aus einer Fläche eine Mittellinie zu erzeugen? Jedes CAD-Programm kann das. hä? Was sind denn Deine Parameter, um aus der Fläche eine Mittellinie zu erzeugen? Ich kann das mir ehrlich gesagt nicht vorstellen und kenne auch keine CAD-Funktion, die so was macht. Du meintest Mittellinie und nicht z.B. Schwerpunkt? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Sperrgebiet (Re: Zensiertes Gebiet?)
Martin Koppenhoefer schrieb: Am 29. März 2009 19:05 schrieb Toni Erdmann toni.erdm...@web.de: Das Problem ist, dass man dadurch sämtliche Informationen zur Oberfläche (Befestigt, Wald, See) verdeckt. Ein fetter Umriss oder eine Schraffur sind m.E. einem Filling unbedingt vorzuziehen. das geht doch auch ... Mapnik http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=B000FTF Osmarender http://openstreetmap.org/?lat=48.06852lon=11.64764zoom=17layers=0B00FTF es geht nicht, bzw. nur solange, bis der Ort gemappt ist, d.h., wenn alles Wald ist, oder alles ist _irgendwas_ (also z.B. befestigt, Wald, See, ...) dann ist es bei der derzeitigen Darstellung immer ein entweder/oder, mit Umriss/Schraffur (wie allgemein üblich in Karten) stellt sich das Problem nicht. Und Seen, Wald, ... (zur Not) als 'inner' eines Multipolygon. es geht eben nicht, Du schreibst ja selbst zur Not, mit einem Multipolygon schließt Du die Flächen aus dem Gebiet aus. Groschen fällt Pfennig-weise. Jetzt habe ich das Thema verstanden. Klar, bei meinem ersten Beispiel besteht ehemalige größte Munitionsdepot Süddeutschlands natürlich überwiegend aus Wald, und der sollte als ebenfalls gesperrtes Gebiet erscheinen, und nicht als Wald. Das würde aber entweder eine Schrafur mit transparentem Hintergrund, oder eine Vielzahl von Objekten (Wald, See, Straße, Gebäude, ...) in zweierlei Ausführung (normal, schraffiert) bedeuten. Und: diese Aufzählung wäre wohl nie ganz vollzählig. Gruß, Toni ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fwd: Bushaltestellen vs. Recyclingstellen
Wenn du ein Rechteck hast, von dem zwri parallele Seiten nivht gleich lang sind, fällst du die Mittelsenkrechte der kürzeren Seite, bis sie die gegenüberliegende schneidet. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Habe hier noch ein paar Details gefunden: http://www.deutschebahn.com/site/bahn/de/unternehmen/presse/verkehrsmeldungen/bw/bw20090302,variant=pdf.pdf Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Mikro-Wohngebiete oder Gärten?
Ich habe bisher geschlossene Wohngebiete als landuse=residential erfaßt. Dabei habe ich den Außenrand auf die Außengrenze der Gärten der Häuser gelegt. Sieht in sich stimmig aus und entspricht auch dem Usus in den topographischen Karten des LVermA. Was aber mache ich in Gegenden, die landwirtschaftlich geprägt sind, aber von mehr oder weniger dichter Wohnbebauung durchsetzt? Immer wieder tauchen Bauernhöfe auf; findet dort noch eine Restlandwirtschaft statt, habe ich das Hofgrundstück mit landuse=farmyard getaggt. Viele Bauernhöfe sind aber nur noch Wohnhäuser, das ehemalige Hofgelände ist jetzt ein großer Garten. Bisher verwende ich dafür leisure=garden, mit der Idee, später beim Gebäudemapping die Häuser hineinzusetzen. Darüber hinaus gibt es auch freistehende Wohnhäuser neueren Datums, die nie Bauernhöfe waren, aber trotzdem einzeln oder zu zweit oder dritt stehen; rundherum landwirtschaftliche Nutzflächen und Wiesen. Ab wann sollte ich diese Grundstücke mit landuse=residential taggen? Schon beim einzelnen Wohnhaus mit Garten, wie es die topograph. Karte 1:25.000 macht? Erst bei Ansammlungen von mehreren Wohngrundstücken (gefühlt ist meine Grenze bisher bei mehr als 4 oder 5 Häusern)? __ Verschicken Sie SMS direkt vom Postfach aus - in alle deutschen und viele ausländische Netze zum gleichen Preis! https://produkte.web.de/webde_sms/sms ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Marcus Wolschon schrieb: Hallo, kennt jemand einen günstigen, TMC-empfänger der sich an einen typischen Bluetooth+USB -Laptop anschließen lässt? Irgendwas, was in NMEA eingebettetes TMC spricht wäre super. Da ich mir gleichzeitig einen 5Hz -165dBm GPS-Empfänger zulegen will wäre ein Gerät was beides in dieser Empfindlichkeit kann super aber bisher habe ich nichts jenseits von -159dBm 1Hz mit TMC gefunden. Hab mir gerade einen Royaltek RTG-2000 gekauft, wollte auch mal ein bisschen mit TMC rumspielen. Keine Ahnung was das Ding für eine Empfindlichkeit hat. Ne (zumindest teilweise?) Beschreibung zu dem TMC Protokoll von den Royaltek Dingern findest du unter: http://www.gpspassion.com/forumsen/post.asp?method=ReplyQuoteREPLY_ID=709654TOPIC_ID=17275FORUM_ID=79 Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Bahnstreckenrenovierung
Ja, es gibt noch bessere Quellen. Aber die Lizenz pasdt mal wieder nicht, DB will nicht komplett mit uns kooperieren und die Rechtsprechung zur Nennung von Presseberichten ist eindeutig. Aber es bleibt ja jedem selbst überlassen... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Marina
Hallo alle, vielleicht keine ganz neue Frage: was genau bezeichnet leisure=marina? Umfasst das nur die eigentlichen Liegeplätze (= Wasser + Stege), wie es die blaue Signatur in JOSM andeutet (wird allerdings nicht gerendert, außer man gibt auch natural=water dazu), oder die gesamte Anlage (inkl. Versorgungsanlagen, Trockenliegeplätzen etc.)? Laut http://wiki.openstreetmap.org/wiki/DE:Segler1#Hafenplan ist es mir auch nicht 100% klar (Landratte ;-). Würde man das eingezäunte Gelände (an einem Fluss) dann als landuse=harbour bezeichnen können? LG Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Studierende haben an unserer Hochschule ein TMC-Projekt gemacht und dazu einen NL-409TE - RDS/TMC PDA Empfänger http://www.navilock.de/produkte/gruppen/3/Kabel_Empfaenger/61493_NL-409TE.html verwendet. Das Decodieren der NMEA / TMC-Messages war einiger Aufwand, aber über das Gerät gab es, soweit mir bekannt, niochts zu klagen. Gruß Franz-Josef Marcus Wolschon schrieb: Hallo, kennt jemand einen günstigen, TMC-empfänger der sich an einen typischen Bluetooth+USB -Laptop anschließen lässt? Irgendwas, was in NMEA eingebettetes TMC spricht wäre super. Da ich mir gleichzeitig einen 5Hz -165dBm GPS-Empfänger zulegen will wäre ein Gerät was beides in dieser Empfindlichkeit kann super aber bisher habe ich nichts jenseits von -159dBm 1Hz mit TMC gefunden. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de begin:vcard fn:Dr. Franz-Josef Behr n:Behr;Franz-Josef org:Stuttgart University of Applied Sciences (SUAS);Faculty of Geomatics, Computer Science and Mathematics adr;quoted-printable:;;Schellingstra=C3=9Fe 24, ;Stuttgart;;D-70174;Germany title:Prof. tel;work:+49) 711/8926-2606 tel;home:+49 (0)721 / 453980-1 url:http://www.hft-stuttgart.de/ version:2.1 end:vcard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Jan-Benedict hat auch in Sachen TMC experimentiert, allerdings direkt aus dem digital Stream. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Danke Ulf und Dr. Joseph, ich habe den Empfänger noch bei GPS-Haus zu 70 statt 100eur gefunden. http://www.gps-haus.de/GPS-Empfaenger/Kabel-GPS/Navilock-NL-409TE-RDS-TMC-Kabel-GPS-Maus::4594.html Dr Joseph: Können Sie mir sagen, was dieser 6-poliger Navilock PDA Anschlussstecker wäre? Sieht für mich nach PS/2 aus aber kann auch irgendwas komplett eigenes sein. Ulf: Ich schätze da werde ich viel zusammensuchen und experimentieren müssen bis ich TMC dekodieren kann. Aber vielen Dank für den Link. Dr Joseph: Kann man eure Software irgendwo sehen? Marcus http://wiki.openstreetmap.org/wiki/Traveling_salesman ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
Tobias Wendorff schrieb: Gäbe es eine Anwendung, die Navigation mit OSM-Daten konkurrenzfähig anbieten könnte? Es hat sich zwar schon eine Menge getan in letzter Zeit, aber es gibt (jedenfalls soviel ich weiss) noch keine Anwendung, die es mit den kommerziellen aufnehmen kann. Ausserdem ist das Kartenmatierial m.E. noch zu lueckenhaft (Abbiegevorschriften, usw.) um eine wirklich gute Navigation zu ermoeglichen. Die bisherigen Navigationsungen laufen entweder nicht auf einem PNA oder sind schlucht von der Bedienung grottig. Nunja, wenn jemand eines oder mehrere Entwicklerjahre (zu den ueblichen Stundensaetzen) spendiert, bekommt er auch eine funktionierende oder sogar schoene Loesung. Bis dahin muss man mit dem Vorlieb nehmen, was die Leute in ihrer Freizeit produzieren. Gruesse, Julian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
On Sun, Mar 29, 2009 at 09:23:11PM +0200, Tobias Wendorff wrote: Subject: Re: [Talk-de] Suche TMC-Empfänger Jan-Benedict hat auch in Sachen TMC experimentiert, allerdings direkt aus dem digital Stream. Ja - ich habe da mal angefangen was zu stricken um aus einem DVB Stream das RDS und schlussendlich das TMC zu holen - Die Idee war mit einer DVB Karte alle Bundeslaender abzugreifen. Der code ist hier mit dem meisten zeugs von Jan Benedict denke ich: git clone git://hydra.gt.owl.de/rdsdump.git 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] OSM- Navi-Oberflächen war:OSM bei Stif tung Warentest erwähnt -
2009/3/29 Tobias Wendorff tobias.wendo...@uni-dortmund.de: Wenn ich mir Oberfläche von kommerziellen Navis anschaue, finde ich kaum Parallelen zu OSM Software. Ich weiß nicht, was man GUI-technisch mit JAVA machen kann. Navis haben ja z.B. Grafikeffekte, wenn man mit dem Pointer oder dem Finger auf einen Buchstabe drückt. Da kann man mit Java seid Java2D und Java3D praktisch alles machen. Der Unterschied ist eher, dass ich z.B. momentan nur für Netbooks schreibe. So wie man Navis vor Aufkommen der Navi-Geräte immer benutzt hat und wie ich das noch gewohnt bin. Einfach aus dem praktischen Grund, dass man keine Navi-Geräte findet in die man eigene Software rein kriegt und selbst wenn, ist das irgendeine extrem eingeschränkte Windows-Mobil -Platform. Nach Version 1.0 in 3 Wochen wollen wir uns bei Traveling Salesman mit coolen Transparenz-Effekten und weichem Aufklappen der Routing-Anweisungen (oben) und Adress-Suche(links) beschäftigen. Leider bin ich kein guter Graphiker aber da könnten wir was richtig cooles hinkriegen. Für Version 1.0 war es halt erstmal wichtig ein zuverlässig funktionierendes Navi zu programmieren. Vorschläge in Form von Anregungen oder Skizzen gerne willkommen. Wahlweise im Forum: http://apps.sourceforge.net/phpbb/travelingsales/index.php oder im Wiki http://apps.sourceforge.net/mediawiki/travelingsales/ ließe sich sowas gut sammeln und schrittweise verbessern. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
2009/3/29 Doru Julian Bugariu j.buga...@wad.org: Tobias Wendorff schrieb: Gäbe es eine Anwendung, die Navigation mit OSM-Daten konkurrenzfähig anbieten könnte? Es hat sich zwar schon eine Menge getan in letzter Zeit, aber es gibt (jedenfalls soviel ich weiss) noch keine Anwendung, die es mit den kommerziellen aufnehmen kann. Ausserdem ist das Kartenmatierial m.E. noch zu lueckenhaft (Abbiegevorschriften, usw.) um eine wirklich gute Navigation zu ermoeglichen. Die noch nicht soo gute Qualität des Kartenmaterials halte ich a) für keine Ausrede bei der Usability zurück zu bleiben weil sie sich b) jeden Tag verbessert und c) für das übliche führe einen halbwegs denkbefähigten Fahrer von A nach B schon ausreicht. Die bisherigen Navigationsungen laufen entweder nicht auf einem PNA oder sind schlucht von der Bedienung grottig. Nunja, wenn jemand eines oder mehrere Entwicklerjahre (zu den ueblichen Stundensaetzen) spendiert, bekommt er auch eine funktionierende oder sogar schoene Loesung. Bis dahin muss man mit dem Vorlieb nehmen, was die Leute in ihrer Freizeit produzieren. Hier bemängle ich definitiv das Ausbleiben von Bug-Reports und Verbesserungs- Vorschlägen. Wenn keiner Vorschläge macht, wie es besser aussehen könnte dann wird sich da auch nichts tun. Selbst wenn die wenigen Entwickler gerade Zeit dafür haben. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
2009/3/29 Florian Lohoff f...@rfc822.org: On Sun, Mar 29, 2009 at 09:23:11PM +0200, Tobias Wendorff wrote: Subject: Re: [Talk-de] Suche TMC-Empfänger Jan-Benedict hat auch in Sachen TMC experimentiert, allerdings direkt aus dem digital Stream. Ja - ich habe da mal angefangen was zu stricken um aus einem DVB Stream das RDS und schlussendlich das TMC zu holen - Die Idee war mit einer DVB Karte alle Bundeslaender abzugreifen. Der code ist hier mit dem meisten zeugs von Jan Benedict denke ich: git clone git://hydra.gt.owl.de/rdsdump.git Connection refused komme ich an den Code auch irgendwie anders ran? Die Idee mit DVB wäre genial. Da könnte man die Daten online z.B. als diff zu OSM-XML-Karten im selben Format wie die stündlichen Diffs bereitstellen. (Sperrung= Füge ein barrier=gesperrt ein, Stau= füge ein maxspeed=0.5 oder so ein.) Das wäre von jeder Software, die OSM kennt relativ einfach verwertbar. Marcus Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Marcus Wolschon schrieb: Danke Ulf und Dr. Joseph, ich habe den Empfänger noch bei GPS-Haus zu 70 statt 100eur gefunden. http://www.gps-haus.de/GPS-Empfaenger/Kabel-GPS/Navilock-NL-409TE-RDS-TMC-Kabel-GPS-Maus::4594.html Dr Joseph: Können Sie mir sagen, was dieser 6-poliger Navilock PDA Anschlussstecker wäre? Sieht für mich nach PS/2 aus aber kann auch irgendwas komplett eigenes sein. Ulf: Ich schätze da werde ich viel zusammensuchen und experimentieren müssen bis ich TMC dekodieren kann. Aber vielen Dank für den Link. TMC ist vom Protokoll her kein Teufelszeug, ich schätze das man das Protokoll recht schnell hinbekommen kann. Das Problem ist, daß du bei TMC die Location Codes brauchst. Im TMC steht nur z.B. 0x1412 und du mußt dann wissen welche Position das eigentlich genau sein soll. Für Deutschland verwaltet das die BASt, die geben die notwendige Location Table (lt. WP ca. 40200) aber nicht frei raus, also wohl erstmal nix mit Open Source :-( http://de.wikipedia.org/wiki/Traffic_Message_Channel#Deutschland Die einzige Möglichkeit wäre Reverse Engineering, also Verkehrsfunk mithören und entsprechend die Codes rausfinden. Inwieweit das rechtlich Koscher ist kann ich aber auch nicht beurteilen ... Gruß, ULFL ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
2009/3/29 Ulf Lamping ulf.lamp...@googlemail.com: TMC ist vom Protokoll her kein Teufelszeug, ich schätze das man das Protokoll recht schnell hinbekommen kann. Das Problem ist, daß du bei TMC die Location Codes brauchst. Im TMC steht nur z.B. 0x1412 und du mußt dann wissen welche Position das eigentlich genau sein soll. Für Deutschland verwaltet das die BASt, die geben die notwendige Location Table (lt. WP ca. 40200) aber nicht frei raus, also wohl erstmal nix mit Open Source :-( http://de.wikipedia.org/wiki/Traffic_Message_Channel#Deutschland Die einzige Möglichkeit wäre Reverse Engineering, also Verkehrsfunk mithören und entsprechend die Codes rausfinden. Inwieweit das rechtlich Koscher ist kann ich aber auch nicht beurteilen ... Hallo Ulf, das mit den Location-Codes ist mir bekannt. Es scheinen aber einige Listen für DE in Umlauf zu sein (viel Suchen) und für andere Länder gibt es die Listen frei. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Kann dir sicher morgen helfen. Allerdings erlauben das dir Nutzungsrechte sicher nicht, da das BASt da ein Quasimonopol drauf hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Suche TMC-Empfänger
Hallo Marcus Wolschon wrote: Dr Joseph: Können Sie mir sagen, was dieser 6-poliger Navilock PDA Anschlussstecker wäre? Sieht für mich nach PS/2 aus aber kann auch irgendwas komplett eigenes sein. physikalisch ist das ein PS/2 Stecker, ich verwende ein normales Tastatur-Verlängerungskabel für die GPS-Maus (Navilock NL-303P) Die Pinbelegung ist anders als bei einer PS/2 Tastatur/Maus: http://www.navilock.de/support/files/listfiles.php?action=getFileid=31filename=nl-41d285c449d9acfilename=BR-305+Pin+Belegung.pdf http://www.mydarc.de/dl4ml/technik/innenleben_nl-303p/innenleben_nl-303p.html Von Navilock gibts Adapter für USB, Seriell und PDAs Frank ___ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM bei Stiftung Warentest erwähnt
Marcus Wolschon schrieb: Die bisherigen Navigationsungen laufen entweder nicht auf einem PNA oder sind schlucht von der Bedienung grottig. Nunja, wenn jemand eines oder mehrere Entwicklerjahre (zu den ueblichen Stundensaetzen) spendiert, bekommt er auch eine funktionierende oder sogar schoene Loesung. Bis dahin muss man mit dem Vorlieb nehmen, was die Leute in ihrer Freizeit produzieren. Hier bemängle ich definitiv das Ausbleiben von Bug-Reports und Verbesserungs- Vorschlägen. Wenn keiner Vorschläge macht, wie es besser aussehen könnte dann wird sich da auch nichts tun. Selbst wenn die wenigen Entwickler gerade Zeit dafür haben. Also gut, wegen Travelling Salesman: 1.) Übersetzungen bitte vollständig 2.) Fachbegriffe vermeiden - was ist eine Planar Map? 3.) Ünnotige Optionen aus dem Wizard nehmen - gpsd Emulation für JOSM - möglichst automatische Erkennung des GPS 4.) Visuelle Gruppierung der Optionen - die erste Seite des Wizards ist grausam 5.) Bei längeren Operationen ProgressBar - *niemals* den User im unklaren lassen was gerade passiert Das waren die Punkte, die mir nach etwa 5 Minuten aufgefallen sind ... Gruß, ULFL P.S: Eine gute Einführung wäre z.B.: http://library.gnome.org/devel/hig-book/stable/ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
