[talk-ph] OpenStreetMap Philippines Community Survey
Sending this to the list for reference, sent it out to all mailing list contributors since Dec 2009 to get their opinion on this current topic. - Hi, I am contacting you in regards to OpenStreetMap in the Philippines. In case you don't know me yet, my name is Andre Marcelo-Tanner, I am from Enthropia Inc., a company in the Philippines which is helping OSM Philippines grow. Since we found that you are an active contributor to OSM in the Philippines, we wanted to get your opinion as part of the community on a very important issue: The formation of a formal legal entity to represent OpenStreetMap in the Philippines There is some starting discussion on the mailing list already at http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000877.html http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000879.html http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000883.html We would greatly appreciate comments, even a simple yes or no from each member of the community as we know this is a community project and thus the community should always have a say in everything. Please send your replies to talk-ph@openstreetmap.org so that the discussion will be public and everyone can join in. Thank you very much for your time, Andre Marcelo-Tanner Enthropia Inc. ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
[talk-ph] OpenStreetMap Philippines Community Survey
Thanks Rally for your response, I'll post it to the group also so we can have a public view of opinions. Regards, Andre Rally de Leon wrote: I share the opinion of Eugene Villar. I'm supporting the move to formalize osm-ph. On Tue, May 26, 2009 at 2:40 AM, Andre Marcelo-Tanner an...@enthropia.com mailto:an...@enthropia.com wrote: Hi, I am contacting you in regards to OpenStreetMap in the Philippines. In case you don't know me yet, my name is Andre Marcelo-Tanner, I am from Enthropia Inc., a company in the Philippines which is helping OSM Philippines grow. Since we found that you are an active contributor to OSM in the Philippines, we wanted to get your opinion as part of the community on a very important issue: The formation of a formal legal entity to represent OpenStreetMap in the Philippines There is some starting discussion on the mailing list already at http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000877.html http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000879.html http://lists.openstreetmap.org/pipermail/talk-ph/2009-May/000883.html We would greatly appreciate comments, even a simple yes or no from each member of the community as we know this is a community project and thus the community should always have a say in everything. Please send your replies to talk-ph@openstreetmap.org mailto:talk-ph@openstreetmap.org so that the discussion will be public and everyone can join in. Thank you very much for your time, Andre Marcelo-Tanner Enthropia Inc. ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] New Proposed Feature: Tagging the age and duration of existence of features
Peter Dörrie wrote: Hi everybody, I made a proposal for tagging the 4th dimension. Hope you like it ;) http://wiki.openstreetmap.org/wiki/Proposed_features/4th_Dimension I've put a note on that talk page, but I think this needs to be opened up a bit, since it IS quite an important area. Should the database ONLY contain currently existing mapping information? That is the area that is getting a 'no' on the 4th_Dimension page although it is not actually WORDED in that way! (Hence my comment there about a poll not being appropriate - it's the wrong question?) There are two types of history being generated as we go along, the history of when information is added and updated, but also now, the history of CHANGES to an area, which from my own point of view is MORE important than simply mapping the current situation. Roads and other POI that exist in today's map have been recorded, and the information is accurate. Should we then simply wipe that history because an area has been flattened and remodelled? Surely it is not beyond the whit of man to simply hide that material from those users who do not want to see it - deleting it just seems like an act of vandalism :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Potlatch 1.0
On 24 May 2009, at 14:22, OJ W wrote: On Sun, May 24, 2009 at 11:19 AM, John McKerrell j...@mckerrell.net wrote: I thought people were sometimes using similar values to the landuse tags, i.e. building=commercial building=retail ? or office, apartments, mixed_use ... currently it looks like the vast majority of buildings are just generic building=yes: http://osmdoc.com/en/tag/building/ Personally I think it would be much nicer if every building was just building=yes or true. That way people will be able to some more interesting renderings. For example shading certain types of building different colours. Shaun mixed with a few building=greenhouse/half-cylindrical plastic sheet covred plant growning housey things ___ 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] Potlatch 1.0 broken non-ASCII input on Mac OS X?
Woll Newall wrote: Potlatch 1.0 seems to have broken the input of non-ASCII characters in tags. I'm running Potlatch inside the Safari browser on Mac OS X. Before Potlatch 1.0 I could type in Japanese characters into the tags, but now the Japanese hiragana and katakana entries in the Kotoeri input menu are disabled when I'm in Potlatch (so only ASCII text can be entered, even in Japanese input mode). Entering non-ASCII text (e.g. é î å ë) works fine for me here, using Safari 4 on OS X 10.4. I think we'd have heard by now if there was a universal problem! Though I wouldn't know Kotoeri from Coco the clown, I've just played around for five minutes, enabled it in System Preferences - International, and have managed to successfully select the Hiragana and Katakana entries from the input menu while using Potlatch. The Kana palette then allows me to enter characters - not the ones I'd expect, but this is probably because I've started the browser with en-GB as the language and Flash Player tends to be sensitive to that. There's a new mailing list called potlatch-dev where such issues are best discussed. :) cheers Richard -- View this message in context: http://www.nabble.com/Potlatch-1.0-broken-non-ASCII-input-on-Mac-OS-X--tp23700117p23704358.html Sent from the OpenStreetMap - General mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap software for vehicles fleet management system
Hi, does anybody knows of any open source software or web application that is useful to be used for a vehicles fleet management system ? (all vehicles carry a GPS unit) and the maps should be based on OpenStreetMap. Otherwise, we are looking forward to start it from zero with the help of the community, and contribute to OSM all the data gathered by the fleet in south east Asia. Best Regards. Ivan Garcia. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap software for vehicles fleet management system
On Mon, 25 May 2009 12:57:36 +0200, Ivan Garcia capisc...@gmail.com wrote: Hi, does anybody knows of any open source software or web application that is useful to be used for a vehicles fleet management system ? (all vehicles carry a GPS unit) and the maps should be based on OpenStreetMap. Otherwise, we are looking forward to start it from zero with the help of the community, and contribute to OSM all the data gathered by the fleet in south east Asia. Best Regards. Ivan Garcia. Hi, I don't know such software in the non-commercial world. But if you write your own, I may help with protocolls. One of the things I'm writing for Traveling Salesman is a web-service to collect traffic information. A next step for me would then be to make a general protcoll that can carry much more data (like vehicle-positions, routes or voice-chat between multiple vehicles in a convoy). So we may make the protocolls between cars, servers and desktop- clients open and general enough so they can be supported by and usefully for many others here. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap software for vehicles fleet management system
Basically the application that we are trying to migrate into OpenStreetMap/OpenSource is this one http://www.vnskeye.com/Products.htm Hi Marcus, how do your protocols could be integrated into OSM? Thks. Ivan. On Mon, May 25, 2009 at 1:06 PM, marcus.wolsc...@googlemail.com wrote: On Mon, 25 May 2009 12:57:36 +0200, Ivan Garcia capisc...@gmail.com wrote: Hi, does anybody knows of any open source software or web application that is useful to be used for a vehicles fleet management system ? (all vehicles carry a GPS unit) and the maps should be based on OpenStreetMap. Otherwise, we are looking forward to start it from zero with the help of the community, and contribute to OSM all the data gathered by the fleet in south east Asia. Best Regards. Ivan Garcia. Hi, I don't know such software in the non-commercial world. But if you write your own, I may help with protocolls. One of the things I'm writing for Traveling Salesman is a web-service to collect traffic information. A next step for me would then be to make a general protcoll that can carry much more data (like vehicle-positions, routes or voice-chat between multiple vehicles in a convoy). So we may make the protocolls between cars, servers and desktop- clients open and general enough so they can be supported by and usefully for many others here. Marcus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Importing selected Tracks from Garmins Current.gpx
Use GPSU to break the tracks - http://www.gpsu.co.uk/ Mike Harris -Original Message- From: Ingo Lantschner [mailto:listen2...@lantschner.name] Sent: 24 May 2009 21:31 To: talk@openstreetmap.org Subject: [OSM-talk] Importing selected Tracks from Garmins Current.gpx Hi all, I am using a nüvi 550 from Garmin. This device stores all tracks in one file called Current.gpx. While this file can be imported into OSM I could not find a way to select the traces. So within a few days you are getting more and more traces when uploding this file. For now I edited the XML by hand. But I wonder, if there is not a tool, which can be used to select the tracks from f.e. today or the last week. (GPSBable did not do that, it even does not work with selecting by a radius - at least not here) Thanks for any hints, Ingo -- Ingo Lantschner 1060 Vienna-Austria Mobil +43-664-143 84 18 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] JOSM max upload changeset size
On 24 May 2009, at 20:02, Sam Vekemans wrote: Hi, I'm wondering what the max size per edit session that JOSM can handle is? Whats the standard rule? Every 10mins? Or will josm accept any size, it would just take longer? What is a happy back-end servers size, that doesnt bog it down? There is a maximum of 50,000 items in each changeset. It really depends on the complexity of the changeset. If it is just node and way changes it will be a lot quicker than large relations. It is also dependant on the number of other editors in your area. So if you have many people in the area editing at the same time, then it is much better to upload more often. Is there a max default/timeout that JOSM squaks at? Could JOSM check for area edits before upload starts? File Update Data, however you currently don't get changes to items moved out of your editing area nor items that have been deleted. There is talk of this changing. Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] How to tag small city alley ?
Hi, could you tell me by looking at this picture [1] how to tag this in OSM ? http://4.bp.blogspot.com/_8Y0T3EnBVPw/SJcJ13KnOII/BCg/ot4X2My6CvA/s400/vietnam%2Balley.jpg It's an alley where only people/motorbikes can go. Best Regards. Ivan. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] How to tag small city alley ?
Ivan Garcia wrote: Hi, could you tell me by looking at this picture [1] how to tag this in OSM ? http://4.bp.blogspot.com/_8Y0T3EnBVPw/SJcJ13KnOII/BCg/ot4X2My6CvA/s400/vietnam%2Balley.jpg It's an alley where only people/motorbikes can go. access=no foot=yes bicycle=yes (I assume bicycles are allowed) motorcycle=yes signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk-nl] OSMDoc
Ha, Ik zag dit vandaag voor het eerst opduiken in een thread op talk, wellicht interessant voor meerderen; een soort improved Tagwatch-website: http://osmdoc.com/de/about/ Take care, Martijn martijn van exel -+- mve...@gmail.com -+- http://www.schaaltreinen.nl/ ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] usability, een grote drempel voor osm gebruik (imho)
Hey, Lange posting, maar ik heb iets uit te leggen. Ik beloof, mijn volgende postings zullen korter zijn. Ondanks dat mijn account al iets langer bestaat, ben ik sinds een paar dagen pas echt actief als gebruiker *en* editor van OSM. Dat tussen het account aanmaken en mijn eerste edit zoveel tijd zit, heeft een slechts een reden: ik vind het project behoorlijk ontoegangelijk. Nu ik er mee bezig ben, weet ik ook precies waar de ontoegangelijkheid vandaan komt: gebrek aan usability bij de ontsluiting van de data aan de voorkant als ook bij de aanpassing aan de achterkant. Het ontbreekt aan een interface waarin je kunt opgeven dat je alle objecten van een bepaald type wilt zien. Iets als toon me alle geld- automaten (in mijn huidige bounding box). Ze zijn wel zichtbaar te maken, maar enkel als je ver genoeg ingezoomed bent, als je de data layer hebt gevonden, als je de omvangswaarschuwing hebt weggeklikt en als je alle andere data voor lief neemt. En zelfs die layer is niet handig. Dat werkt niet. [1] Wat wel zou werken, denk ik, is een enkele kolom met een uitklap menu en waarin je de verschillende type objecten kunt aan- een uitzetten. Om te beginnen een kale kaart waarop enkel objecten worden getoond als de gebruiker ze aanzet (toon alle brievenbussen en postkantoren). Een ander heel praktisch ding: de legenda is op een uiterst onhandige plek weggestopt. De map key link in de linkerkolom is niet de plaats waar je zoekt naar een legenda als je de kaart voor je neus hebt. Andere voorbeelden van een omslachtige ontsluiting zijn de manier waarop je de kaarten met overlays kunt embedden op een webpagina (een grote lap Javascript is daarvoor nodig) en de manier waarop je de kaart in je GPS kunt laden (hoewel sterk verbeterd met de komst van garmin.na1400.info). En ook aan de andere kant vind ik de usability van OSM problematisch. De editor JOSM doet wat het moet doen, maar dat is het dan ook wel. JOSM heeft niets, maar dan ook echt niets, wat het iets intuitief of zelfs aantrekkelijk maakt. De presentatie van de data in de editor maken het moeilijk om in te schatten wat het resultaat gaat zijn. De presets zijn handig maar erg traag (worden die elke keer opgehaald?). Om de Yahoo imagery in de achtergrond krijgen moet ik eerst XCode en Qt gaan installeren. Validatie en bugs zijn enkel via plugins beschikbaar. Eindeloos. Hopeloos. Iemand die het bestaande verder wil verbeteren wordt ook drempels opgeworpen. Er zijn wat losse interfaces voor het detecteren van fouten, maar dat zijn allemaal losstaande initiatieven die daarmee ondersteuning missen. Ik ben in de paar dagen dat ik er mee bezig ben onder meer Keep Right! en OpenStreetBugs, maar er zullen er zonder meer zijn. Bovendien zijn die niet erg uitnodigend voor niet-editors. Het zou toch mooi zijn als gebruikers (visitors) van OSM makkelijk melding kunnen maken van vermeende fouten en dat dat soort meldingen snel inzichtelijk gemaakt worden voor editors? Ik zou zo een stuk van mijn woonplaats onder mijn hoede willen nemen als editor. En zo zijn er mee dingen: op mijn gevoel af zeg ik dat er (te) weinig standarisatie is en dat de organisatie eromheen te los is. Ik realiseer me dat veel van de problemen die ik noem niet specifiek issues van NL zijn. Dat neemt niet weg dat ik ze hier wel ervaar. :) Anyway... natuurlijk ben ik bekend met het principe van open projecten als dit. Ik wil dan ook niet alleen kritiek hebben, ik wil er ook graag aan bijdragen. Nu ben ik geen programmeur en daardoor kan ik een aantal van deze problemen kan ik niet zelf oppakken. Ik ben echter graag bereid om mee te denken en suggesties te doen voor de problemen die ik (we?) zien. Dat aanbod staat. En in de tussentijd doe ik gewoon mijn best als editor. [1] Ik ken http://xapidemo.openstreet.nl, dat gaat een goede kant op. -- Rejo Zenger . r...@zenger.nl . 0x75FC50F3 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] licentie kaart data
Hi, Op http://tile.openstreetmap.nl/ staat onderin in de witte balk de tekst Kaart data cc-by-sa OpenStreetMap gebruikers.. Dat lijkt me niet helemaal correct, afhankelijk van de wijze waarop je gebruikers definieert. Mijn gevoel zegt dat je gebruikers definieert als editors *en* als visitors (of browsers). Voor zover ik weet ligt het auteursrecht van de data in die kaart slechts bij de editors, niet bij die andere groep. Zou die tekst niet anders moeten? -- Rejo Zenger . r...@zenger.nl . 0x75FC50F3 . https://rejo.zenger.nl GPG encrypted e-mail prefered. signature.asc Description: Digital signature ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[talk-au] Yorke Peninsula and South Australia
Hi All, I will be working in SA for several months, everywhere from Mt Gambier to Olympic Dam to Ceduna. I will be going through the Yorke Peninsula too and adding major roads. If you need something checked anywhere, ie street names etc, as long as it will only take a few minutes as I am passing through, then make a list and I will see what I can do. Graeme Wilson VK1RE wandere...@live.com.au _ View photos of singles in your area Click Here http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fdating%2Eninemsn%2Ecom%2Eau%2Fsearch%2Fsearch%2Easpx%3Fexec%3Dgo%26tp%3Dq%26gc%3D2%26tr%3D1%26lage%3D18%26uage%3D55%26cl%3D14%26sl%3D0%26dist%3D50%26po%3D1%26do%3D2%26trackingid%3D1046138%26r2s%3D1_t=773166090_r=Hotmail_Endtext_m=EXT___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Mon, 25 May 2009, Delta Foxtrot wrote: Wikipedia has 2 distinct entries, a ford is something close to the usual concrete slab I'm thinking/refering to, the US version of a causeway looks like a built up piece of land acting like a low bridge, although they do seem to have a Western Australian reference as well. http://en.wikipedia.org/wiki/Ford_(crossing) http://en.wikipedia.org/wiki/Causeway Looking at the photos above a ford looks the closest to what I'd call a causeway. wikipedia does have a disambiguation, because causeway means different things, while offering this definition A causeway is a road or railway elevated by a bank, usually across a broad body of water or wetland. so for that sort of causeway i would consider bridge=yes might be useful. I made some decision when I put in a Causeway near the Darwin convention centre. I looked back to see what was there now, and found it changed by someone to highway=unclassified just a way marked across the water. It is for people only, although a bike would be ok, and the later editor hasn't marked the restrictions. -- Q: What's a WASP's idea of open-mindedness? A: Dating a Canadian. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Mon, 25 May 2009, Mark Pulley wrote: Wikipedia also has http://en.wikipedia.org/wiki/Low_water_crossing - this is what I have been thinking of as 'causeway'. Do we need a new setting highway=low_water_crossing ? ford should do that OK. We have an interesting language problem in OSM, where the Poms push forward pommie English, and the rest of the English speaking world may not use that word that way, and causeway which has two clear meanings to us and the Yanks, is a good example. Ford isn't in common use in Oz, except in Ford vs Holden. Something else I can't work out how to tag is a jetty, the thing that juts out into water and boats tie up to. But after 8 years of drought here, perhaps I needn't worry too much. -- Q: What's the difference between a Mac and an Etch-a-Sketch? A: You don't have to shake the Mac to clear the screen. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Yorke Peninsula and South Australia
On Mon, 25 May 2009 18:50:15 +1030 Graeme Wilson wandere...@live.com.au wrote: If you need something checked anywhere, ie street names etc, as long as it will only take a few minutes as I am passing through, then make a list and I will see what I can do. On good thing to get since you mentioned the YP is the path of the B89, I've added it down to north of wallaroo but I can't remember where it goes from there so if you're in that area.. :) -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
2009/5/25 Liz ed...@billiau.net: Something else I can't work out how to tag is a jetty, the thing that juts out into water and boats tie up to. But after 8 years of drought here, perhaps I needn't worry too much. Just be grateful you're not trying to teach English to some-one who speaks Melanesian pidgin. There's no distinction there between a bridge, a pier, a jetty, etc. If it's man-made and it's elevated, it's a bris. Trying to explain why English uses different words for what to them is the same thing was difficult. Stephen ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Mon, 25 May 2009, Stephen Hope wrote: Just be grateful you're not trying to teach English to some-one who speaks Melanesian pidgin. There's no distinction there between a bridge, a pier, a jetty, etc. If it's man-made and it's elevated, it's a bris. Trying to explain why English uses different words for what to them is the same thing was difficult. Stephen I understand. We deal daily with Italians, Sikhs, Turks, 50 + ethnic groups, the English-speaking are a minority here. -- BOFH excuse #352: The cables are not the same length. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
--- On Mon, 25/5/09, Liz ed...@billiau.net wrote: Yup, in New South, when you have a concrete road way built into the bottom of a creek bed, crossing the creek, that's a causeway. Except it's a ford. Except the deff of a ford is that it's usually wet and the slabs in NSW creeks and gullies are usually dry, and they aren't bridges and a lot of them don't even have pipes for water to flow underneath them since there usually isn't that much except when it floods. So while a ford seems the closest fit it isn't the same thing either. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] NSW/QLD Border
--- On Mon, 25/5/09, Delta Foxtrot delta_foxt...@yahoo.com wrote: A section of ABS boundary is over 4000 nodes, but I keep getting an error about a maximum of 2000 nodes, and I can't figure out how to split or otherwise the segment so it can be turned into a river/border. JOSM can't deal with it, but for some reason potlatch can. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
--- On Mon, 25/5/09, b.schulz...@scu.edu.au b.schulz...@scu.edu.au wrote: They're not marked in though, because the river hasn't been marked in yet either. Along that road they are marked with an RTA road sign which reads FORD. Perhaps we could mark all the crossings which are signposted as such as highway=ford and the rest as causeways or bridges. Well there is no causeway tag, beyond that you have the whole issue that there seems to be at least 2 different meanings depending on where the person is from as to what they are talking about. My original question was in relation to concreate slab crossings which technically aren't fords because they dry far more often than wet, and they aren't raised at all so they're not bridges. I can't find an example of what I mean, I'll have to take a photo of one and post it online in the next few days. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Tue, 26 May 2009, Delta Foxtrot wrote: My original question was in relation to concreate slab crossings which technically aren't fords because they dry far more often than wet, and they aren't raised at all so they're not bridges. I can't find an example of what I mean, I'll have to take a photo of one and post it online in the next few days. the definition of it being wet is a pommie problem you need rain before they get wet we don't even have a marker for rivers or lakes which are seasonal (ie, usually dry) i'm not at all bothered if you label a ford ford when the creeks dry - if the creek had water it would be wet?? Liz ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Tue, 26 May 2009 07:31:01 +1000 Liz ed...@billiau.net wrote: On Tue, 26 May 2009, Delta Foxtrot wrote: My original question was in relation to concreate slab crossings which technically aren't fords because they dry far more often than wet, and they aren't raised at all so they're not bridges. I can't find an example of what I mean, I'll have to take a photo of one and post it online in the next few days. the definition of it being wet is a pommie problem you need rain before they get wet we don't even have a marker for rivers or lakes which are seasonal (ie, usually dry) i'm not at all bothered if you label a ford ford when the creeks dry - if the creek had water it would be wet?? I agree Liz, I was just thinking pretty much exactly the same thing a few minutes ago when Delta's post arrived. It's totally a factor of the state of the watercourse in question. Luckily for us a couple of Fords I went through on the weekend did actually have a spot of water in them, it's been nice this last month to finally see some of that long forgotten rain :D -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] Fords, Causeways, Piers, Wharfs, etc
Really? We've always called 'em Fords here in SA, they called causeways elsewhere? And a causeway to me is exactly the definition I saw posted earlier from wikipedia, so the whole confusion is confusing to me :) Something else I can't work out how to tag is a jetty, the thing that juts out into water and boats tie up to. But after 8 years of drought here, perhaps I needn't worry too much. man_made = pier works doesn't it? That's whay I've seen people using and the definition on map features seems to fit it. Hi All, I don't have a problem with a ford (Slab of concrete or gravel base across a water course, wet or dry) or a causeway ( A rock or concrete structure across a water course with the ability of water to pass under during normal season and water over structure during flooding) I don't have a problem with a pier to show a structure along a water course or protruding into a watercourse that is used for marine activities. What I do have a problem with is a rock or concrete wall that is built to control the flow of water as in river mouths and enclosing harbours. Some call them Breakwalls, some call them Training Walls, some call them Breakwaters, some call them Retaining Walls and so forth. What do we call them ??? Nearly every river and harbour on the north coast of NSW have them Regards Darylr -- ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au End of Talk-au Digest, Vol 23, Issue 7 ** ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fords, Causeways, Piers, Wharfs, etc
Hi there, The maps produced by the NSW Department of Lands (now NSW Land and Property Information) calls them a breakwater in their map key. I've also seen the breakwater term used on warning sings and the like which are posted near said man-made rocky protrusions. So, unless a different govt dept calls them something else that's probably the most official name for them in an Australian context. Brent What I do have a problem with is a rock or concrete wall that is built to control the flow of water as in river mouths and enclosing harbours. Some call them Breakwalls, some call them Training Walls, some call them Breakwaters, some call them Retaining Walls and so forth. What do we call them ??? Nearly every river and harbour on the north coast of NSW have them Regards Darylr -- ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au End of Talk-au Digest, Vol 23, Issue 7 ** ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Causeways
On Tue, 26 May 2009 07:31:01 +1000 Liz ed...@billiau.net wrote: On Tue, 26 May 2009, Delta Foxtrot wrote: My original question was in relation to concreate slab crossings which technically aren't fords because they dry far more often than wet, and they aren't raised at all so they're not bridges. I can't find an example of what I mean, I'll have to take a photo of one and post it online in the next few days. the definition of it being wet is a pommie problem you need rain before they get wet we don't even have a marker for rivers or lakes which are seasonal (ie, usually dry) i'm not at all bothered if you label a ford ford when the creeks dry - if the creek had water it would be wet?? I agree Liz, I was just thinking pretty much exactly the same thing a few minutes ago when Delta's post arrived. It's totally a factor of the state of the watercourse in question. I agree with Darrin and Liz on this. The openstreetmap wiki also says any water it does not mean that there has to be water over the ford all the time. I take this as if there is water over the ford then a vehicle will have to enter it. The part that says The road crosses through stream or river is more significant as we mark these (stream or river) whether they are flowing or not so if the road passes through it rather than over it on a bridge then it's a ford. I would also consider the case where some roads have pipes ( 1m dia) that run under the road so that when water level is low as it runs under the road but with rain in the area it readily flows over the road. The road also drops down to just above, or becomes part of, the river bed as opposed to staying at or above the river banks. There is also the situation with large diameter pipes (1m dia) where the road stays well above the river bed and is at the same height as the banks. I've always thought of these as culverts but as osm has no definition for this I have marked them as bridges as that's generally what they are. It's either a ford or a bridge that you cross through or cross over a stream or river on. A bridge does not require that you drive through the water if there is water flowing in the stream or river, a ford does even though some may have pipes under them as well. Cheers Ross ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Fords, Causeways, Piers, Wharfs, etc
--- On Mon, 25/5/09, dar...@tpg.com.au dar...@tpg.com.au wrote: What I do have a problem with is a rock or concrete wall that is built to control the flow of water as in river mouths and enclosing harbours. Some call them Breakwalls, some call them Training Walls, some call them Breakwaters, some call them Retaining Walls and so forth. What do we call them ??? Nearly every river and harbour on the north coast of NSW have them South coast too... http://tagwatch.stoecker.eu/Australia-oceania/En/tags.html Has a number of the above variations listed. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] tracks in osmarender (16-17)
Heiko Jacobs heiko.jac...@gmx.de wrote: Sei waren früher mal innen weiß. Dann hat jemand dran rumgeschraubt und sie hatten innen einen hellstbraunen oder hellstgrünen (bei surface= grass) Strich. Das war ne Änderung von jemandem hier auf der Liste. Da das besser ausgesehen hatte als vorher hatte ich das seinerzeit eingecheckt. Sven -- We don't know the OS that God uses, but the Vatican uses Linux (Sister Judith Zoebelein, Vatican Webmaster) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] All-in-One Deutschland - mit Garmin eTrex
Hallo, ich lese inzwischen regelmäßig mit, manches ist mir etwas hoch, aber als Hobby Mapper muss ich ja auch nicht alles wissen. Ich teste aber gerne immer wieder die Routigfunktion auf meinem Garmin eTrex legend Cx und da ist All-in-One Karte eigentlich super, aber... Jetzt hab ich aber mit der All-in-One Karte auf meinem Garmin eTrex ein Problem. Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Bei anderen Strecken ist mir das in den Osterferien in NRW auch schon mal passiert, dann hatte ich eine neuere Karte da ging's. Die Karte die ich jetzt verwende ist vom 22.05 hat jemand einen Tipp was da los ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Hi die erste weiße Linie müsste die transparente sein, d.h. die Transparenz muss sich nirgends durcharbeiten. Das könnte vielleicht schon helfen. Die optische Überbewertung der schlechteren Tracktypes vor dunklem Hintergrund kommt m.E. im wesentlichen durch den höheren Weißanteil im Rand. -fri- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] All-in-One Deutschland - mit Garmin eTrex
Hallo, ich lese inzwischen regelmäßig mit, manches ist mir etwas hoch, aber als Hobby Mapper muss ich ja auch nicht alles wissen. Ich teste aber gerne immer wieder die Routigfunktion auf meinem Garmin eTrex legend Cx und da ist All-in-One Karte eigentlich super, aber... Jetzt hab ich aber mit der All-in-One Karte auf meinem Garmin eTrex ein Problem. Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Bei anderen Strecken ist mir das in den Osterferien in NRW auch schon mal passiert, dann hatte ich eine neuere Karte da ging's. Die Karte die ich jetzt verwende ist vom 22.05 hat jemand einen Tipp was da los ist? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Für z12-z14 bin ich zum Mapnik-Stil übergegangen, da man da anders gar nix mehr erkannt hat und nix zu optimieren ging... Diesen Stil finde ich generell ziemlich gut; die Tracks und auch die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege (besonders letztere): http://www.openstreetmap.org/?lat=49.895lon=10.9201zoom=14layers=0B00FTF Das sieht alles aus wie ein hellgrüner Brei, man muss sich schon sehr konzentrieren, um die einzelnen Wege auseinanderhalten zu können. Wenn man rauszoomt, wirds noch schlimmer. Bei den Feldwegen (z.B. weiter nördlich in dem großen Kleingartengebiet vor Hallstadt) kommt mir das nicht so schlimm vor, deswegen vermute ich, dass es an der grellen Farbe liegt. -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Sven Geggus li...@fuchsschwanzdomain.de wrote: Heiko Jacobs heiko.jac...@gmx.de wrote: Sei waren früher mal innen weiß. Dann hat jemand dran rumgeschraubt und sie hatten innen einen hellstbraunen oder hellstgrünen (bei surface= grass) Strich. Das war ne Änderung von jemandem hier auf der Liste. Da das besser ausgesehen hatte als vorher hatte ich das seinerzeit eingecheckt. An der Diskussion war ich damals glaub sogar mit beteiligt. Ich meine, ich hätte damals schon wegen der Nichterkennbarkeit des tracktyps rumgenölt ;-) Geholfen hat das bzgl. tracktype-Unterscheidbarkeit aber nicht viel... Mag an meinem Laptop-LCD liegen... Aber das Problem hätte ich dan sicher nicht alleine... Da die tracks den Leuten offenbar nun zu weiß sind, könnte ich das alte hellstbraun ja wieder ausgraben und zusätzlich einbauen und/oder Transparenzen, schaun mer mal, wie's wirkt. Aber vielleicht erst in paar Tagen, wollte eigentlich wegen anderer wegen OSM schon aufgeschobener Terminsachen mal einen OSM-suchtfreien Tag versuchen ;-) MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Martin Koppenhoefer dieterdre...@gmail.com wrote: Als Alternative fällt mir nur ein, wie in den höheren Zoomstufen eine einzige braune Linie für den Track zu rendern (alles insgesamt schmaler, z.B. weisse Linie, 40% Alpha, 0.8px, darüber braune Linie 0.6px und keine 3. weisse Linie mehr). Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Christian von Rotenhan umax...@googlemail.com wrote: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Ein bekanntes Problem, das manchmal bei längeren Routen auftritt. Christoph, der die all-in-one Graminkarte macht ist in Urlaub und kann vielleicht mehr dazu sagen. Hast Du mal pobiert zu Hause einen Wegpunkt zu setzen und Dich zu diesem Wegpunkt routen zu lassen? Das mit den Adressen ist ja bekanntlich noch etwas holprig. Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am 25.05.2009 11:24 Uhr, schrieb Sven Geggus: Christian von Rotenhanumax...@googlemail.com wrote: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Ein bekanntes Problem, das manchmal bei längeren Routen auftritt. Christoph, der die all-in-one Graminkarte macht ist in Urlaub und kann vielleicht mehr dazu sagen. Hast Du mal pobiert zu Hause einen Wegpunkt zu setzen und Dich zu diesem Wegpunkt routen zu lassen? Das mit den Adressen ist ja bekanntlich noch etwas holprig. Sven Tja, genau das hab ich gemacht, In der Regel vermeide ich die Adressen suche und navigiere nur Wegpunkte an ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrbahnen und bicycle=no
Joerg Fischer schrieb: Am Freitag 22 Mai 2009 14:43:33 schrieb Martin Koppenhoefer: er weiss ja, wohin Du fahren willst. Das kannst Du beim Mappen des Wegs nicht vorhersagen. Wenn der Radweg dorthin führt, wo Du nicht hinradeln willst (z.B. willst Du links abbiegen, oder Du willst auf Ok, das ist ein Argument, das ich an relevanten Stellen beachte. Wenn ich in mich gehe hab ich das in hiesiger Umgebung *so* auch noch nicht gesehen. (Also, dass ein Radweg straßenbegleitend anfängt und dann unvermittelt und ohne eine weitere Möglichkeit zurück auf die Straße zu kommen abbiegt.) Es muss ja noch nicht mal so sein, dass der Radweg dann irgendwo in einen Park o. ä. verschwenkt. Wenn man sich zu einer Hausnummer auf der linken Straßenseite routen lässt, dann wird der Router einen erstmal auf den Radweg auf der rechten Seite schicken, an der Hausnummer vorbeifahren und an der nächsten Kreuzung dann wieder auf dem Radweg zurück. Sollte man das bemerken und direkt vom Radweg auf die andere Straßenseite wollen, ist einem dann evtl. der Weg durch Hecken, Bäume, Zäune etc. versperrt. Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Christian von Rotenhan schrieb: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Das passiert bei meinem Vista HCx leider auch recht häufig, bevorzugt bei längeren Strecken, und liegt wohl am zu kleinen Arbeitsspeicher des Geräts. Ich habe verschiedene Karten ausprobiert (Computerteddy, All-in-one, selbst mit mkgmap erstellte), bei allen tritt das Problem auf. Vielleicht beherrscht mkgmap ja auch noch nicht alle Eigenheiten des Garmin-Datenformats, so dass dadurch noch Fehler entstehen können? Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Das habe ich auch schon gehabt, ist aber die Ausnahme. Ich lasse das Navi oft mitlaufen wenn ich kurze Strecken in bekanntem Gebiet unterwegs bin um einen Eindruck von der Routingqualität zu bekommen, da klappt es normalerweise recht gut. Aber dafür brauche ich eben kein Navi :-/ Ich hoffe ja, dass Plan B von Openmoko ein taugliches Opensource-Navi wird, dann gäbe es wohl einige Probleme weniger. Viele Grüße, Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Holger Blum ho...@gmx.net wrote: Ich hoffe ja, dass Plan B von Openmoko ein taugliches Opensource-Navi wird, dann gäbe es wohl einige Probleme weniger. Tja, der wasserdichte Linux PDA mit GPS-chip. Gibts leider noch nicht. Würd ja auch schon reichen, wenn jemand sowas auf vorhandene Navi-Hardware portieren würde. Die Outdoor Garmins sind AFAIK leider nicht Linuxbasiert. Sven -- We just typed make (Stephen Lambrigh, Director of Server Product Marketing at Informix about porting their Database to Linux) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am 25.05.2009 11:38 Uhr, schrieb Holger Blum: Christian von Rotenhan schrieb: Fahrten von Schweinfurt nach Würburg oder Bamberg gehen prima und führen mich auch so zum Ziel wie ich mir das vorstelle. Gebe ich aber dann von dort meine Straße in Schweinfurt an, um mich zurückrouten zu lassen, dann wird diese Route berechnet bis 100% und dann erfolgt ein totalabsturz des Garmin, der sich nur noch durch einen Neustart beheben lässt (Das Berechnen Bild hängt sich bei 100% auf) Das passiert bei meinem Vista HCx leider auch recht häufig, bevorzugt bei längeren Strecken, und liegt wohl am zu kleinen Arbeitsspeicher des Geräts. Ich habe verschiedene Karten ausprobiert (Computerteddy, All-in-one, selbst mit mkgmap erstellte), bei allen tritt das Problem auf. Vielleicht beherrscht mkgmap ja auch noch nicht alle Eigenheiten des Garmin-Datenformats, so dass dadurch noch Fehler entstehen können? Selbst Versuche kurz vor der Haustür ( Schweinfurt - Raßdörferstr.) noch den Rest Routen zu lassen scheitern Das habe ich auch schon gehabt, ist aber die Ausnahme. Ich lasse das Navi oft mitlaufen wenn ich kurze Strecken in bekanntem Gebiet unterwegs bin um einen Eindruck von der Routingqualität zu bekommen, da klappt es normalerweise recht gut. Aber dafür brauche ich eben kein Navi :-/ Ich hoffe ja, dass Plan B von Openmoko ein taugliches Opensource-Navi wird, dann gäbe es wohl einige Probleme weniger. Viele Grüße, Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Merkwürdig ist eben nur, dass der hinweg klaglos und schnell berechnet wird (sind ja nur ca 50 km) und beim Rückweg diese Abstürze auftreten. Ich kann in den Straßen die ich befahre mit JOSM und mit potlach nichts verdächtiges finden... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Schlüssel-Klartext über den Eigenschaften
Moin ! wenn ich mich richtig erinnere, dann war der Klartext Tags bisher immer UNTER den Key-Value-Einträgen. Jetzt sind diese darüber und müssen immer nach oben geschoben werden. Unten fand ich das besser ! Seht ihr das genauso und sollte das nicht wieder geändert werden !? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Hallo Heiko, meiner Meinung nach ist die Karte durch deine Änderungen deutlich übersichtlicher geworden. Für z15 und z16 wirken die Tracks noch etwas überbetont und könnten schmaler sein. Bei z17 sieht es wieder gut aus. Als Alternative fällt mir nur ein, wie in den höheren Zoomstufen eine einzige braune Linie für den Track zu rendern Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... In höheren Zoomstufen bevorzuge ich die flächenhafte Zeichnung der Wege von Osmarender. Bei z=13-z14 erkennt man kleine Wege auf der Mapnikkarte einfacher, dafür wirkt sie unruhiger. Da wir schon über das Kartendesign in osmarender sprechen: Die Darstellung der Bahnlinien finde ich unglücklich. Im Ausschnitt http://www.openstreetmap.org/?lat=54.334lon=10.2105zoom=14layers=0B00FTF erkennt man sie Museumsbahnstrecke sofort, bei den normalen Bahnstrecken muss man genau schauen, welche Straßen durch Querstriche zu Gleisen werden. Mapnik stellt Bahnstrecken geschickter dar. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Marc Schütz schue...@gmx.net wrote: Für z12-z14 bin ich zum Mapnik-Stil übergegangen, da man da anders gar nix mehr erkannt hat und nix zu optimieren ging... Diesen Stil finde ich generell ziemlich gut; die Tracks und auch die Residentials sind bei niedrigem Zoom viel besser zu erkennen. Wenn ich genug Zeit dafür habe, werde ich das wohl für z11 abwärts weiter entwickeln. Was meiner Meinung nach nicht ganz so schön ist sind die Fuß- und Radwege (besonders letztere): Ja, da ist mein eigenes Empfinden für's Optimum auch noch nicht voll erreicht... Das sieht alles aus wie ein hellgrüner Brei, deswegen vermute ich, dass es an der grellen Farbe liegt. Ich hatte die Farben aus denen der flächigen Pastellfarben der Wege weiter entwickelt, nur mit mehr Sättigung im IHS-(HSV)-System, aber das ist es wohl noch nicht so ganz... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] an die Routing- und sonstigen Entwickler
Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite wird ausführlich beschrieben, man sollte z.B. nicht walk sondern maxspeed=UK:walk oder maxspeed=DE:living_street verwenden. Ist das wirklich notwendig? Oder reicht doch schon ein schlichtes walk ohne Länderkürzel? Dasselbe gilt natürlich auf für town und country. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Am 25. Mai 2009 11:17 schrieb Heiko Jacobs heiko.jac...@gmx.de: Martin Koppenhoefer dieterdre...@gmail.com wrote: Als Alternative fällt mir nur ein, wie in den höheren Zoomstufen eine einzige braune Linie für den Track zu rendern (alles insgesamt schmaler, z.B. weisse Linie, 40% Alpha, 0.8px, darüber braune Linie 0.6px und keine 3. weisse Linie mehr). Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... ja, mind. für 15 ist es m.E. klar, dass eine Behandlung ähnlich Z14 besser aussähe (eine Linie statt 2), bei 16 und 17 bin ich mir nicht so sicher, wobei da der weisse Hintergrund ein bisschen stört, aber vielleicht kommt man dem ja auch anders bei. Hast Du es schonmal ohne casing versucht? Das Problem ist wohl, dass man nur hinzufügen (also überdecken) kann, nicht weglöschen (also so was wie ne Boolsche Subtraktion). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite wird ausführlich beschrieben, man sollte z.B. nicht walk sondern maxspeed=UK:walk oder maxspeed=DE:living_street verwenden. Ist das wirklich notwendig? Oder reicht doch schon ein schlichtes walk ohne Länderkürzel? Dasselbe gilt natürlich auf für town und country. Gruß Martin Hallo Martin, so eine Frage wäre wohl auf der routing oder zumindest der dev Mailing-Liste besser aufgehoben. Zumal du hier nur die deutschsprachigen Entwickler und von denen auch nur einen Teil erreichst. Also, für mich: Momentan wird alles in maxspeed was keine Zahl ist konsequent ignoriert. Der einzige Ausnahmefall sind Zahlen mit mph dahinter. Für nationale Verkehrsregeln und damit auch die Default-Werte für Maxspeed sind bei mir die Klassen http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=TrafficRuleManager und http://apps.sourceforge.net/mediawiki/travelingsales/index.php?title=Country zuständig. Diese versuchen für tausende angefragte Strassen pro Sekunde jeweils möglichst schnell zu bestimmen in welchem Land sie vollständig oder teilweise liegen. Die Auswertung des Grenzpolygons ist dabei der letzte Rückfall-Kandidat und die aufwendigste Methode. Eine Vorverarbeitung findet für maxspeed nich statt. Du kannst jederzeit edit in JOSM clicken und was du bekommst auch hochladen ohne lauter computer-generierte Tags mit in die DB zu pusten. (Die ich lokal ja auch speichen müsste und die Karte ist schon viel zu gross auf der Platte.) Für die Maxspeed-Werte gibt es eine Default-Implementierung welche versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit wählt. Die einzelnen Länder können dabei diese Default-Logik nutzen oder eine eigene (für Sonderfälle) besitzen. (z.B. abhängig von lit=yes/true/1 oder von dem Wert eines lanes-tags) Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 13:51 schrieb Falk Zscheile falk.zsche...@googlemail.com: Moin, auf Campingplätzen sind die Sanitärgebäude oft eine Kombination aus amenity=toilets und amenity=shower. Unter JOSM kann ich beides nicht gleichzeitig in einer node abbilden. Ist dieses Verhalten gewollt? Gibt es ein eigenes tag für Sanitärgebäude? Gruß, Falk wieso nur unter JOSM? Ist das nicht allgemein unmöglich, 2 tags mit demselben namen zu setzen, mind. seit API 0.6? Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) oder setzen von 2 Nodes: einen mit Toilets, einen mit Shower. (ist praktisch problemlos). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
Am 25. Mai 2009 15:42 schrieb marcus.wolsc...@googlemail.com: On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer Für die Maxspeed-Werte gibt es eine Default-Implementierung welche versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit wählt. anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder ausserhalb bist? Wäre das explizite Mappen von impliziten Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 15:52:03 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 25. Mai 2009 15:42 schrieb marcus.wolsc...@googlemail.com: On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer Für die Maxspeed-Werte gibt es eine Default-Implementierung welche versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit wählt. anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder ausserhalb bist? Wäre das explizite Mappen von impliziten Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? Von Ländern oder Orten? Ort: Es gibt 2 mögliche Adress-Datenbanken (Plugins wie alles andere in TS halt). Diese kennen entweder das Polygon eines Ortes oder Mittelpunkt und angenommenen Radius. Eine Unterscheidung zwischen Orts-Polygon für Adress-Suche und für Verkehrs-Regeln findet (noch) nicht statt. Eine Suche ob ein als Ortschaft getaggter Weg/Node in einem bestimmten Umkreis vorhanden ist wären viel, viel zu aufwendig nur um wärend der Auswertung einer Metrik in der Routen-Berechnung die maximale erlaubte Geschwindigkeit für ein Wegstück, was am Ende warscheinlich eh nicht Teil der Router wird zu ermitteln. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 15:47 schrieb Martin Koppenhoefer dieterdre...@gmail.com: Am 25. Mai 2009 13:51 schrieb Falk Zscheile falk.zsche...@googlemail.com: auf Campingplätzen sind die Sanitärgebäude oft eine Kombination aus amenity=toilets und amenity=shower. Unter JOSM kann ich beides nicht gleichzeitig in einer node abbilden. Ist dieses Verhalten gewollt? wieso nur unter JOSM? Ist das nicht allgemein unmöglich, 2 tags mit demselben namen zu setzen, mind. seit API 0.6? Das wusste ich nicht. Deshalb habe ich es nur auf den Fall bezogen, für den ich mir sicher war. Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? Bei tourism=hotel und amenity=restaurant ist es ja auch mehr oder weniger entwicklungsgeschichtlicher Zufall, dass es hier zu keiner unzulässigen Kombination kam. Auch ein hotel könnte ich mir sehr gut als amenity vorstellen. Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne Tricks kombinieren lassen. Gruß, Falk ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
On Mon, 25 May 2009, Falk Zscheile wrote: Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? Bei tourism=hotel und amenity=restaurant ist es ja auch mehr oder weniger entwicklungsgeschichtlicher Zufall, dass es hier zu keiner unzulässigen Kombination kam. Auch ein hotel könnte ich mir sehr gut als amenity vorstellen. Eigentlich ist das Semikolon wohl der offizielle Weg. Aber außer TagWatch wertet das keiner aus. Da kann es noch so offiziell sein, wenn es keiner nutzt hilft das nicht. Ciao -- http://www.dstoecker.eu/ (PGP key available)___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
also ich würde es nicht explizit taggen, sondern anhand von grenzpolygonen in einem präprozessor dem routing algorithmus zuführen. man kann ja feststellen, ob eine straße innerorts oder außerorts ist. in deutschland oder in england. das ist ein klein wenig aufwändig, läuft aber automatisch und muss nur zur datenaufbereitung gemacht werden. nicht für jedes routing. ps: arbeite gerade an boundary.pl wo ich erste erfahrungen mit hirarchien sammeln werde! http://wiki.openstreetmap.org/wiki/Boundaries.pl PPS: denkbar wäre auch ein bot, der das auf osm daten direkt macht. periodischer lauf. dann würde jeder way ein oder mehrere flags oder attribute bekommen, die dann jeder router ohne preprocessing verwenden könnte. my 2cts ciao gerhard On Mon, 2009-05-25 at 15:57 +0200, marcus.wolsc...@googlemail.com wrote: On Mon, 25 May 2009 15:52:03 +0200, Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 25. Mai 2009 15:42 schrieb marcus.wolsc...@googlemail.com: On Mon, 25 May 2009 15:07:34 +0200, Martin Koppenhoefer Für die Maxspeed-Werte gibt es eine Default-Implementierung welche versucht zu erkennen ob man innerhalb oder ausserhalb einer Ortschaft ist und dann abhängig vom highway-Tag eine maximale Geschwindigkeit wählt. anhand von was erkennst Du in der Default-Logik, ob Du innerhalb oder ausserhalb bist? Wäre das explizite Mappen von impliziten Gegebenheiten (also innerhalb, ausserhalb) hier nicht sehr hilfreich? Von Ländern oder Orten? Ort: Es gibt 2 mögliche Adress-Datenbanken (Plugins wie alles andere in TS halt). Diese kennen entweder das Polygon eines Ortes oder Mittelpunkt und angenommenen Radius. Eine Unterscheidung zwischen Orts-Polygon für Adress-Suche und für Verkehrs-Regeln findet (noch) nicht statt. Eine Suche ob ein als Ortschaft getaggter Weg/Node in einem bestimmten Umkreis vorhanden ist wären viel, viel zu aufwendig nur um wärend der Auswertung einer Metrik in der Routen-Berechnung die maximale erlaubte Geschwindigkeit für ein Wegstück, was am Ende warscheinlich eh nicht Teil der Router wird zu ermitteln. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
Am 25. Mai 2009 16:09 schrieb Gary68 g...@gary68.de: also ich würde es nicht explizit taggen, sondern anhand von grenzpolygonen in einem präprozessor dem routing algorithmus zuführen. man kann ja feststellen, ob eine straße innerorts oder außerorts ist. in deutschland oder in england. das ist ein klein wenig aufwändig, läuft aber automatisch und muss nur zur datenaufbereitung gemacht werden. nicht für jedes routing. aber doch nur, wenn sämtl. Ortschilder oder ein entspr. Tag am Weg oder ein Innerorts-Polygon explizit gemappt wurden, ansonsten kann man das nur grob abschätzen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] amenity=shower/toilets und JOSM
Am 25. Mai 2009 16:01 schrieb Falk Zscheile falk.zsche...@googlemail.com: Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? wie angedeutet wird das praktisch von niemandem ausgewertet, man generiert also zumindest derzeit unbrauchbare Daten, daher empfehle ich das eher nicht (auch wenn es offiziell ist). Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne Tricks kombinieren lassen. meine Erfahrung ist eher, dass man die Kombinationen weniger braucht, wenn man detaillierter arbeitet (Ausnahmen gibt es wohl trotzdem). Ein Gebäude nur mit einem Node darzustellen ist nur eine Interimslösung, wenn eine Bank z.B. einen Geldautomaten hat, kann man den POI für atm dorthinsetzen, wo der atm steht, und die Bank dorthin, wo der Eingang ist (oder der Mittelpunkt der Bank, abgesehen davon, dass hier schon atm=yes verwendet wird). Denkbar wäre so eine Art collected-building-relation, die die einzelnen Polygone (für EInheiten innerhalb desselben Gebäudes und evtl. auch für versch. Stockwerke) und Nodes wieder zu einem Gesamtgebäude zusammenfasst. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Hausnummern für Garmin
Moin ! hat einer von Euch schon einmal mir den Hausnummern und den zugehörigen Verbindungslinien für den Garmin experimentiert. Wie habt Ihr das umgesetzt (Overlay ?!?!) und wie sind die Erfahrungen? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Auflisten aller Elementtypen...
hi ! hat einer etwas in der schublade liegen mit dem man die vorkommenden pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des klassenfilters gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, May 25, 2009 at 03:07:34PM +0200, Martin Koppenhoefer wrote: Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite wird ausführlich beschrieben, man sollte z.B. nicht walk sondern maxspeed=UK:walk oder maxspeed=DE:living_street verwenden. Ist das wirklich notwendig? Oder reicht doch schon ein schlichtes walk ohne Länderkürzel? Dasselbe gilt natürlich auf für town und country. de:living_street ergibt sich als einziges maxspeed tag aus highway=living_street und muss nicht gesetzt werden. Ansonsten sind nicht numerische maxspeeds im moment nicht wirklich in benutzung bzw werden nicht ausgewertet ... 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] an die Routing- und sonstigen Entwickler
On Mon, May 25, 2009 at 03:42:02PM +0200, marcus.wolsc...@googlemail.com wrote: Also, für mich: Momentan wird alles in maxspeed was keine Zahl ist konsequent ignoriert. Der einzige Ausnahmefall sind Zahlen mit mph dahinter. Wobei der traveling salesman ja nur die maxspeed werte als hilfe nimmt um zu bestimmt wie schnell man auf der Straße wohl vorwaert kommen mag - d.h. gewichtung der Straßen/Routen. Mich interessiert ja eher wirklich die maximalgeschwindigkeit d.h. speedlimit um sie beim fahren auch anzuzeigen. 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] Wanderkarte für Österreich
Nop ekkeh...@gmx.de wrote: Die Reit- und Wanderkarte (http://topo.geofabrik.de/) wurde erweitert und deckt jetzt die Länder Deutschland und Österreich komplett ab. Super! Fehlt eigeltich nur noch die Schweiz :) Mir ist aufgefallen, dass die Gletscher nicht da sind, die solltest Du aber IMO schon einzeichnen. http://www.openstreetmap.org/?zoom=14lat=47.09225lon=12.29377 http://topo.geofabrik.de/?zoom=14lat=47.09225lon=12.29377 Gruss Sven -- Why are there so many Unix-haters-handbooks and not even one Microsoft-Windows-haters handbook? Gurer vf ab arrq sbe n unaqobbx gb ungr Zvpebfbsg Jvaqbjf! /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ways_with_long_segments / Kontrollierter Luftraum eingetragen?
Hi, nachdem wir ja letzten die Diskussion zum Thema Flugrouten hatten sind jetzt noch Grenzen des kontrollierten Luftraums aufgetaucht: http://www.openstreetmap.org/browse/way/35007658 Die sind nur so grossflaechig ohne nodes das natuerlich der OSM Inspektor Meckert ;) Und auch schon eine Wiki Seite: http://wiki.openstreetmap.org/wiki/DE:Luftraum Macht das wirklich Sinn? 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] amenity=shower/toilets und JOSM
Falk Zscheile schrieb: Der Notlösungen sind mit 2 bekannt: Trennung mit Semikolon. amenity=toilets;shower (wird quasi von keiner Anwendung erkannt/ausgewertet) Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Ja: Es ist schwerer auszuwerten. Außerdem: Spätestens, wenn du einem der Dinge noch Attribute geben willst, funktioniert dein System nicht mehr. Genauso wenig kannst du z.B. mit den kürzlich vorgeschlagenen Etagen-Relationen das Restaurant in den ersten Stock setzen. Darum: Nimm zwei getrennte Nodes, ggf. innerhalb des selben building. Damit ist zwar die Information befindet sich im selben Gebäude schwerer zugänglich, aber die wichtigere Basisinformation leichter zugänglich. Und was ist wohl der wahrscheinlichere Anwendungsfall für eine 0815-Anwendung: Gib mir eine Liste der Gebäude, die sowohl eine Toilette als auch eine Dusche enthalten oder Wo gehts zur nächsten Toilette? Je detaillierter man zukünftig arbeiten wird, desto häufiger wird man Gebäude haben, die mehrere Eigenschaften besitzen, die sich nicht ohne Tricks kombinieren lassen. Das Gebäude hat nicht mehrere Eigenschaften, sondern enthält mehrere (mehr oder weniger getrennte) Einrichtungen. Und so würde ich das auch mappen. Schon verschwinden alle potentiellen Probleme mit Zusatzattributen und bei Auswertungen. Dieser Gedanke, das im gleichen Gebäude liegende oder am selben Laternenpfahl hängende Einrichtungen sich einen Node teilen müssten, macht nur alles unnötig kompliziert. Hängt am selben Pfahl ist eine in der Praxis unwesentliche Information, für die man nicht das Tagging verkomplizieren sollte. Wenns wirklich interessiert, kann man ja eine Relation same_pole machen. ;-) Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Martin Koppenhoefer dieterdre...@gmail.com wrote: Also z15-z17 ähnlich wie ich es in z12-z14 eingebaut habe und wie es in Mapnik ist? Hmmm... Erstmal anderes ausprobieren... ja, mind. für 15 ist es m.E. klar, dass eine Behandlung ähnlich Z14 besser aussähe (eine Linie statt 2), bei 16 und 17 bin ich mir nicht so sicher, wobei da der weisse Hintergrund ein bisschen stört, aber vielleicht kommt man dem ja auch anders bei. Hast Du es schonmal ohne casing versucht? Es war vorher OHNE das weiße casing: man sah den tracktype nicht mehr, das war ja überhaupt der Anlass, dass ich das reinbastelte... ;-) Ich werde gleich mal was umbasteln in z15-z17 Das Problem ist wohl, dass man nur hinzufügen (also überdecken) kann, nicht weglöschen (also so was wie ne Boolsche Subtraktion). Kann man theoretisch schon, klappt praktisch aber nicht wirklich... Besser nicht, wenn's anders geht... MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auflisten aller Elementtypen...
Hi! hat einer etwas in der schublade liegen mit dem man die vorkommenden pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des klassenfilters Bin mir zwar nicht ganz sicher, was Du genau willst, aber vielleicht kann Dir der OSM Composer weiterhelfen. Der kann: - eine Statistik ausspucken wie oft welcher tag verwendet wurde - bestimmte OSM Elemente nach halbwegs genauen Regeln ausfiltern und rausschreiben. bye Nop -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://portal.gmx.net/de/go/dsl02 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Auflisten aller Elementtypen...
prinzip ja - aber ! erst einmal vielen - werde ich mir ansehen. gruß Jan :-) ekkeh...@gmx.de schrieb: Hi! hat einer etwas in der schublade liegen mit dem man die vorkommenden pois ermitteln kann in einer OSM-datei - vielleicht mit vorgabe des klassenfilters Bin mir zwar nicht ganz sicher, was Du genau willst, aber vielleicht kann Dir der OSM Composer weiterhelfen. Der kann: - eine Statistik ausspucken wie oft welcher tag verwendet wurde - bestimmte OSM Elemente nach halbwegs genauen Regeln ausfiltern und rausschreiben. bye Nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fahrbahnen und bicycle=no
Am Montag 25 Mai 2009 11:29:54 schrieb Markus Schaub: Es muss ja noch nicht mal so sein, dass der Radweg dann irgendwo in einen Park o. ä. verschwenkt. Wenn man sich zu einer Hausnummer auf der linken Straßenseite routen lässt, dann wird der Router einen erstmal auf den Radweg auf der rechten Seite schicken, an der Hausnummer vorbeifahren und an der nächsten Kreuzung dann wieder auf dem Radweg zurück. Sollte man das bemerken und direkt vom Radweg auf die andere Straßenseite wollen, ist einem dann evtl. der Weg durch Hecken, Bäume, Zäune etc. versperrt. Wenn man sich an der Stelle auskennt wird man das Routing nicht benutzen oder ignorieren. Wenn man sich an der Stelle nicht auskennt passiert das sowieso, mit oder ohne Navi. Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] boundary.pl v2.0 beta
hi, habe eben die erste v2 beta veröffentlicht: http://wiki.openstreetmap.org/wiki/Boundaries.pl code über meine wiki seite - diverse verbesserungen der funktionen der v1 - zusätzlich die möglichkeit, die hirarchie der boundaries auszugeben (is_in) das speicherproblem bei größeren dateien kommt wohl von den polygonen - mal sehen... ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte für Österreich
Hi! Sven Geggus schrieb: Nop ekkeh...@gmx.de wrote: Mir ist aufgefallen, dass die Gletscher nicht da sind, die solltest Du aber IMO schon einzeichnen. http://www.openstreetmap.org/?zoom=14lat=47.09225lon=12.29377 http://topo.geofabrik.de/?zoom=14lat=47.09225lon=12.29377 Gute Idee. Sind aufgenommen. bye nop ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] tracks in osmarender (16-17)
Am 25. Mai 2009 18:33 schrieb Heiko Jacobs heiko.jac...@gmx.de: Kann man theoretisch schon, klappt praktisch aber nicht wirklich... Besser nicht, wenn's anders geht... damit könnte man die gestrichelte Doppellinie erzeugen ohne ein 3. weisses Innencasing zu benötigen, d.h. mit dem ersten Casing in transparent würde es gehen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Selbstbezug in Relation
Hallo, ich bin heute über eine Relation gestolpert, die sich selbst als Mitglied enthielt: 56873. Erst nach vielen missglückten Hochladeversuchen, die unter anderem eine Änderung an dieser Relation enthielten, bei denen JOSM einfach nichts mehr tat, habe ich diese Relation als Übeltäter ausmachen können. Mit JOSM (tested) konnte ich dann diesen Selbstbezug auflösen, JOSM (latest) lief sich immer mit 100% CPU-Last fest. Lange Rede, kurzer Sinn: Ich denke solche Endlosschleifen sind eher nicht gewollt, zumindest fällt mir kein Szenario ein, wo das sinnvoll wäre. Besteht die Möglichkeit, solche Fehler abzufangen, bevor sie in die Datenbank kommen, entweder über die API oder Plugins in den Editoren? Zumindest würde ich mir eine Warnung wünschen, daß solche Konstrukte zu Problemen führen können. Grüße, Carsten 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] an die Routing- und sonstigen Entwickler
Am Monday 25 May 2009 schrieb Martin Koppenhoefer: Hoffentlich seid Ihr nicht alle von der bisherigen Maxspeed-Debatte abgeschreckt, aber eine kleine Frage hätte ich nochmal: im Laufe der Diskussion hatte ich gesagt, dass man die Länder, in denen die Straßen liegen, per Polygon durch Vorverarbeitung klären sollte. Ich bin mir allerdings nicht ganz sicher, ob das wirklich Stand der Technik ist (ist ja auch in anderem Zusammenhand relevant). Auf der Maxspeed-Seite wird ausführlich beschrieben, man sollte z.B. nicht walk sondern maxspeed=UK:walk oder maxspeed=DE:living_street verwenden. Ist das wirklich notwendig? Oder reicht doch schon ein schlichtes walk ohne Länderkürzel? Dasselbe gilt natürlich auf für town und country. rein technisch ist die polygon-methode zwar sicherlich machbar, aber ich wuerde das tag mit laenderkuerzel bevorzugen. das mag zwar redundant sein, aber weh tut die zusatzinfo auch nicht. desweiteren laesst sich das ganze wesentlich einfacher auswerten, finde ich... 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] amenity=shower/toilets und JOSM
Am Monday 25 May 2009 schrieb Martin Koppenhoefer: Am 25. Mai 2009 16:01 schrieb Falk Zscheile falk.zsche...@googlemail.com: Spricht außer des für OSM etwas unüblichen Schemas etwas gegen diese Variante? Beispielsweise im Zusammenhang mit der Auswertung durch die Renderer? wie angedeutet wird das praktisch von niemandem ausgewertet, man generiert also zumindest derzeit unbrauchbare Daten, daher empfehle ich das eher nicht (auch wenn es offiziell ist). naja, fuer manchen dinge ist das schon sinnvoll so. da aber leider der alte weg mit zwei tags nicht mehr geht, muss man es wohl so machen... zumindest auf meiner TODO-liste steht die unterstuetzung schon seit geraumer zeit ;-) 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] tracks in osmarender (16-17)
Moin Neue Version seit einigen Stunden für z15-z17 online mit nun leicht brauner Füllung, unterschiedlich stark je nach tracktype und zoom plus leichte Transparanz am Rand... Martin Koppenhoefer dieterdre...@gmail.com wrote: Am 25. Mai 2009 18:33 schrieb Heiko Jacobs heiko.jac...@gmx.de: Kann man theoretisch schon, klappt praktisch aber nicht wirklich... Besser nicht, wenn's anders geht... damit könnte man die gestrichelte Doppellinie erzeugen ohne ein 3. weisses Innencasing zu benötigen, d.h. mit dem ersten Casing in transparent würde es gehen. Ja. nennt sich mask-class in den Osmarender-styles, geht darin offenbar für Tunnel, aber bisher nur dafür. Ein weiteres Mal begegnete es mir bei der Suche nach einem unerklärbaren Fehler vor längerer Zeit. Da hatte es schon wer anderes für eine andere Anwendung auch verwenden wollen, erfolglos, hatte unerwünschte Seiteneffekte. Und auch ich spielte schon erfolglos 2x mit diesem Feature. Ist mir ehrlich gesagt zu viel fruchtlose Arbeit, die da versandet... Das gewünschte soll evtl. der nächste SVG-Standard können. Ich stöberte darin mal rum und entdeckte dort solche Strichmuster quer zu den bisherigen Strichlierungen als Nice-to-have oder so erwähnt.. MfG Heiko Jacobs Z! IRCnet Mueck -- Douglasstr. 30, D-76133 Karlsruhe fon +49 721 24069 fax 2030542 Geo-Bild Ing.büro geo-bild-KA.de Internet-Service auch-rein.de Couleurstud. Infos cousin.de VCD, umweltverkehr KA umverka.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Routing - Separater Radweg und andere Probleme
Moin, nach einigem Lesen alter Diskussionen über das Erstellen eines von der Straße abgetrennten Radweges (etwa durch simplen Bordstein), bin ich noch immer nicht fähig mich zu entscheiden. Soll ich nun Radwege entlang von Straßen möglichst als eigenständige Wege (highway=cycleway) erfassen, oder sollen diese einfach nur als zusätzliches Attribut an die Straße geheftet werden (bspw. highway=secondary + cycleway=track) ? Bei straßenbegleitenden Radwegen, die nur durch eine Markierung von der Fahrbahn getrennt sind, ist es ja eindeutig mit cycleway=lane. Aber bei dem anderen Fall? Spontan würde ich mich für den Separaten entscheiden, aufgrund der Vorteile wie: -Radfahrer kann problemlos in eine Einbahnstraße abbiegen -Radfahrer hat andere Fahr/-Abbiegeregeln als Autofahrer, bspw. an Kreuzungen (naja eher uninteressant für Radroutenplaner?) -Zusätzliche Tags (Oberfläche, Breite..) für Fahrradweg verfügbar, die man so in der einfachen Form hätte nicht an die Straße (wenn Fahrradweg als Tag an highway=secondary/...) anbringen können. -Angabe des Fahrradweg-Typs; angeben was es genau ist(Gemeinsamer Fuß/-Radweg, getrennt,..) ? -weitere?? Was mich aber so verwundert ist, dass sehr viele gegen das Vorgehen des zusätzlichen Erstellen von Radwegen neben der Straße sind, warum?, welche großen Nachteile existieren denn? Meine 2. Frage: Worauf muss ich noch achten, wenn ich einen Radrouting erstellen will, also welche Probleme oder Szenarien könnte es noch geben? (mein Gott, sind hier viele ? drin..) Grüße von der Erde!!! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Access-Tags für Radfahrer
Moin, für Radfahrer gelten zwar formal die üblichen Verkehrsregeln und Beschilderungen, aber diese sind oft lückenhaft, widersprüchlich oder praxisfern. Oft muss man intuitiv entscheiden, ob ein Weg fahrradgeeignet ist oder nicht. Allerdings ist es schwierig, das in OSM-Tags umzusetzen. Entsprechend enttäuschend verliefen meine Versuche mit Fahrradroutung auf meinem eTrex Vista mit Computerteddys Karten. Die Einstellung Fußgängerrouting brachte bessere Resultate. Wie wollen wir grundsätzlich vorgehen: die Beschilderung möglichst exakt wiedergeben und es dem Routern/Auswerteprogrammen überlassen, diese sinnvoll zu interpretieren, oder die Eignung zum Radfahren nach eigener Anschauung eingeben? Einige Beispiele: Eine fahrradgeeignete Strecke mit Radwegweisern trägt 100m vor der Einmündung ein Verbotsschild für Radfahrer mit einem Zusatzschild Radfahrer absteigen. Der Weg führt dort recht steil bergab. In Gegenrichtung ist radfahren erlaubt, aber wegen der Steigung recht schwierig. Welche Tags gibt man dort ein, so dass der Router die schöne Strecke nicht meidet: bicycle:forward=no, speed:bicycle= walk oder nur note=Radfahrer absteigen? Nach einem tödlichen Fahrradunfall auf einer Kanalhochbrücke sind in Kiel einige Brücken wegen zu niedriger Geländer für Radfahrer gesperrt. Einige sind als Fußwege andere als kombinierte Rad- und Fußwege mit dem Zusatz Radfahrer absteigen gekennzeichnet. Ein Fahrradrouter sollte trotzdem keinen großen Umweg planen um wenige Sekunden Schiebestrecke zu vermeiden. Viele Einbahnstraßen sind in Gegenrichtung für Radfahrer freigegeben. Allerdings haben alle Straßen an der Einmündung Abbiegeverbote zur Einbahnstraße ohne Zusatz Radfahrer frei. Formal müsste man das Rad vermutlich um die Ecke schieben. Ein Feldweg mit Verbot für Fahrzeuge aller Art, landwirtschaftlicher Verkehr frei ohne Radfahrer frei, in den aber neu aufgestellte Fahradwegweiser auf beiden Seiten hineinzeigen: bicycle=no, bicycle=permissive oder bicycle=inconsistent? Ein Weg, der an einem Ende als Fußweg am anderen Ende aber aber gar nicht beschildert ist Ein gepflegter, nur knapp 2m breiter Kiesweg im Ortsbereich ohne Beschilderung (vom Bauchgefühl ein Fussweg, den man vorsichtig mit dem Rad befahren kann): path, footway, footway mit bicycle=yes oder cycleway? Ein Waldweg (kein Trampelpfad, aber für mehrspurige Fahrzeuge ungeeignet) ohne Beschilderung: path, footway, footway mit bicycle=yes oder cycleway? Ein für Renn- und Tourenräder ungeeigneter Waldweg ohne Verbotsschilder: path, path mit bicycle=no oder footway Treppen auf Radstrecken (vor kurzem in einem anderen Thread), etc. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] All-in-One Deutschland - mit Garmin eTrex
Am Montag, 25. Mai 2009 12:56:09 schrieb Christian von Rotenhan: Am 25.05.2009 11:38 Uhr, schrieb Holger Blum: Merkwürdig ist eben nur, dass der hinweg klaglos und schnell berechnet wird (sind ja nur ca 50 km) und beim Rückweg diese Abstürze auftreten. Ich kann in den Straßen die ich befahre mit JOSM und mit potlach nichts verdächtiges finden... Hallo, ich habe das gleiche Problem mit einem Colorado 300. Es muss (auch) an der Garmin-SW liegen. Meistens sagt er Datenfehler, dann kann man immerhin noch Wegepunkte zwischensetzen, aber manchmal stürzt er ab und kann nur mit Kaltstart wiederbelebt werden, was mit dem Verlust aller nicht gesicherten eigenen Daten verbunden ist. Abhilfe ist eigentlich immer, zusätzliche Wegepunkte einzufügen. Ich vermute, dass das Navi einfach zu viele Alternativen findet. Für längere Fahrten sollte man wohl eine Karte ohne Fußwege etc benutzen, um das Datenvolumen kleiner zu halten. Gruß, Wolfgang ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Access-Tags für Radfahrer
Stephan Wolff schrieb: Ein Feldweg mit Verbot für Fahrzeuge aller Art, landwirtschaftlicher Verkehr frei ohne Radfahrer frei, in den aber neu aufgestellte Fahradwegweiser auf beiden Seiten hineinzeigen: bicycle=no, bicycle=permissive oder bicycle=inconsistent? Und wenn die Stadt sich Mühe gibt, dann kommen solche Monster dabei heraus: http://www.addicks.net/gallery/osm/P5180069 -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] an die Routing- und sonstigen Entwickler
On Mon, 25 May 2009 17:07:24 +0200, Florian Lohoff f...@rfc822.org wrote: On Mon, May 25, 2009 at 03:42:02PM +0200, marcus.wolsc...@googlemail.com wrote: Also, für mich: Momentan wird alles in maxspeed was keine Zahl ist konsequent ignoriert. Der einzige Ausnahmefall sind Zahlen mit mph dahinter. Wobei der traveling salesman ja nur die maxspeed werte als hilfe nimmt um zu bestimmt wie schnell man auf der Straße wohl vorwaert kommen mag - d.h. gewichtung der Straßen/Routen. Nicht ganz. Die Gewichtung macht die jeweilige Metrik. Wenn sich die Metrik für die Fahrtzeit/Geschwindigkeit interessiert kann sie (muss aber nicht) die maximale erlaubte Geschwindigkeit erfragen. So eine Metrik wie kürzeste Strecke oder scenic tour z.B. interessiert die Geschwindigkeit nicht. Ausserdem wird die maximale erlaubte Geschwindigkeit immer bei der Berechnung der ETA berücksichtigt. (Wenn die gewählte Metrik Fahrtzeiten berechnen kann wird das Minimum aus dieser Fahrzeit und dem Maximum genommen, sonst das Gleiche mit einer fest vorgegebenen Zeit-basierenden Metrik.) Mich interessiert ja eher wirklich die maximalgeschwindigkeit d.h. speedlimit um sie beim fahren auch anzuzeigen. Lässt sich im MetricsPanel einbauen. Ist dort auch schon vorgesehen. Marcus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] Statistiche
Ciao *, ho letto http://wiki.openstreetmap.org/index.php/WikiProject_Italy/Stats e sembra che i dati siano quantomeno datati :) Come sono stati generati quei dati? Qualche script? In particolare, mi interesserebbe creare delle sottopagine Stats dei sottoprogetti cui partecipo attivamente (Mazara del Vallo, Palermo, Sicilia), così da avere più granularità. Ciao, David -- . ''`. Debian maintainer | http://wiki.debian.org/DavidPaleino : :' : Linuxer #334216 --|-- http://www.hanskalabs.net/ `. `'` GPG: 1392B174 | http://snipr.com/qa_page `- 2BAB C625 4E66 E7B8 450A C3E1 E6AA 9017 1392 B174 signature.asc Description: PGP signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: GPS in auto
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Federico Cozzi Sent: venerdì 22 maggio 2009 9.59 To: openstreetmap list - italiano Subject: Re: [Talk-it] R: GPS in auto Dai Garmin non si possono estrarre i RINEX a registrazione avvenuta - l'unica possibilità sembra quella di estrarli durante la registrazione. Forse altre antenne GPS sono più furbe da questo punto di vista? Per i Tomtom esistono applicazioni in grado di loggare le sentenze NMEA, ad esempio TTTracklog [1]. Per i Garmin credo che l'unica sia fare come dici, cioè settare l'interfaccia nel formato NMEA e usare un logger esterno. Alla fine resta il problema di chi ci fornisce i dati per la correzione. E poi tanto per gli errori dovuti a riflessioni (multipath), che sono il problema più frequente, la correzione RINEX non serve a nulla. [1] http://www.opentom.org/TTTracklog Ciao! ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Bicitalia
Chi ha partecipato ieri a qualche evento di bicitalia? ciao Luca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
Vedi subject: come si fa? Ho scaricato l'SVG degli shelter (bivacchi) e l'ho modificato in modo da ottenere un'icona degli alpine_hut (rifugi alpini). A differenza degli shelter è una casa chiusa (cioè ha anche il pavimento) in modo da dare l'idea di un edificio ed è rossa anziché nera, perché - se non ricordo male - su alcune cartine i rifugi sono rossi. A dire la verità spesso i rifugi sono metà trasparenti e metà rossi se aperti solo in alcuni periodi dell'anno, tutti rossi se sono aperti sempre - ma mi sembra che su OSM non sia facile fare questa distinzione, quindi ho lasciato l'interno tutto trasparente per non dare indicazioni errate. Idee: 1. qualcuno esperto di SVG può dargli una sistemata? L'ho fatto in 5 minuti con Inkscape 2. qualcuno con accesso a SVN può metterlo su? Penso che dovrebbe finire qui: http://svn.openstreetmap.org/applications/rendering/osmarender/stylesheets/symbols/ 3. qualcun altro ancora sa modificare gli stylesheet di Osmarendere in modo che appaia? Grazie, Federico attachment: alpine_hut.svg___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
per quelli chiusi d'inverno prova a tratteggaire il segno nei tratti rettilinei del disegno... non so se ci sono i tag adeguati, ma non è certo impossibile inserire questo tipo di dati, caso mai proponi te il tag... è comunque un'informazione fondamentale per un corretto utilizzo della mappa, trovarsi davanti un rifugio chiuso con -10 gradi a 3000m di quota non deve essere bello :D -- Bigshot - Gianluca Il 25 maggio 2009 15.33, Federico Cozzi f.co...@gmail.com ha scritto: Vedi subject: come si fa? Ho scaricato l'SVG degli shelter (bivacchi) e l'ho modificato in modo da ottenere un'icona degli alpine_hut (rifugi alpini). A differenza degli shelter è una casa chiusa (cioè ha anche il pavimento) in modo da dare l'idea di un edificio ed è rossa anziché nera, perché - se non ricordo male - su alcune cartine i rifugi sono rossi. A dire la verità spesso i rifugi sono metà trasparenti e metà rossi se aperti solo in alcuni periodi dell'anno, tutti rossi se sono aperti sempre - ma mi sembra che su OSM non sia facile fare questa distinzione, quindi ho lasciato l'interno tutto trasparente per non dare indicazioni errate. Idee: 1. qualcuno esperto di SVG può dargli una sistemata? L'ho fatto in 5 minuti con Inkscape 2. qualcuno con accesso a SVN può metterlo su? Penso che dovrebbe finire qui: http://svn.openstreetmap.org/applications/rendering/osmarender/stylesheets/symbols/ 3. qualcun altro ancora sa modificare gli stylesheet di Osmarendere in modo che appaia? Grazie, Federico ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Federico Cozzi f.co...@gmail.com: Vedi subject: come si fa? hai accesso al svn? Se non un ticket nel trac. Ho scaricato l'SVG degli shelter (bivacchi) e l'ho modificato in modo da ottenere un'icona degli alpine_hut (rifugi alpini). l'icone mi piace, ma il senso che dai a shelter come bivacco mi sembra un po strano (forse ho capito male lo significato della parola): con shelter ho associato un qualsiasi riparo, mentre un rifugio alpino lo vedo come una attività che ti offre anche un servizio di albergo con ristorante semplice. Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Federico Cozzi Sent: lunedì 25 maggio 2009 15.34 To: openstreetmap list - italiano Subject: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender? Ho scaricato l'SVG degli shelter (bivacchi) e l'ho modificato in modo da ottenere un'icona degli alpine_hut (rifugi alpini). Ottima iniziativa! A differenza degli shelter è una casa chiusa (cioè ha anche il pavimento) in modo da dare l'idea di un edificio ed è rossa anziché nera, perché - se non ricordo male - su alcune cartine i rifugi sono rossi. A dire la verità spesso i rifugi sono metà trasparenti e metà rossi se aperti solo in alcuni periodi dell'anno, tutti rossi se sono aperti sempre - ma mi sembra che su OSM non sia facile fare questa distinzione, quindi ho lasciato l'interno tutto trasparente per non dare indicazioni errate. La distinzione si potrebbe fare usando il tag opening_hours, che a dispetto del nome si può usare anche per indicare le date di inizio e fine dei periodi di apertura o chiusura. Anche se in realtà la sintassi non è semplicissima, e non sarebbe banale distinguere i periodi di chiusura importanti da quelli di pochi giorni. E poi resterebbe il dubbio di come disegnare i rifugi per cui nulla è specificato (default sempre aperti?). Un altro dubbio che ho riguarda i posti dove viene servito solo da mangiare, spesso chiamati 'ristoro', ma altrettanto spesso anche 'rifugio'. Io li taggo come alpine_hut anziché come ristorante, per indicare che si tratta di ristoranti accessibili solo agli escursionisti, ma non sono sicuro che sia corretto, anche perché così non ce modo di distinguerli dalle strutture i cui si può anche dormire. Forse ci manca proprio il tag relativo al ristoro, che è rispetto al ristorante l'equivalente di ciò che è il rifugio rispetto all'albergo. Le carte della Kompass per esempio usano le casette in rosso, con le seguenti varianti: - disegnato solo il perimetro per i ristori (tipo la tua, senza neppure il tetto pieno) - il quadrato sotto il tetto in rosso pieno per i rifugi aperti tutto l'anno - il quadrato sotto il tetto diviso dalla diagonale (dal vertice in basso a sinistra al vertice in alto a destra), con solo il triangolo inferiore in rosso pieno. - tutto rosso pieno, compreso il tetto, per gli alberghi (questo caso non ci interessa) Comunque avere i rifugi visibili sulla mappa, anche se indistinti, sarebbe già un bel passo avanti. Ciao. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Confini amministrativi regione Lombardia
Ho dato un'occhiata agli shape file dei confini della regione Lombardia, e ho notato che sono fatti diversamente da quelli dell'ISTAT. Sono definiti tutti i tratti di linee di confine tra due comuni, ma non c'è un riferimento ai comuni separati dalla linea. C'è solo un identificativo univoco (FID, numero intero), che mi sembra che aumenti man mano che ci si sposta verso nord, a partire dai numeri bassi per le linee di confine più a sud. Qualcuno sa se i nomi dei comuni separati da ciascun valore FID sono documentati da qualche parte, o ha idea se sia possibile desumerli per 'vicinanza' dai confini dell'Istat (o meglio ancora di OSM, dove le linee sono già spezzate come nella CT della Lombardia)? Idee sul procedimento di importazione e sostituzione dei confini Istat? Ciao. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Il Gps ha solo dodici mesi di vita
La cosa sembra assurda, ma da quanto ho letto da pi? parti la situazione sembrerebbe davvero grave, potrebbe essere addirittura gi? troppo tardi per intervenire e rimediare ai ritardi. Che dire... vedremo, non abbiamo da aspettare molto a lungo. Chiss? che contenti che sono quelli di TomTom, Garmin, ecc. ma va la dai. immagina un mondo senza gps e senza Ferrari in F1. Tutte notizie ad elevato impatto mediatico ma senza un reale seguito. gianluca ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] R: R: Piazze e strade
-Messaggio originale- Da: talk-it-boun...@openstreetmap.org [mailto:talk-it-boun...@openstreetmap.org]per conto di Martin Koppenhoefer Inviato: domenica 24 maggio 2009 22.17 A: openstreetmap list - italiano Oggetto: Re: [Talk-it] R: Piazze e strade [...] ho fatto una cosa poco diddattica e ho messo mano io per darti un esempio, perdonami. Un esempio vale più di mille parole: Ora è chiarissimo! Ciao e Grazie Fabrizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Gianluca De Rossi bigshot4e...@gmail.com: per quelli chiusi d'inverno prova a tratteggaire il segno nei tratti rettilinei del disegno... Come dice più sotto Alberto Nogaro, il simbolo standard (almeno all'interno delle Tobacco) è un quadrato diviso con la diagonale. non so se ci sono i tag adeguati, ma non è certo impossibile inserire questo tipo di dati, caso mai proponi te il tag... Non facciamo il passo più lungo della gamba :-) Per il momento sarei contento che OSM mostrasse i rifugi in maniera confusa: almeno si vedrebbero, ora sono invisibili! è comunque un'informazione fondamentale per un corretto utilizzo della mappa, trovarsi davanti un rifugio chiuso con -10 gradi a 3000m di quota non deve essere bello :D Premesso che solo un pazzo pianificherebbe un'escursione con OSM *allo stato attuale*, questo è secondo me uno di quei casi in cui OSM, così raffinato, funziona male. So che c'è il tag opening_hours ma qui c'è bisogno di una regola semplice (scrivibile nell'xml di osmarender) che distingua tra i rifugi sempre aperti e quelli che hanno aperture stagionali. Finché non ci sarà un tag adeguato preferirei che il simbolo fosse volutamente impreciso, cioè non fosse identico a nessuno di quelli convenzionali. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Alberto Nogaro bartosom...@yahoo.it: La distinzione si potrebbe fare usando il tag opening_hours, che a dispetto del nome si può usare anche per indicare le date di inizio e fine dei periodi di apertura o chiusura. Anche se in realtà la sintassi non è semplicissima, e non sarebbe banale distinguere i periodi di chiusura importanti da quelli di pochi giorni. E poi resterebbe il dubbio di come disegnare i rifugi per cui nulla è specificato (default sempre aperti?). Esatto: nel dubbio, meglio essere imprecisi. Non vorrei che un pazzo vedesse un simbolo standard (rifugio sempre aperto) e usasse l'informazione per pianificare un'escursione. Un altro dubbio che ho riguarda i posti dove viene servito solo da mangiare, spesso chiamati 'ristoro', ma altrettanto spesso anche 'rifugio'. Io li taggo come alpine_hut anziché come ristorante, per indicare che si tratta di ristoranti accessibili solo agli escursionisti, ma non sono sicuro che sia corretto, anche perché così non ce modo di distinguerli dalle strutture i Personalmente non sono d'accordo, ma ti perdono ;-) Secondo me il fatto che un posto di ristoro sia raggiungibile solo dagli escursionisti è ovvio da dove si trova. Se metti un amenity=restaurant sulla vetta del Monte Bianco nessuno si aspetta di arrivarci in macchina :-) Secondo me un rifugio è un posto dove si può mangiare ma soprattutto dormire. Di solito sono gestiti dal CAI (ma non necessariamente). Le carte della Kompass per esempio usano le casette in rosso, con le seguenti varianti: Il tetto è triangolo o spiovente? Potrei migliorare l'icona e farlo a triangolo (più semplice, più universale) - disegnato solo il perimetro per i ristori (tipo la tua, senza neppure il tetto pieno) - il quadrato sotto il tetto in rosso pieno per i rifugi aperti tutto l'anno - il quadrato sotto il tetto diviso dalla diagonale (dal vertice in basso a sinistra al vertice in alto a destra), con solo il triangolo inferiore in rosso pieno. Qual è un buon compromesso tra i tre? Indicare con precisione se stagionale o aperto tutto l'anno non mi sembra corretto con i dati che abbiamo. Potrei fare il tetto pieno più evidente (a triangolo) e lasciare trasparente il centro della casa. Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Martin Koppenhoefer dieterdre...@gmail.com: Vedi subject: come si fa? hai accesso al svn? Se non un ticket nel trac. Si può allegare anche un file? Ora provo... l'icone mi piace, ma il senso che dai a shelter come bivacco mi sembra un po strano (forse ho capito male lo significato della parola): con shelter ho associato un qualsiasi riparo, mentre un rifugio alpino lo vedo come una attività che ti offre anche un servizio di albergo con ristorante semplice. Sì infatti questo è un altro baco di OSM. Sulle Alpi (italiane) esistono grosso modo due tipi di edifici: a. rifugi b. bivacchi La differenza tra i rifugi e i bivacchi è che i rifugi hanno uno staff, e quindi hanno un sistema di prenotazioni, un ristorante, delle tariffe ecc. Sono di solito molto più grandi dei bivacchi. I bivacchi invece sono senza staff: quando arrivi ti trovi solo le mura e il tetto. A volte hanno un sistema di prenotazioni altre volte no; a volte c'è la chiave oppure no; in ogni caso ti devi portare appresso il cibo. Allo stato attuale su OSM i rifugi corrispondono agli alpine_hut. I bivacchi, purtroppo, agli shelter. (la parola corretta in inglese sarebbe bothy, e la pagina degli shelter dice che si può usare shelter per i bothy). Il problema è che osmarender disegna gli shelter (i bivacchi nel nostro caso) ma non disegna i rifugi. Questo si vede ad es. in Val d'Aosta, dove un paio di mesi fa ho importato (dal sito CAI) tutti i rifugi e i bivacchi. Ora su osmarender si vedono i rifugi ma non i bivacchi, il che è un po' assurdo perché comunque sono più frequentati i rifugi dei bivacchi. La mia proposta è quindi di dare un'icona ai rifugi. Almeno in Val d'Aosta si vedrebbero entrambi... Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Federico Cozzi f.co...@gmail.com: hai accesso al svn? Se non un ticket nel trac. Si può allegare anche un file? Ora provo... Ecco qui: http://trac.openstreetmap.org/ticket/1860 Votate votate votate! (si può votare? non lo so...) Ho allegato l'icona rimaneggiata (ora il tetto è triangolare, più semplice) Ciao ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Mapping Party - Bergamo
Salve a tutti, ci sono osmapper della bergamasca che avrebbero voglia di organizzare un mapping party? In particolare, io vivo in Val Seriana ed a giudicare dalla Mappa di OSM, un party da queste party sarebbe davvero l'ideale :) A presto! -- Antonio Quartulli http://www.ritirata.org/ordex ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
-Original Message- From: talk-it-boun...@openstreetmap.org [mailto:talk-it- boun...@openstreetmap.org] On Behalf Of Federico Cozzi Sent: lunedì 25 maggio 2009 19.03 To: openstreetmap list - italiano Subject: Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender? Secondo me il fatto che un posto di ristoro sia raggiungibile solo dagli escursionisti è ovvio da dove si trova. Se metti un amenity=restaurant sulla vetta del Monte Bianco nessuno si aspetta di arrivarci in macchina :-) Vero, ma se il nome anzichè sulla mappa lo leggo su un elenco, dedurre se l'accessibilità è semplice non è immediato. Comunque sono d'accordo con te che il rifugio in cui si dorme debba essere distinguibile dal ristoro. Mapperò i ristori come ristorante, anche se non mi dispiacerebbe che esistesse un tag più specifico (abbiamo la distinzione tra fast-food e ristorante, ci potrebbe stare anche una categoria per i ristori). Un motivo per cui alle volte li mappo come rifugio è che non so se offrono alloggio o meno: nel senso che il posto sarebbe anche attrezzato per i pernottamenti, ma a volte il gestore lo tiene aperto solo come ristorante. Il tetto è triangolo o spiovente? Potrei migliorare l'icona e farlo a triangolo (più semplice, più universale) Ho controllato Tabacco, Kompass ed IGC: il tetto è sempre un triangolo sporgente rispetto al corpo. Se è anche più semplice da fare tanto meglio. Qual è un buon compromesso tra i tre? Indicare con precisione se stagionale o aperto tutto l'anno non mi sembra corretto con i dati che abbiamo. +1 Potrei fare il tetto pieno più evidente (a triangolo) e lasciare trasparente il centro della casa. Mi sembra una buona idea, resta una via di mezzo tra il tutto pieno (che potrebbe essere un albergo) ed il tutto vuoto (che potrebbe essere un bivacco). Ciao. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Aggiungiamo gli alpine_hut a Osmarender?
2009/5/25 Federico Cozzi f.co...@gmail.com: 2009/5/25 Federico Cozzi f.co...@gmail.com: hai accesso al svn? Se non un ticket nel trac. Si può allegare anche un file? Ora provo... Ecco qui: http://trac.openstreetmap.org/ticket/1860 Votate votate votate! (si può votare? non lo so...) non, non si puo votare. Si puo aggiungere [patch] oppure [icon] davanti al sogetto cosí attira più attrazione. [patch] lo metti se hai creato un diff. Si scaricano le regole attuali dal svn, poi si modificanno e alla fine calcoli la differenza allo stato di prima. Questo diff si puo applicare facilmente. Se vuoi spingere di più, crei anche un render di esempio con lo styleset modificato (prima, dopo). Cosí si capisce subitò l'impatto delle modifiche. Anche senza questo diff probabilmente qn. usa l'icone, crea lui le regole ed il diff, ma è più impegno, quindi forse dura di più. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Il Gps ha solo dodici mesi di vita
Il 25/05/2009 17:40, Gianluca Frare ha scritto: Tutte notizie ad elevato impatto mediatico ma senza un reale seguito. Notizia effettivamente già ridimensionata: http://www.zeusnews.com/index.php3?ar=stampacod=10368 -- .' `. | Registered Linux User #443882 |a_a | | http://counter.li.org/ .''`. \_)__/ +--- : :' : /( )\ ---+ `. `'` |\` /\ Registered Debian User #9 | `- \_|=='|_/ http://debiancounter.altervista.org/ | ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-es] FOSS4G Press Release: Academic track at FOSS4G 2009, two weeks till abstracts due, workshops announced
Sydney, Australia. 25 May 2009. The Academic community and FOSS4G organising committee are pleased to add an academic track to the FOSS4G conference, and remind interested presenters that there are only two weeks left for FOSS4G abstract submissions! Abstract submission closes 8 June 2009. (Note the deadline has been extended a week.) http://2009.foss4g.org/presentations/. The Free and Open Source Software for Geospatial conference (FOSS4G), is being held in Sydney, Australia October 20-23. http://2009.foss4g.org. The academic track will act as an inventory of current research topics and promote cooperative research between OSGeo developers and the academia. The academic track is the right forum to highlight the most important research challenges and trends in the domain, and let them became the basis for an informal OSGeo research agenda. It will foster interdisciplinary discussions in all aspects of the geospatial and free and open source domains. It aims to promote networking between participants, initiate and favour discussions regarding cutting-edge technologies in the field, exchange research ideas and promote international collaboration. All submissions to the academic track must be original unpublished work written in English that is currently not under review elsewhere. The submitted papers will be thoroughly reviewed by two to three members of the international scientific committee and refereed for their quality, originality and relevance. For further information, please read the full call for research papers. http://wiki.osgeo.org/wiki/FOSS4G_2009_Call4papers. Submit your Abstracts now Only two weeks to submit your abstracts and secure your presentation slot. Presentations are open to all and comprises a 30 minute slot which includes hand-over, introductions and 5 minutes for questions. Presentations will be selected which have a strong Open Geospatial theme to them. We are keen to hear about your experiences, both technical and non technical. While the technology is a key part of the conference, in 2009 we are very keen to have a good selection of case studies and business case type presentations. Workshops and tutorials announced Workshops and tutorials have been finalised and descriptions are now online at: http://2009.foss4g.org/workshops/ http://2009.foss4g.org/tutorials/ Stay Informed Join the FOSS4G announcement email list: http://lists.osgeo.org/mailman/listinfo/foss4g2009-announce or our twitter feed: http://2009.foss4g.org/contacts/ Media Sponsors * Position Magazine: http://www.positionmag.com.au/ * Asian Surveying and Mapping Newsletter: http://www.asmmag.com * Geoconnexions Magazine: http://www.geoconnexion.com/ * Directions Magazine: http://directionsmag.com/ * GIS Development: http://gisdevelopment.net/ * Baliz Media: http://www.BALIZ-MEDIA.com/ For more details about this press contact us http://2009.foss4g.org/contacts/ or contact: Cameron Shorter, Chair of the FOSS4G Organising Committee and Geospatial Systems Architect at LISAsoft tel +61-2-8570-5050 c a m e r o n . s h o r t e r @ l i s a s o f t . c o m -- Jorge Gaspar Sanz Salinas Ingeniero en Geodesia y Cartografía http://wiki.osgeo.org/wiki/Jorge_Sanz ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] Routen (traces) vom Friday Night Skating
Hallo, um Deine Routen online zu visualisieren gibt es auch Lösungen wie z.Bsp. www.bikemap.net (gibt's auch als wandermap und skatemap). Da kannst Du dann einfach Deine gpx-Datei hochladen und anzeigen lassen. Als Karte kann man sowohl openstreetmap als auch opencyclemap wählen (was beides die gleichen Daten sind, allerdings unterschiedlich gerendert, d.h. bei opencyclemap werden Radwege besonders hervorgehoben). Gruß Thomas ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
