Re: [OSM-talk] Potlatch localisation
Richard, On Thu, Jun 05, 2008 at 12:43:46AM +0100, Richard Fairhurst wrote: I'd like to offer Potlatch in native languages - so a German-speaking user gets the prompts and tooltips in German, a French user in French, and so on. It would be a good thing to have at any point, but especially considering the current influx of German speakers. I'm very happy to do the coding, but can't manage the languages (apart from Medieval Welsh and some very bad French). So offers of translation would be gratefully accepted. There's a trac ticket at http://trac.openstreetmap.org/ticket/955 and I can supply the relevant text on request. If there is a gettext .po file or similar in subversion somewhere I could imagine people would contribute translations. On a related note: I created the current openstreetmap.de website which lacks edit support. Does it make sense to integrate Potlatch into that web page? Would it be hard to do? On the one hand I would like to make it as easy and seemless as possible for German users. On the other hand I don't want duplication of effort and multiple similar but different web pages doing essentially the same thing. Jochen -- Jochen Topf [EMAIL PROTECTED] http://www.remote.org/jochen/ +49-721-388298 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch localisation
i can help with spanish sergio Richard Fairhurst escribió: I'd like to offer Potlatch in native languages - so a German-speaking user gets the prompts and tooltips in German, a French user in French, and so on. It would be a good thing to have at any point, but especially considering the current influx of German speakers. I'm very happy to do the coding, but can't manage the languages (apart from Medieval Welsh and some very bad French). So offers of translation would be gratefully accepted. There's a trac ticket at http://trac.openstreetmap.org/ticket/955 and I can supply the relevant text on request. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] More European countries on download.geofabrik.de
Hi, I have now added most of the missing European countries to download.geofabrik.de so you can get daily planet extracts for them. Portugal, Monaco, Greece, Belarus, Slovakia and the Czech republic are among those added. Unfortunately my national border data was too old to include Serbia/Croatia. Hakan, if you read this then you might want to compare my Turkey extract with the one you use and check whether it's right. Oh, and the Ukraine is now there as well of course. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Enabling communities to use OSM as a planning tool
On Wed, Jun 4, 2008 at 9:26 PM, Jon Burgess [EMAIL PROTECTED] wrote: On Wed, 2008-06-04 at 11:09 -0400, [EMAIL PROTECTED] wrote: At present they can achieve the same effect using off line file and merging layers before rendering. To make the process more smooth maybe some (or all) of the following can be implemented: 1) Enable the render to use multiple '.osm' files for rendering, automatically merging or laying onto the output. The osm2pgsql code used for the mapnik layer can already load multiple osm files into a single render database (see the --append option). Alternatively the Mapnik osm.xml file can easily pull in data from many different sources when rendering. The existing style already uses multiple database connections and shapefiles to build up the main map. If the data was in the DB then it would be a bit tricky to exclude data from the rendering. We would need to have prior knowledge of what tags to exclude from rendering. I personally think it would make more sense to keep the data out of the main OSM DB. Or keep the tag names very different. Essentially namespace them. ie: highway(planning)=cycleway highway(historic)=track -- the historic space would expect the epoch style tag mentioned before to also be on the object we wouldn't have any trouble not rendering these, but they would be easy to convert to standard tag names if status changed or your renderer wished to treat them as the same/override the existing feature. Editing problems remain of course. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Using Palm Software: CotoGPS
Hi all, I just discovered this very fresh and interesting project. As i want to join the community and help mapping my region, I started to search for software that fit my gps config (Palm handheld+BT338). So i found out that the best choice seems to be cotoGPS. But as it's pretty new to me, does someone have a little userguide that should helps me to create traces and upload them to OSM? Or give me another good software? Thanks for any information. -- NoZ MSN/Mail/Gtalk: [EMAIL PROTECTED] ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On 2008-06-05, Steve Hill wrote: Can areas be nested? Yes, mapped one recently To a human, it is fairly obvious that a small areas which is completely enclosed within a larger area should take presidence, but are the renderers expected to understand this? I had to add a layer tag to get it rendered correctly, so apperently renderers don't currenlty understand this by default, but you can tell them about it :) -- Cheers, cobaco (aka Bart Cornelis) signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, Jun 5, 2008 at 12:28 PM, cobaco (aka Bart Cornelis) [EMAIL PROTECTED] wrote: On 2008-06-05, Steve Hill wrote: Can areas be nested? Yes, mapped one recently To a human, it is fairly obvious that a small areas which is completely enclosed within a larger area should take presidence, but are the renderers expected to understand this? I had to add a layer tag to get it rendered correctly, so apperently renderers don't currenlty understand this by default, but you can tell them about it :) Layer tags on areas are pure evil. The layer tag is there to indicate vertical separation, not to give a handy z-order hint to the renderer. So unless you do genuinely have two areas which are physically suspended one on top of the other then please don't add layer tags! Thankfully the mapnik maps will just ignore them. Instead you should fix the renderer, which may include adding something like handy_renderer_z_order_hint=1 to your objects if there isn't a better way. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Brentford Biopsy Private View Thurs 12th June from 6-8pm at Watermans Gallery
If you live in West London you might be interested in coming along. Lots of unusual social mapping + use of Open Street Map: --- Brentford Biopsy Private View Visulising the ecological, cultural and social health of Brentford Thurs 12th June from 6-8pm at Watermans Gallery For the last 12 weeks artist Christian Nold and designer Daniela Boraschi have worked with over 200 people from the local area, members of the public and invited stakeholders, politicians and historians to map the smells, sounds and emotions of Brentford as well as people's opinions and visions of the past, present and future of Brentford. Come to the unveiling of this unique 10 meter long Brentford Biopsy Map at Watermans Gallery on the 12th of June. If you would like to come please RSVP to this e-mail. Free drinks and canapés will be served from 6.30pm Watermans Gallery 40 High Street, Brentford TW8 0DS Google Maps link The best way to get here is to take the train to Brentford and walk or take the District Line Tube towards Richmond and get off at Gunnersbury. Then take either the 237 or 267 bus in front of the tube to Watermans which is a bus stop all by itself. http://publicbiopsy.net/invite.htm best Christian Nold Mobile: 0044(0)7946640395 Skype: crowdcompiler www.softhook.com www.publicbiopsy.net www.paris.emotionmap.net Feel free to join my mailing list on the www.softhook.com website ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Geofabrik planet extracts
On Sun, March 30, 2008 16:23, Frederik Ramm wrote: I was also planning to offer alternative downloads that have a country's full bounding box instead of the exact borders. Would that be good for you? Hi Frederik, If you still intend to provide data with full bounding boxes, would you please add another few kilometers around the boxes? Regards, Hakan -- The key to immortality is first living a life worth remembering... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] More European countries on download.geofabrik.de
On Thu, June 5, 2008 09:27, Frederik Ramm wrote: include Serbia/Croatia. Hakan, if you read this then you might want to compare my Turkey extract with the one you use and check whether it's right. Hi, Since I'm using simple rectangular bounding boxes for both cyprus and turkey, your data is bound to be more correct. In the case of cyprus, this suffices, but my turkey extracts always include parts of the neighboring countries. Would you please send me the polygons you use for those two countries? I'd like to verify them. Regards, Hakan -- The key to immortality is first living a life worth remembering... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch localisation
Jochen Topf wrote: On a related note: I created the current openstreetmap.de website which lacks edit support. Does it make sense to integrate Potlatch into that web page? Would it be hard to do? Sounds really good. There are three potential issues, I think. One is that Potlatch calls its API via relative URLs rather than absolute URLs. This could be fixed by an alternate build (the compile script already supports different URLs, for local testing), or even by adding support to pass the URLs in through JavaScript, which would be trivial. The second is that usually Potlatch authenticates by the Rails site token (which obviously you won't have), rather than by username password. However, there is support in there for supplying username+password (i.e. +-separated) instead of a token. I added this yonks ago for Nick Whitelegg, but to the best of my knowledge it's never been used; it should work. The third is that some background layers _may_ be sniffy if their crossdomain.xml only permits connections from openstreetmap.org, i.e. not openstreetmap.de. In reality most probably permit connections from all, and the Yahoo imagery will work anyway. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Potlatch localisation
Thanks all for the offers of help! Really encouraging. I'll spend a bit of time bringing the text together and will create a wiki page for it. We can then maintain the translations through svn. More soon, hopefully. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, 5 Jun 2008, Dave Stubbs wrote: If the 2nd area is meant to replace the 1st rather than just say something extra about the land/water then you should probably make a hole. Hmm.. ok. Looks like I need to investigate the multipolygon relations stuff. osmarender rules pay attention to the layer tag even when dealing with areas. In this case the river is on layer=-1, and the industrial area has no layer tag (so defaults to 0). osmarender is rendering all -1 objects first, then moves on to the layer 0 objects. This seems wrong to me. An easy fix would be to subtract a number (e.g. 10) from the layer value of areas so they always get rendered under non-area objects. Maybe I'll look at doing this when I don't have a hundred and one other things to do. :) I suspect there's no easy way of doing the surface-area calculation to keep small areas on top though. - Steve xmpp:[EMAIL PROTECTED] sip:[EMAIL PROTECTED] http://www.nexusuk.org/ Servatis a periculum, servatis a maleficum - Whisper, Evanescence ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, Jun 5, 2008 at 2:07 PM, Dave Stubbs [EMAIL PROTECTED] wrote: Layer tags on areas are pure evil. The layer tag is there to indicate vertical separation, not to give a handy z-order hint to the renderer. So unless you do genuinely have two areas which are physically suspended one on top of the other then please don't add layer tags! Thankfully the mapnik maps will just ignore them. Not entirely. On the NL list we had a building overlapping a water area and mapnik was drawing them in the wrong order. Due to the shapes, the building covered more area. Perhaps longterm we should change the styles to always draw buildings over waterways, but for now a layer tags fixes it nicely. Have a nice day, -- Martijn van Oosterhout [EMAIL PROTECTED] http://svana.org/kleptog/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, Jun 5, 2008 at 5:24 PM, Martijn van Oosterhout [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 2:07 PM, Dave Stubbs [EMAIL PROTECTED] wrote: Layer tags on areas are pure evil. The layer tag is there to indicate vertical separation, not to give a handy z-order hint to the renderer. So unless you do genuinely have two areas which are physically suspended one on top of the other then please don't add layer tags! Thankfully the mapnik maps will just ignore them. Not entirely. On the NL list we had a building overlapping a water area and mapnik was drawing them in the wrong order. Due to the shapes, the building covered more area. Perhaps longterm we should change the styles to always draw buildings over waterways, but for now a layer tags fixes it nicely. It might fix it. But it doesn't fix it nicely. You're taking something meant to represent a physical property, and abusing it to produce a pretty map. The question here is whether your building is actually over the water or not; if it is then adding the layer tag is actually correct for once, but if it isn't then please, please invent a new tag rather than abuse an existing one. Although that's been going on for ages now with the layer tag, so it's quite possibly useless except as a render hint which is a pity. At least it's not quite as silly as natural=land. Dave ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, Jun 05, 2008 at 12:10:23PM +0100, Steve Hill wrote: As a side note, I noticed that whilst Mapnik appears to be quite good at rendering areas (e.g. industrial landuse) under the ways, Osmarender doesn't seem smart enough and areas sometimes obscure ways. For example, the river is obscured by an industrial area here: http://www.openstreetmap.org/?lat=51.68998lon=-3.9007zoom=16layers=0B0FT Osma does it exactly right. That river has a layer=-1 while the landuse has no layer (implying 0). The data-wise, the river *is under the idustrial area*. I haven't fixed it. spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
osmarender rules pay attention to the layer tag even when dealing with areas. In this case the river is on layer=-1, and the industrial area has no layer tag (so defaults to 0). osmarender is rendering all -1 objects first, then moves on to the layer 0 objects. This seems wrong to me. An easy fix would be to subtract a number (e.g. 10) from the layer value of areas so they always get rendered under non-area objects. Maybe I'll look at doing this when I don't have a hundred and one other things to do. :) I suspect there's no easy way of doing the surface-area calculation to keep small areas on top though. Why should it work differently? If I want a tunnel under a forest, a layer=-1 *should* draw the tunnel under the forest. Why do you think it's doing something wrongly? tagging a river with layer=-1 seems wrong to me on the other hand. spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Nested areas
On Thu, 2008-06-05 at 19:49 +0200, spaetz wrote: osmarender rules pay attention to the layer tag even when dealing with areas. In this case the river is on layer=-1, and the industrial area has no layer tag (so defaults to 0). osmarender is rendering all -1 objects first, then moves on to the layer 0 objects. This seems wrong to me. An easy fix would be to subtract a number (e.g. 10) from the layer value of areas so they always get rendered under non-area objects. Maybe I'll look at doing this when I don't have a hundred and one other things to do. :) I suspect there's no easy way of doing the surface-area calculation to keep small areas on top though. Why should it work differently? If I want a tunnel under a forest, a layer=-1 *should* draw the tunnel under the forest. Why do you think it's doing something wrongly? If the tunnel becomes invisible because the forest is drawn on top then that does not look good. If however the tunnel was drawn over the top with an appropriate style then that may be more useful. Mapnik would render the tunnel on top of the area but using a dashed style. tagging a river with layer=-1 seems wrong to me on the other hand. Buildings are often constructed over the top of rivers. Whether the building is +1 or the river is -1 surely just depends on where you take your ground reference. If the river really flows through the building then I guess the layer tag is not the right answer. A similar issue must occur frequently with railway lines through train stations. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Large river proposal open for voting was rendering oflarge rivers
On Wed, Jun 4, 2008 at 6:26 PM, David Groom [EMAIL PROTECTED] wrote: The proposed tag waterway = riverbank was approved by 13 votes to 1, with 1 abstention. So if I understand correctly, rivers should not be tagged as both waterway = riverbank and natural = coastline--just waterway = riverbank? Since it was approved, should the wiki page be moved from http://wiki.openstreetmap.org/index.php/Proposed_features/Large_rivers to http://wiki.openstreetmap.org/index.php/Large_rivers ? -- Dylan Type faster. Use Dvorak: http://dvzine.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Keyboard navigation defunct on informationfreeway
Keyboard navigation on informationfreeway is mostly broken once again. At least on MacOSX using Firefox. After pressing '-', '+', or 'r' the focus seems to be elsewhere and you cannot press such a key a second time. I think this is a side-effect of the State of the Map message overlay, that was installed several weeks ago. -- Karl Eichwalder ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk-nl] Welke tags gebruiken we?
On Wed, 2008-06-04 at 17:11 +0200, Lambertus wrote: Geert Schuring wrote: Hallo, Ik heb een vraagje over het gebruik van tags. Bij mij in de omgeving (Ede) ben ik bosweggetjes in kaart aan het brengen, en bij het toevoegen aan OSM vroeg ik me het volgende af: Hoe tag je de volgende situaties: Zo doe ik het: - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor alle verkeer. (rond wit bord, rode rand) highway=track access=no + wellicht: bicycle=yes foot=yes Waarom niet: highway=unclassified surface=unpaved foot=yes Een track kan je het niet echt noemen. Ik map kleine paadjes door het bos als track. - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor auto's en motoren? (rond wit bord, rode rand met auto en motor in het wit) highway=track access=no bicycle=yes foot=yes access=no is wel een goeie, maar hiermee kun je niet aangeven wat nou precies wel en niet erin mag. Een brommer mag er namelijk wel rijden, maar een motor niet. Geert. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags gebruiken we?
Ik denk dat je de map_features [1] pagina in de wiki eens moet gaan lezen. Een track is een weg dat eigenlijk alleen door de landeigenaar wordt gebruikt voor toegang tot bossen of land (en niet een klein paadje door het bos waar je alleen maar op kunt lopen/fietsen). Zie de access tags voor access=no en andere mogelijkheden. [1] http://wiki.openstreetmap.org/index.php/Map_Features On Wed, 2008-06-04 at 17:11 +0200, Lambertus wrote: Geert Schuring wrote: Hallo, Ik heb een vraagje over het gebruik van tags. Bij mij in de omgeving (Ede) ben ik bosweggetjes in kaart aan het brengen, en bij het toevoegen aan OSM vroeg ik me het volgende af: Hoe tag je de volgende situaties: Zo doe ik het: - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor alle verkeer. (rond wit bord, rode rand) highway=track access=no + wellicht: bicycle=yes foot=yes Waarom niet: highway=unclassified surface=unpaved foot=yes Een track kan je het niet echt noemen. Ik map kleine paadjes door het bos als track. - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor auto's en motoren? (rond wit bord, rode rand met auto en motor in het wit) highway=track access=no bicycle=yes foot=yes access=no is wel een goeie, maar hiermee kun je niet aangeven wat nou precies wel en niet erin mag. Een brommer mag er namelijk wel rijden, maar een motor niet. Geert. ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [OSM-talk-nl] Welke tags gebruiken we?
Geert Schuring schreef: Hallo, Ik heb een vraagje over het gebruik van tags. Bij mij in de omgeving (Ede) ben ik bosweggetjes in kaart aan het brengen, en bij het toevoegen aan OSM vroeg ik me het volgende af: Hoe tag je de volgende situaties: - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor alle verkeer. (rond wit bord, rode rand) - Een zandweg waar je met een auto prima kunt rijden, maar die gesloten is voor auto's en motoren? (rond wit bord, rode rand met auto en motor in het wit) - Een weg met een fietspad erlangs. - Een weg met een stukje berm en dan een fietspad erlangs. - Een weg met een rij paaltjes en dan een fietspad erlangs. Ik bedoel maar aan te geven: Is een gesloten zand weg met een astfalt fietspad erlangs gewoon een fietspad, of is het een zandweg waar je ook kunt fietsen? Deze keuzes hangen af van de manier waarop de fietskaart bijvoorbeeld de informatie bevat. Als we willen kunnen routeren voor fieters moeten we dus elk fietspad langs een normale weg toevoegen als lijntje, of die weg een speciale tag geven. Any ideas? Ik gebruik highway=track voor dit soort wegen. Als het fietspad erlangs gescheiden is door bv. een rij bomen en wel verhard, dan krijgt het z'n eigen lijntje. Je kan dit makkelijk doen door eerst één lijn te tekenen en dan CTRL-d om deze te dupliceren in JOSM. Ik gebruik ook highway=minor voor alle verharde wegen, waar je met geen mogelijkheid met twee wagens tegelijk doorkan. Highway=unclassified voor wegen waar dit wel kan, maar waar geen lijnen getekend zijn. Jo ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [talk-au] Tracing items.
On Thu, 5 Jun 2008 14:38:20 +1000 (EST) [EMAIL PROTECTED] wrote: Hi All, Just a general comment and a couple of suggestions. Having been adding items into osm for the last year I've noticed people spending a lot of time tracing roads from landsat, yahoo, etc. While this is admirable work is this really a useful exercise. Someone will eventually drive along this road with a gps upload it and then erase the traced road. Give that some parts of Adelaide for example have got 2 years without anyone doing a GPS track on the, having somebody have at least put in the main roads with an overhead trace gives a framework to place things on. Likewise there are a number of people who contribute ONLY GPS tracks but no names or other details, and often don't ever trace their GPS tracks. If someone has traced from YAHOO etc and put the road name in then someone else can come along and combine the 2 pieces of information to make the more accurate data. Surely getting whatever data we can at whatever level we currently have is a better methodology? Surely even if an area were to be fully GPS traced and annotated people should still be occsionally checking things anyway and will notice things that slip by? Or worse still will not bother to drive down that road as it's already in osm and not tagged as survey and therefore not sure should they replace it. So it never gets surveyed accurately. Anyone with 1/2 oz of a clue can work out the difference between a yahoo/etc traced map and a gps track, for starters if you've uploaded you GPS track and made it public it's obvious. Then of course there's the source: tags. So my suggestion is instead of tracing roads, trace things that can not be easily surveyed. eg railway lines, rivers, powerlines. Railway lines are easy to survey, catch a train ;) Or fix the coastline. There's still lots of areas where the coastline is not accurate and needs to be fixed up. Anyway just my 2c's. And if someone enjoys tracing roads or some other feature exclusively are we to tell them to go away because it's not our idea of the best way to spend their time on OSM? -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Kangaroo Island SA
On Thu, 5 Jun 2008, Darrin Smith wrote: It's tragic to see that as usual with most of the people who dive in they haven't actually checked out the AU or SA wiki which make it pretty clear what should be primary roads in rural areas and have gone primary crazy... I did the B23, and if I didnt put tags on it I can tell you it should be source:yahoo. -- I've driven a select few SA roads in the SE corner (from my point of view) I waypoint each corner and try to record the name of the road, then when bored trace the side roads off landsat. Despite initial complete confusion in my head about what road is what grade, I think I've got it right at last. ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Kangaroo Island SA
On Thu, 5 Jun 2008 18:29:12 +1000 Liz [EMAIL PROTECTED] wrote: On Thu, 5 Jun 2008, Darrin Smith wrote: It's tragic to see that as usual with most of the people who dive in they haven't actually checked out the AU or SA wiki which make it pretty clear what should be primary roads in rural areas and have gone primary crazy... I did the B23, and if I didnt put tags on it I can tell you it should be source:yahoo. -- I've driven a select few SA roads in the SE corner (from my point of view) I waypoint each corner and try to record the name of the road, then when bored trace the side roads off landsat. Despite initial complete confusion in my head about what road is what grade, I think I've got it right at last. I wasn't talking about your roads Liz :) they seem to be pretty reasonable 99% of the time ;) From what I can see is your work you seem to go on the everythings unclassified unless it's special type thinking, whereas a few of our newer mappers in SA seem to follow a everything remotely main is a primary and as that flows down we end up with every 4th road a secondary and every 2nd road a tertiary. Makes a great rainbow, but not so useful as a street map. -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Tracing items.
On Thu, Jun 5, 2008 at 5:38 AM, [EMAIL PROTECTED] wrote: Hi All, Just a general comment and a couple of suggestions. Having been adding items into osm for the last year I've noticed people spending a lot of time tracing roads from landsat, yahoo, etc. While this is admirable work is this really a useful exercise. Someone will eventually drive along this road with a gps upload it and then erase the traced road. Or worse still will not bother to drive down that road as it's already in osm and not tagged as survey and therefore not sure should they replace it. So it never gets surveyed accurately. So my suggestion is instead of tracing roads, trace things that can not be easily surveyed. eg railway lines, rivers, powerlines. IMHO Yahoo tracers should focus on lakes (and other bodies of water), parks and buildings. After that maybe roads with no public access. Tracing public roads should be a last resort, they'll get done much sooner using GPS if they are not already traced from Yahoo. I'm not saying that Yahoo tracers should not do roads, but please do lakes and buildings and stuff first. Give the GPS guys a chance to do the roads. It's a big planet we are not going to run out of unmapped space any time soon. 80n Or fix the coastline. There's still lots of areas where the coastline is not accurate and needs to be fixed up. Anyway just my 2c's. Cheers Ross ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Tracing items.
On Thu, 5 Jun 2008 23:25:06 +0100 80n [EMAIL PROTECTED] wrote: On Thu, Jun 5, 2008 at 5:38 AM, [EMAIL PROTECTED] wrote: Hi All, Just a general comment and a couple of suggestions. Having been adding items into osm for the last year I've noticed people spending a lot of time tracing roads from landsat, yahoo, etc. While this is admirable work is this really a useful exercise. Someone will eventually drive along this road with a gps upload it and then erase the traced road. Or worse still will not bother to drive down that road as it's already in osm and not tagged as survey and therefore not sure should they replace it. So it never gets surveyed accurately. So my suggestion is instead of tracing roads, trace things that can not be easily surveyed. eg railway lines, rivers, powerlines. IMHO Yahoo tracers should focus on lakes (and other bodies of water), parks and buildings. After that maybe roads with no public access. Tracing public roads should be a last resort, they'll get done much sooner using GPS if they are not already traced from Yahoo. I'm not saying that Yahoo tracers should not do roads, but please do lakes and buildings and stuff first. Give the GPS guys a chance to do the roads. It's a big planet we are not going to run out of unmapped space any time soon. If that's the case, why be picky about what anybody maps? Let those who want to contribute in their own way do it. It may get them traced quicker leaving them blank, but it gets them MAPPED quicker if someone does them via Yahoo/etc. By you argument you'd be happy to sit there with huge empty swaths of map whilst someone wastes time doodling buildings (what relevance those have on a street map is debatable, although they do look very cool) and not adding useful navigational data to the map. It's trivial to find out if an area hasn't been gps tracked by firing up josm and searching for roads without the source:survey tag if you want to GPS map an area. -- =b ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] GPS drive tracks are not accurate.
I got very keen and loaded lots of roads by tracing them off Yahoo maps, making sure the trace was an accurate reflection of reality. Then someone overwrote my plots with a GPS track that was the result of driving these roads once, with no understanding of the unavoidable inaccuracies in GPS tracks. The straight plot of what I knew was straight road was replaced by a wavy line. I gave up. What about the copyright ramifications of tracing maps? I've done a lot of GPS tracks and through making multiple passes at various times I've found them very accurate. Frequently I've found real maps having curves that aren't there and the GPS is more accurate. It depends on the quality of the GPS fix and how many times you go over it, if it's just been done once, well chances are it's could be 10-25m out. David ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Tracing items.
On Fri, 6 Jun 2008, 80n wrote: I'm not saying that Yahoo tracers should not do roads, but please do lakes and buildings and stuff first. Give the GPS guys a chance to do the roads. It's a big planet we are not going to run out of unmapped space any time soon. 80n This weekend I'm going to Darwin (plane, car not fixed yet) and that city has a lot of streets done by Yahoo, no names, not much detail. So on foot, should I be photographing all the street signs or walking up and down every street trying to get a GPS trace? My main technical interest is whether the work in Darwin requires redoing as there has not been an adequate georeferencing of the photogrammetry. (for you lot - are the streets in the right place on the ground or are we several hundred metres out overall) I can't see a problem with anyone adding from any source PROVIDED it is IDENTIFIED How else will we get Darwin mapped? ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
Re: [talk-au] Tracing items.
And if someone enjoys tracing roads or some other feature exclusively are we to tell them to go away because it's not our idea of the best way to spend their time on OSM? Missed the point of my suggestion totally didn't you. I am not saying don't do it just that if you want to improve the whole map in osm then here are some things that will help to do that. OSM is not just about streets/roads/highways. It's about the whole map. Look at some of the parts of UK and Europe. There's now even proposals to include the street numbers. All things that add to the navigation assistance available. As to using josm etc that's fine if I've got the laptop running or sitting at home at the desktop connected to the internet. But when I'm on the road and I've got gpsdrive with mapnik running and the osm data is from last thursday and I'm not connected to the internet, I can't tell if the road was traced from Yahoo etc or from a gps upload. Cheers Ross ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-au
[Talk-de] GPS--EXIF
Hallo, Will mir gerade ein Equipment zusammenstellen, tendiere da zu einem Nokia E51 mit Wintec201. Frage ist nun, ob das E51 auch die GPS-Daten in die EXIF der Fotos mit hineinschreibt. Hat da jemand Erfahrung? Gruß, Arne+++ ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Am Mittwoch, 4. Juni 2008 schrieb Frank Wein: Allerdings hat JOSM bemängelt, dass es sich dabei um overlapping ways handelt, da ich die selben Nodes für das Gebäude und die area verwende. Stimmt diese Meldung und ich sollte das nicht machen oder ist das bei einer area egal? Ok, ich muss zugeben es könnte schwieriger werden danach etwas am Gebäude oder der area zu ändern. Wie sieht es aus wenn die area an einer Straße endet, ist ja im Prinzip das gleiche Problem? Kann man die Nodes der Straße mitverwenden oder sollte man das lieber lassen? Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. IMHO schon. :) Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Gruß, Bernd -- Schlechter Geschmack ist kein Privilleg des Alters. - Oliver Kalkofe signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] GPS--EXIF
Hallo Arne. Das noch, dann bin ich auch ruhig. ;-) Am Donnerstag, 5. Juni 2008 schrieb Arne Bischoff: Will mir gerade ein Equipment zusammenstellen, tendiere da zu einem Nokia E51 mit Wintec201. Nur damit du da nichts verwechselst: Der Wintec 201 zeichnet auch selbst auf. Wenn du mit dem Handy aufzeichnen willst, das also immer dabei haben willst, dann reicht ein Bluetooth-GPS (blumax oder ähnliches) für 40 €. Frage ist nun, ob das E51 auch die GPS-Daten in die EXIF der Fotos mit hineinschreibt. Hat da jemand Erfahrung? Wenn du mit dem Wintec aufzeichnest, dann hat das Handy ja erstmal gar keine GPS-Daten, die es speichern könnte. Allerdings würde ich in so ein Setup wenig Energie bzw. Geld reinstecken, da das Abgleichen von Bildern mit GPS-Tracks (Anhand der Zeitstempel) mit sehr einfachen Mitteln nachher am PC geht und es IMHO umständlich ist, das live vor Ort machen zu wollen. Gruß, Bernd -- Die Menschen glauben viel leichter eine Lüge, die sie schon hundertmal gehört haben, als eine Wahrheit, die ihnen völlig neu ist. - Alfred Polgar signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
On Wed, Jun 4, 2008 at 9:00 PM, Plautzenpaule [EMAIL PROTECTED] wrote: Hallo zusammen, vielleicht hatte schon jemad ein ähnliches Problem. Ich habe OSMTracker auf meinem Xda Orbit mit integriertem GPS installiert. Die Installation verlief eigentlich problemlos, nur findet OSMTracker das GPS nicht. Ich verwende die selben Einstellungen, wie bei VisualGPSce, welches erfolgreich GPS findet und Daten aufzeichnet (COM4, 9600. Ich habe auch schon in die config.xml geschaut und manuell die Einstellungen geändert, nichts hilft. Ich hoffe, jemand kann mir helfen? Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
Hallo Martin, Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Das stimmt, aber ich spreche das GPS ja über den COM Port an, so wie die anderen Programme das auch machen. Irgendwo hatte ich gelesen, dass jemand ein Problem beim _gleichzeitigen_ Betrieb von OSMtracker und Glopus hatte, der auch ein XDA benutzt hat. Welches Programm ist denn sonst zu empfehlen, welches auch Waypoints markieren kann? Ich habe jetzt VisualGPSce ausprobiert, was ganz gut läuft, aber das eben nicht beherrscht. Vielen Dank, Christian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Mir fehlen Tags für bestimmte Fläch en, wer kann helfen?
Moin, ich habe da ein paar Probleme mit Flächen, die ich sauber zuordnen möchte. Vielleicht kann mir jemand mal den entscheidenden Tip geben: - unbewirtschaftete Grünflächen (Rasen, Büsche, Bäume, Unkraut)habe ich hier oft und in Größenordnungen landuse=farm passt definitiv nicht, landuse=forest auch nicht könnte man hier natural=scrub nehmen? - vorhandene Industrieruinen im Allgemeinen da fehlt mir generell etwas, historic=ruins ist es sicher nicht - Brachflächen nach Abriss von Industrie, die aber NICHT zur Neubebauung vorgesehen sind landuse=brownfield passt hier nicht, ist das dann auch natural=scrub? Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfaehige Garminkarten
Christoph Eckert [EMAIL PROTECTED] wrote: Auch wenn Du natürlich Recht hast und die Garmins hardwareseitig derzeit das einzige/beste sind was man für den Outdoorbereich haben kann. Das allerdings zu einem echt saftigen Preis. Etrex Legend hat einen Straßenpreis von 180 Euro, ich glaube kaum, dass Du für diesen Preis einen Linux PDA bekommen wirst. Mir sind Geräte mit freier Firmware ebenfalls erheblich lieber als proprietäres Zeug a la Garmin. Fürs Fahrrad sind mir aber andere Dinge wichtiger (Batterielaufzeit, wasserdicht). Schaumermal, vielleicht wird das ja was mit dem OBiCo. Teuer wird der aber auch werden: http://www.obico.de/ Gruss Sven -- The main thing to note is that when you choose open source you don't get a Windows operating system. (from http://www.dell.com/ubuntu) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Es kann nicht dein Problem sein wie das ganze gerendert wird. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Somit macht es wenig Sin diese zu verbinden. Anders sieht es z.b. bei Grenzen aus, dort kann es durchaus sinvoll sein die Nodes sowohl für die Gesamtortsgrenze (weiss zwar nicht was für ein Tag es dazu gibt), sowie die Grenze für eine landuse=residential Fläche zu nutzen. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Dies war in keiner Weise meine Aussage. Ich habe nur gesagt, dass Flächen und Strassen nicht die Selben Nodes verwenden sollen. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Am 5. Juni 2008 09:48 schrieb Raphael Studer [EMAIL PROTECTED]: Soweit ich das Prinzip verstehe, sollte man Nodes wiederverwenden, wenn es die Realität abbildet. Also ein Platz grenzt an eine Straße, ein landuse=residetial geht bis zu einer Straße und ähnliches. Bedenkte bitte, dass du eine Strasse in der Mitte Mappst und nicht am Rand. Wenn du somit die Nodes wieder verwendest würdest du den Rand des Platzes in die Mitte der Strasse verlegen. Das widerrum finde ich eine nicht zutreffende Aussage. Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Ich stelle mal die zwei Haupt-Gründe für mein Vorgehen vor und warte auf tiefgründige Antworten: 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Es kann nicht dein Problem sein wie das ganze gerendert wird. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Somit macht es wenig Sin diese zu verbinden. Anders sieht es z.b. bei Grenzen aus, dort kann es durchaus sinvoll sein die Nodes sowohl für die Gesamtortsgrenze (weiss zwar nicht was für ein Tag es dazu gibt), sowie die Grenze für eine landuse=residential Fläche zu nutzen. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Der Validator macht in diesem Punkt IMHO einfach Mist bzw. wurde diesbezüglich nicht (wirklich) auf API 0.5 umgestellt. Der Validator macht somit keinen Mist. Der Validator beschwert sich über jegliche Art von overlapping ways, egal für wechen Zweck. Oder willst du ernsthaft sagen, dass es nie sinnvoll ist, Nodes wiederzuverwenden? Dies war in keiner Weise meine Aussage. Ich habe nur gesagt, dass Flächen und Strassen nicht die Selben Nodes verwenden sollen. Ich verstehe eure Meinungen und denke ich weiss, wie ihr zu diesen gekommen seit. Meine persönliche Meinung ist, dass mich doppelt benutzte nodes beim Editieren oft sehr stören. Auch sind diese wesentlich anfälliger für Anfängerfehler. Ich bin heilfroh, dass es seit ein paar Wochen das unglue-plugin für JOSM gibt. Wenn ich beim Mappen auf gemeinsam genutzte nodes treffe, dann werden die getrennt. Basta! Bei mir benutzen nur physikalisch verbundene Objekte gemeinsame nodes. Dass können für mich nie Wald+Straße od. See+ Straße sein. Bei Marktplatz + Straße sollte natürlich die angrenzende Straße einen gemeinsamen node mit dem Markt haben. Mein Senf Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Die Aussage dreht sich im Kreis. Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Eben grade *weil* die Straße (nicht die Einmündende sondern die Ausgangsstraße) nicht zweidimensional erfasst wird. Fall 1: -- - - - - - - - - ---+ +--- | | | | Fall 2: -- - - - - - - - - + +--- | | | | +-+ Für mich sieht die obere Straße auch unterhalb der Mitte noch identisch aus bei beiden Szenarien. Nur der Rand der Straße (der gar nicht erfasst ist) ändert sich. Wenn du den Platz jetzt unabhängig erfassen würdest, wäre das Datenmodell so: -- - - - - - - - - -- +-+ | | | | +-+ Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. Mag sein, seh ich anders. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Daher komme ich zu dem Schluß, dass verbundene Elemente für jede Nutzung und für jede Art von Renderer die mir einfällt leichter zu verarbeiten bzw. einzustufen ist. Weil es eine semantische Abbildung ist. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem Datenbestand exakt bestimmen kann) oder ob die Karten primär dafür gedacht sein sollen, semantisch die Realität abzubilden damit man einzelne Objekte in Relation zu anderen Objekten setzen kann. Ich sehe unsere gesamte Genauigkeit als so grob an, dass wir ersteren Anspruch niemals erfüllen können. Daher mappe ich semantisch. Sonst müsste man ja auch jede Kurve mit tausenden von Nodes machen, um das genau genug abzubilden. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Wieso sollte das so sein? Flächen verschieben sich nicht einfach so. Also zumindest nicht in der Realität. :) Bei baulichen Veränderungen muss man ggf. die Karte korrigieren, das ist aber logisch. Und ich will ja grade vermeiden, dass Straße und Platz in irgendwelcher Darstellung auseinander gezogen werden obwohl sie in Wahrheit direkt aneinander grenzen. Ich kann nur nochmal erwähnen dass Strassen eindimensional erfasst werden und Flächen 2 Dimensional nicht. Das nicht ist zu viel, oder? ;-) Ich finde nicht, dass das was ändert. Wobei ich eher dazu tendieren würde alle Flächen eines Ortes (an die Rechtschreibspezialisten, heisst es Orts oder Ortes?) in eine Relation zu packen. Man kann laut Duden beides benutzen. ;-) Da stimme ich dir zu. Die Frage von oben ist IMHO aber auch, wie man es z.B. handhabt, wenn eine Straße links Wald und rechts Wohngebiet hat. Für mich ist die Antwort hierrauf die selbe wie für den Platz oben. Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Bei Marktplatz + Straße sollte natürlich die angrenzende Straße einen gemeinsamen node mit dem Markt haben. Das klingt aber schauderhaft. Einen gemeinsamen Node oder alle an denen eine Einfahrt möglich ist? Wenn nur einen, welchen? Nach Zufallsprinzip ausgewählt? Klingt IMHO nicht überzeugend. Vorschlag für neuen Grundsatz: Mappe nicht für die Vermeidung von Anfängerfehlern. ;-)) Gruß, Bernd -- Keine zwei Menschen gleichen einander, und beide sind froh darüber signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden
Hallo, ich benutze gpxVP http://gpsvp.garminmapsearch.com/ funktioniert bei mir ganz gut auf meinem Orbit. leider funktionieren bei mir die POI Namen von erstellten OSM - Garminkarten nicht. als dann Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Christian Görs Gesendet: Donnerstag, 5. Juni 2008 09:35 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] OSMTracker und HTC/Xda Orbit kann GPS nicht finden Hallo Martin, Auf der Wiki Seite (http://wiki.openstreetmap.org/index.php/OSMtracker) dazu steht: Target platform : ...internal gps support not yet... Das stimmt, aber ich spreche das GPS ja über den COM Port an, so wie die anderen Programme das auch machen. Irgendwo hatte ich gelesen, dass jemand ein Problem beim _gleichzeitigen_ Betrieb von OSMtracker und Glopus hatte, der auch ein XDA benutzt hat. Welches Programm ist denn sonst zu empfehlen, welches auch Waypoints markieren kann? Ich habe jetzt VisualGPSce ausprobiert, was ganz gut läuft, aber das eben nicht beherrscht. Vielen Dank, Christian. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Ich glaub ich hab schon wirklich darüber nachgedacht, mit dem Resultat dass eine Strasse und ein Platz nicht das Selbe sind :) Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. Ich würde auch wenn der Platz baulich nicht getrennt ist, nur einen einzigen Weg zwischen Strasse und Platz markieren, damit ein Navi erkennen könnte dass man auf den Platz fahren kann. Weiter wärs wahrscheinlich auch nicht Tragisch wenn einem das Navi nur vor den Platz lotst und nicht direkt darauf. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Ich denke man sagt: Der Platz ist neben der Strasse. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem Datenbestand exakt bestimmen kann) oder ob die Karten primär dafür gedacht sein sollen, semantisch die Realität abzubilden damit man einzelne Objekte in Relation zu anderen Objekten setzen kann. Ich sehe unsere gesamte Genauigkeit als so grob an, dass wir ersteren Anspruch niemals erfüllen können. Daher mappe ich semantisch. Sonst müsste man ja auch jede Kurve mit tausenden von Nodes machen, um das genau genug abzubilden. Ich sehe auch, dass wir den zweiten Anspruch erfüllen sollten. Daher hat die Strasse und der Platz auch nur eine einzige Verbindung :). Teilen sich Platz und Strasse die Nodes, wäre die Strasse ja ein Teil des Platzes, was IMOH nicht der Fall ist. Was wenn sich die Fläche verschiebt, die Strasse jedoch nicht? Wieso sollte das so sein? Flächen verschieben sich nicht einfach so. Also zumindest nicht in der Realität. :) Bei baulichen Veränderungen muss man ggf. die Karte korrigieren, das ist aber logisch. In meiner Realität verschieben sich Flächen. z.B. ändert sich die Fläche des Bodensees laufend. Oder die Fläche von Indien schiebt sich laufend Richtung Fläche von Russland, so dass diese immer kleiner (und höher) wird. Die Frage von oben ist IMHO aber auch, wie man es z.B. handhabt, wenn eine Straße links Wald und rechts Wohngebiet hat. Für mich ist die Antwort hierrauf die selbe wie für den Platz oben. Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz grob frei Hand. Die Ways schneiden sich in den OSM-Daten vor allem in Kurven recht unkoordiniert und dass das in der Karte nachher nicht scheisse aussieht liegt nur daran, dass der Renderer der Straße eine gewisse Breite gibt, sodass beide Flächen auf dem Bild nachher genau an die Straße angrenzen. Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Dass sich die Ways schneiden ist natürlich nicht wünschenswert. Da ist jedoch etwas mehr Disziplin des Bearbeitenden gewünscht. Oder der Editor sollte deutlicher darauf aufmerksam machen, dass hier eventuell ein Fehler vorliegt. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. That's the way I'm working on the localisation at Skype as well. I'd like to do the Potlatch translation into german. Anyone else with l10n experience/Noch jemand mit Übersetzungserfahrung? Regards, /Claudius/ Torsten Breda: 2008/6/5 Fabian -Patzi- Patzke [EMAIL PROTECTED]: Oscar Knapp schrieb: Hi Richard, I'm interested in doing some of the translations. I'd suggest to open a new page in the OSM Wiki containing the english source to be translated - so everyone will be able to contribute to this. Discussions whether a specific translation is adequate could be held on the discussion page. Hi, i'd like to contribute my part to the translation. As Oscar said, some kine of multiuser translation would be very handsome, so many users could help and the work need not be done by only one person. So if there is some kind of multiuser thing count me in. Yes, a translation on a wiki page would be good. Just post the english language file, when you have it completed. (Don't know if it already exists, or has to be generated) If there is a char-limit for some fields, then this would be interesting too, because words are normaly longer in german. An information about the context of the words to be translated could be useful. E.g the word play could mean spielen, herumspielen, ausprobieren... I think, a translation of potlatch is the right step to make it more usable to newbies and could prevent errors when editing. Do you want to implement a translation for the tags also? Greets Torsten Breda ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tag für P+R Parkplatz
Hallo Heiko, hier ist ein P+R : http://www.openstreetmap.org/?lat=52.44111lon=9.72504zoom=17layers=0B0FT Mapnik zeigt nur ein P an, Osmarender schreibt Park Ride drüber. Gruß Christian Heiko Schack wrote: Moin Moin. Die Tagvergabe für P+R (Park and Ride) Parkplätze scheint mir ein wenig missverständlich zu sein. Normale Parkplätze werden ja als amenity=parking gekennzeichnet. Für dieses Tag gibt es noch zusätzlich den Key parking. Laut Wiki (http://wiki.openstreetmap.org/index.php/Tag:amenity%3Dparking) kann man dort auch park_ride eintragen. Laut der Wiki-Seite zu P+R (http://wiki.openstreetmap.org/index.php/Proposed_features/Park_and_Ride) gibt ein eigenes Tag amenity=park_ride mit der Class-Angabe, um was für ein ÖPNV-Übergang es sich handelt Leider habe ich in der näheren Umgebung keinen P+R Parkplatz gefunden, an dem ich mich orientieren kann. Welches Tag würdet ihr für einen P+R vergeben? Wird die amenity park_ride in Mapnik und Osmarender richtig angezeigt? Lg Heiko ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Raphael Studer schrieb: Ich habe hier sehr viele Stellen, an denen jemand ganz grob den Wald unabhängig von der Straße gezeichnet hat. Das Wohngebiet auf der anderen Seite dann ebenfalls ganz grob frei Hand. Die Ways schneiden sich in den OSM-Daten vor allem in Kurven recht unkoordiniert und dass das in der Karte nachher nicht scheisse aussieht liegt nur daran, dass der Renderer der Straße eine gewisse Breite gibt, sodass beide Flächen auf dem Bild nachher genau an die Straße angrenzen. Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Na klar! Ein landuse=residential kann doch sehr wohl Straßen enthalten. Oder machst du da für jede Straße eine Schneise in die area? Ebenso enthält ein landuse=forrest auch Wege und Straßen. Das unterscheidet es ja von natural=wood, was explizit nur Bäume, ergo keine Straßen sind. Und in dem obigen Fall würde die Straße also halb durch den Wald und halb durch ein Wohngebiet verlaufen. Das entspricht IMHO sehr gut der Realität. Mann würde ja auch sagen, die Straße verläuft auf der Grenze zwischen Ort und Wald. Das funktioniert natürlich nur mit landuse, das per Definition eine Fläche mit verschiedenen Objekten zusammenfasst. Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Wieso nicht? Nicht jeder Quadratmeter eines Wohngebiets ist bebaut. :) Ich finde die Formulierung Das Wohngebiet beginnt direkt neben dem Wald nicht falsch. Die Straße ist in meinem Vorgehen halb im Wald (Straßen im Wald gibt es, da wachsen auch keine Bäume drauf) und halb im Wohngebiet (Auch da gibt es Straßen auf denen keine Häuser stehen). Ich sehe das als genau das was ich darstellen möchte. Wenn man es so sieht wie du, dann müsste man Straßen IMHO auch in 2-D mappen. sonst hat man um jede Straße ein paar Meter undefiniertes Gebiet, das der Renderer dann bitte mit der Straße abdecken soll. Das ist IMHO nicht logisch. Gruß, Bernd -- Ein Kompromiß ist nur dann gerecht, brauchbar und dauerhaft, wenn alle Partner damit gleich unzufrieden sind. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
Two people for each langauge :) Martin Thurau: On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Help! German translation for Potlatch
Uh...my bad ;) I agree that you *could* end up with a messy result if more than two people translate an application but I still think translations should be 'free for all'. I would suggest Launchpad like approach (https://translations.launchpad.net/). If potlach already uses gettext (or can be changed) ) we could even use launchpad. Otherwise we could still use the wiki and do the translation there (eventually with automatic import to potlach). After all OSM (and of course Wikipedia) are pretty impressive proves that 'intelligence of the masses' is a working concept. On Thu, Jun 5, 2008 at 12:10 PM, Claudius Henrichs [EMAIL PROTECTED] wrote: Two people for each langauge :) Martin Thurau: On Thu, Jun 5, 2008 at 11:11 AM, Claudius Henrichs [EMAIL PROTECTED] wrote: I strongly oppose a multisuer translation as in the result you are likely to end up with different translations for the same term. Better to form a core team of two people dealing with this. Two people who translate a application in every language even if they are no nativ speakers? Isn't this supposed to end up in something like Stecke Nippel A von durch Lasche in Gegenseite? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Tag für P+R Parkplatz
ups, sorry, hab nicht in den Daten geschaut sondern nur auf der Karte, da ich weiß, da da einer ist. Bernd Wurst wrote: Hallo. Am Donnerstag, 5. Juni 2008 schrieb Christian Malolepszy: hier ist ein P+R : http://www.openstreetmap.org/?lat=52.44111lon=9.72504zoom=17layers=0B0FT Nein. Dort ist ein normaler Parkplatz, dem jemand den *Namen* Park Ride gegeben hat. Mit einem speziellen ParkRide-Tag hat das nichts zu tun. Gruß, Bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Am 05.06.2008 um 12:18 schrieb Dirk-Lüder Kreie: Bernd Wurst schrieb: Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Dein Beispiel find ich sehr gut. Wenn jetzt die der Wald, die Strasse und das Wohngebiet die selben Nodes teilen, heisst dies dass das Wohngebiet DIREKT neben den Wald ist. Die Strasse in der Mitte könnte also gar nicht vorhanden sein. Wieso nicht? Nicht jeder Quadratmeter eines Wohngebiets ist bebaut. :) Ich finde die Formulierung Das Wohngebiet beginnt direkt neben dem Wald nicht falsch. Die Straße ist in meinem Vorgehen halb im Wald (Straßen im Wald gibt es, da wachsen auch keine Bäume drauf) und halb im Wohngebiet (Auch da gibt es Straßen auf denen keine Häuser stehen). Ich sehe das als genau das was ich darstellen möchte. Wenn man es so sieht wie du, dann müsste man Straßen IMHO auch in 2-D mappen. sonst hat man um jede Straße ein paar Meter undefiniertes Gebiet, das der Renderer dann bitte mit der Straße abdecken soll. Das ist IMHO nicht logisch. Überall dort, wo die Straße quasi die Grenze zwischen Gebieten definiert, sollte sie IMnsHO dieselben nodes sharen,wie die angrenzenden Gebiete, da eine Korrektur der Straße auch eine Korrektur der Gebiete nach sich zieht. Die Gebilde hängen topologisch zusammen, und sollten darum auch in der Topologie in OSM genau so abgebildet werden. Bin auch dafür, dass Straßen eine Grenze zwischen Gebieten bilden können. Oder genauer: auf der Grenze zweier Gebiete kann durchaus eine Straße liegen. Was macht man denn, wenn hinter dem Wohngebiet der Wald (ohne Straße dazwischen) beginnt? Lässt man da auch ein Niemandsland, oder hängt man die über die selben Nodes aneinander? Wohl eher Letzteres. Nodes sind erstmal nur Punkte im Raum. Wer die alles als Teil seiner selbst referenziert (Briefkasten, Straße, Gebiet, Fluss) ist erstmal egal. Ob ein Renderer nur Straßen, oder auch Gebiete darstellt (und wie) ist für die Datenbasis unerheblich. Wie breit eine Straße ist, kann man mit dem Set aus Node und Way auch nicht definieren. Man könnte natürlich eine Breite beim Way zuordnen, aber ist das das Ziel einer Straßenkarte? Dafür benutzt man besser den Typ der Straße. Für perfekte Vermessung wendet Euch an das Projekt OpenSurveyAndMeasurement :P Bei den Parkplätzen sollte IMHO ein Straßenstummel hineinführen, wenn es eine dedizierte Einfahrt gibt, dann darf der P auch keine Nodes der Straße nutzen. Wenn die Parkplätze als Bucht ausgeführt sind, sollten die selben Nodes benutzt werden, da man direkt von der Straße drauf fahren kann. atze ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutsch land
Am 5. Juni 2008 13:28 schrieb Martin Thurau [EMAIL PROTECTED]: Wenn man mal von Grundstücksflächen, Städten und Wäldern absieht, besteht die restliche Fläche unseres Landes ja quasi nur aus landwirtschaftliche genutzten Flächen, die von Straßen, kleinen Bächen und Gräben sowie vereinzelt ein paar Sonderfälle wie Seen und Flüssen, unterbrochen werden. Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Mir ist durchaus klar, dass es für OSM im moment wichtigeres gibt, als Freiflächen zu benennen, aber der Gedanke schoss mir gerade in den Kopf und ich fragte mich, ob man sich darüber schonmal Gedanken gemacht hat. Hier herscht leider schon seit Ewigkeiten kein Konsenz. Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Hier stellen sie eine Außnahme und eine Besonderheit dar. Auf dem platten Land hingegen gehen die Meinungen weit auseinander. In der Aachener Gegend haben wir versucht das so: http://wiki.openstreetmap.org/index.php/Aachen#.22landuse.3Dfarm.22 zu machen. Ich wiederhole: Hier herrscht keine Einigkeit. Das ist nur ein Vorschlag. Hole mir schon mal Popkorn Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Landwirtschaftliche Flächen in Deutschla nd
Wenn man mal von Grundstücksflächen, Städten und Wäldern absieht, besteht die restliche Fläche unseres Landes ja quasi nur aus landwirtschaftliche genutzten Flächen, die von Straßen, kleinen Bächen und Gräben sowie vereinzelt ein paar Sonderfälle wie Seen und Flüssen, unterbrochen werden. Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Mir ist durchaus klar, dass es für OSM im moment wichtigeres gibt, als Freiflächen zu benennen, aber der Gedanke schoss mir gerade in den Kopf und ich fragte mich, ob man sich darüber schonmal Gedanken gemacht hat. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutschla nd
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Martin Thurau: Gibt es im Hinblick auf diese Tatsache eigentlich eine Art Konsens, wie man damit umgeht? Wenn man es aml überspitzen will könnte man ja einfach mal jede Freifläche nehmen und ein landuse=farm draufklatschen...in den meisten Fällen würde es vermutlich passen ;) Ich finde an der Tatsache, dass die beiden aktuellen Renderer landuse=farm komplett unterschiedlich rendern sieht man, dass es keinen Konsens gibt. Beispiel: http://www.informationfreeway.org/?lat=48.93925163541401lon=9.435541347388728zoom=14layers=B000F000F Osmarender macht es grün, Mapnik braun. Die Wahrheit ist, dass sich Grünland und Ackerland aber meist abwechseln und sich das auch über die Zeit immer wieder ändert. Ich denke es macht es allen Beteiligten leichter, wenn man das Gebiet einfach undefiniert lässt. Rendern sollte man das IMHO sowieso gar nicht, da beides, grün oder braun, immer falsch ist. Es gibt natürlich die andere Meinung, dass alles irgend ein landuse haben muss, sonst sind wir unvollständig. Ich seh das aber nicht so. Gruß, Bernd -- Fachbegriffe der Informatik (#286): Googlehupf Abstand zwischen zwei Suchergebnissen. (Markus Kempken) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deutsch land
Hallo. Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Das widerspricht aber dem verlinkten Wiki-Eintrag: Landuse=farm meint den Landwirtschaftlichen Betrieb, der ja nicht als landuse=residential, industrial oder ähnlichem zu taggen ist. Gemeint ist also der Bauernhof mit direkt angrenzenden Nebengebäuden, Gewächshäusern, Jauchegrube usw. Meist ist das ganze auch umzäunt. Und der widerrum der Definition der Map-Features. ;-) Gruß, Bernd -- Wenn's an Silvester stürmt und schneit, ist das Neujahr nicht mehr weit. Stürmt und schneit's Silvester nicht, ist das Neujahr auch in Sicht. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Noch mehr Flächen
Hallo. Wollte grade unser bisher großzügig vergebenes landuse=residential etwas korrigieren. Dabei fiel mir eine Fläche auf, die aus folgendem besteht (zusammenhängend, ohne Wohnbebauung dazwischen): * Kirche * Gemeindehalle (+ Parkplatz) * Sporthalle * Schulzentrum * Sportplätze * (öffentlicher) Spielplatz und daran grenzt der Stadtpark (der bisher nur leisure=park hat und kein landuse, was ich auch korrekt finde). Hat jemand nen Vorschlag für so ein Gebiet? Gruß, Bernd -- OPERA: When a guy gets stabbed in the back and instead of bleeding he sings. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Noch mehr Flächen
Ich würde die Fläche komplett entfernen und statt dessen lieber einzelflächen an den entsprecheden Positionen angeben: Sporthalle + Schule - amenity=school Sportplatz - amenity=pitch (oder Gemeindehalle - amenity=public_building Parkplätze - amentiy=parking+ Kirche - POI mit amenity=place_of_worship Ist zwar etwas umständlicher und geht ein wenig verschwenderisch mit Punkten um, wäre imho aber am korrektesten. Gruß Martin 2008/6/5 Bernd Wurst [EMAIL PROTECTED]: Hallo. Wollte grade unser bisher großzügig vergebenes landuse=residential etwas korrigieren. Dabei fiel mir eine Fläche auf, die aus folgendem besteht (zusammenhängend, ohne Wohnbebauung dazwischen): * Kirche * Gemeindehalle (+ Parkplatz) * Sporthalle * Schulzentrum * Sportplätze * (öffentlicher) Spielplatz und daran grenzt der Stadtpark (der bisher nur leisure=park hat und kein landuse, was ich auch korrekt finde). Hat jemand nen Vorschlag für so ein Gebiet? Gruß, Bernd -- OPERA: When a guy gets stabbed in the back and instead of bleeding he sings. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, der Diskussion fehlt mir irgend wie ein System. Ich habe in meiner Umgebung nur Parkplätze und diese sind in der Natur baulich von der Straße abgegrenzt. Und wenn es nur ein paar Meter sind. Entweder endet die Straße im Parkplatz oder geht daneben vorbei, besitzt dann aber eine separate Zufahrt zum Parkplatz. Ich erstelle erst einmal den Parkplatz ganz isoliert aus den vier Eckpunkten. Es ist mir kein Parkplatz bekannt, bei dem die Zufahrt direkt auf einem Eckpunkt liegt. Also mache ich ein paar Meter neben der Ecke eine weitere Node in die Parkplatzumgrenzung und lasse die Straße/Zufahrt dann dort enden. Das Ergebnis sieht dann wie in der Realität aus. Habe ich hier einen Denkfehler? Ganz anders sieht die Sache bei einem (historischen) Marktplatz aus, in den mehrere Straßen münden und der eigentlich kein richtiger Platz (wie z. B. der Parkplatz) ist. Da müsste man eher so eine Art Kreisverkehrskonstukt erstellen. Mancher Marktplatz besitzt ja auch eine Mittelinsel (mit Brunnen oder Kriegerdenkmal). Echte Marktplätze sind im Augenblick für mich zu weit weg. Irgendwann werde ich mich auch damit befassen müssen, aber noch nicht gleich heute. Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Bernd Wurst Gesendet: Donnerstag, 5. Juni 2008 10:31 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Overlapping ways bei einer area Hallo. Am Donnerstag, 5. Juni 2008 schrieb Raphael Studer: Genauso könntest du argumentieren, dass eine Querstraße am Rand der Straße einmündet und nicht in die Mitte. Dennoch wären unsere Daten ziemlich sinnlos, wenn die nicht verbunden wären. Eine Querstrase wird Seitlich eingebunden. Stassen sind nämlich im Moment noch 1 dimensinal und somit ist jeder Punkt darauf sowohl in der Mitte wie auch am Rand :) Die Aussage dreht sich im Kreis. Also ich verstehe was du sagen willst. Aber ich sehe keinen Grund, warum eine Quer-Straße, die in eine Straße einmündet etwas anderes sein soll als ein Platz, der an die Straße angrenzt. Denk mal wirklich drüber nach, es ist eigentlich echt kein Unterschied. Eben grade *weil* die Straße (nicht die Einmündende sondern die Ausgangsstraße) nicht zweidimensional erfasst wird. Fall 1: -- - - - - - - - - ---+ +--- | | | | Fall 2: -- - - - - - - - - + +--- | | | | +-+ Für mich sieht die obere Straße auch unterhalb der Mitte noch identisch aus bei beiden Szenarien. Nur der Rand der Straße (der gar nicht erfasst ist) ändert sich. Wenn du den Platz jetzt unabhängig erfassen würdest, wäre das Datenmodell so: -- - - - - - - - - -- +-+ | | | | +-+ Ob es ein Renderer oder ein Navi wäre, der Zusammenhang zwischen Straße und Platz (z.B. Parkplatz) wäre nicht gegeben. Es gibt keinen Anhaltspunkt, dass es hier überhaupt eine Einfahrt in den Platz gibt. Wenn der Platz baulich getrennt ist (Mauer, Grünstreifen, ...), dann ist es natürlich was anderes. Aber das war nicht die Ausgangslage. 1. Warum sollte man unnötig viele Nodes in den Datenbestand eingeben, wenn sie keinen Mehrwert bringen? Man kann hier Nodes wiederverwenden ohne dass es die semantische Abbildung der Welt stört. Ob ein Mehrwert vorhanden ist oder nicht, kann aus der jetzigen Sicht nicht berurteilt werden. Mag sein, seh ich anders. 2. Der Platz soll an der Straße beginnen, egal wie breit die Straße gerendert wird. Wir werden später immer wieder die Situation haben, dass Straßen unterschiedlich dargestellt werden sollen oder sogar minimal verschoben werden um daraus optisch ansprechende Karten zu schaffen. Wenn der Platz keine Verbindung zur Straße hat, dann ist er nachher evtl. auch optisch nicht damit verbunden. Das ist in der Regel falsch. Durch Benutzung der selben Nodes wird das Problem grundsätzlich umgangen. Grundsatz: Mappe nicht für den Renderer!! Ja, eben drum. Ich weiß ja nicht, wie breit der Renderer die Straße macht. In der Realität würde man sagen: Der Platz schließt sich direkt an die Straße an. Man sagt nicht: Der Platz beginnt 3 Meter vom Mittelpunkt der Straße entfernt. Daher komme ich zu dem Schluß, dass verbundene Elemente für jede Nutzung und für jede Art von Renderer die mir einfällt leichter zu verarbeiten bzw. einzustufen ist. Weil es eine semantische Abbildung ist. Für mich stellt sich die übergeordnete Frage, ob wir Karten mit dem Anspruch auf Vermessungs-Genauigkeit haben wollen (so dass man z.B. Flächen-Größen aus unserem
Re: [Talk-de] Wie und wo Mailingliste einrichten?
Holger Schrader schrieb: Hallo Liste, Wie und wo kann ich auf einem einfachen Weg eine lokale Mailingliste einrichten ohne personalisierte Werbung zu erwarten? Ciao Holger ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de Probiers einfach mal auf http://groups.yahoo.com/ Die sind kostenlos und zumindest früher war das auch sehr einfach einzurichten und zu admnistrieren und sehr zuverlässig. Ich hatte da auch ne ganze Weile ne Mailinglist eingerichtet. Gruß, Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] GPS Tuner V5.4c ist 'Open Street Map' kompatibel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, schon wieder erhalte ich eine Mitteilung, dass neue Version vom GPS Tuner ausgeliefert wird. Da ich das Programm einmal ehrlich bezahlt hatte, brauche ich nur die neue Version herunterzuladen. Leider hinkt das PDF-Handbuch der Entwicklung hinterher. (http://pocketland.de/product.php?prod_id=13384) Weiß jemand, was man unter GPS Tuner V5.4c ist 'Open Street Map' kompatibel verstehen kann? Die Daten sind in den Wegpunkte im GPX-, LOC-, KML-Dateiformat verfügbar. Kennt jemand mehr spezifische Details? Ich verwende dieses Programm auf dem Yakumo delta 300 GPS mit Windows mobile 2003. Ich wäre richtig zufrieden, wenn der die Speicherbereiche nicht so intensiv bis zum letzten Byte belegen würde. Für das reine Datenerfassen nehme ich doch lieber Odgps. Kann auch GPX aber außer einigen Anzeigen nicht viel mehr. Eingestellt auf ein Punkt jede Sekunde. Dem GPS Turner kann ich ein JPG als Karte nach dem vergeodaten auf dem PC oder notfalls auch auf dem PDA geben. Wenn ich die Geo-Daten eintrage, wird eine *.gmi angelegt. Gleicher Name wie die *.jpg. Der Inhalt sei hier mal als Beispiel angegeben: Map Calibration data file v3.0 Buch JPG.JPG 1256 1040 50;10;13.36667;52.65 141;946;13.38333;52.56667 1166;1022;13.5;52.56667 1185;34;13.5;52.65 Border and Scale 52.6531233732431;13.3593388698909;52.5580773902482;13.5466699234652 6823.408;11526.46 Zeile drei und vier sind die Größe des JPG in Pixel In den folgenden sind vier Punkte verewigt. Jeweils die Koordinaten als Pixel und als Nautische Werte. Auf der OSM-Hauptseite kann ich ein Bild als JPG exportieren. Kann die Seite so eingerichtet werden, dass sie bei Wunsch auch gleich diese gmi-Datei anlegt? Dann sollten die vier Eckpunkte von 0;0 bis 1255;1039 oder so ähnlich angelegt werden. Die nautischen Koordinaten werden ja beim Export angezeigt. Die Datei per Hand zu erzeugen, ist doch sehr fehleranfällig. Kann jemand meinen Wunsch nachvollziehen? Rolf -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) Charset: iso-8859-1 wj8DBQFISBrUX/cdferISG0RAgQ6AJ44U7UBakz7r7CaWOu9R0dOmeIXBgCg27UH LG44CoEe2ssIPrpVFjz4QJA= =talu -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] neue Garmin Karte
Habe heute die Aktuelle Karte von Computerteddy runtergeladen, hatte noch eine 4 Wochen alte installiert. Habe dann die alten img und tdb Dateien einfach aus denen der neuen Karte ersetzt, was bisher immer klappte. Jetzt stürzt aber Mapsource ab wenn ich die OSM Karte anzeigen lasse. Ein rückersetzen der Kartendateienen hilft, aber dann hab ich ja auch die alten Karten... Hab ich was falsch gemacht, oder ist bei der Kartenerstellung was schiefgelaufen? Viele Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] neue Garmin Karte / Worldfile vom 4.6.08
Hallo Carsten wie offenbar bemerkt worden ist, ist die neue Karte online. Entschuldigung für die Dopplung sind meine ersten Erfahrungen mit einer Mailinglist. eine 4 Wochen alte installiert. Habe dann die alten img und tdb Dateien einfach aus denen der neuen Karte ersetzt, was bisher immer klappte. Jetzt Das wird der Fehler sein. Hm, in der Registry trägt man doch nur das ein: [HKEY_LOCAL_MACHINE\SOFTWARE\Garmin\MapSource\Products\OSM] LOC=E:\\Garmin\\OSM\\ BMAP=E:\\Garmin\\OSM\\6324.img TDB=E:\\Garmin\\OSM\\6324.tdb Wenn ich jetzt alle Dateien im OSM Ordner mit denen der neuen Karte ersetze (ich nenne den Ordner in OSM_alt um und mache dann einen neuen der OSM heisst, dahin entpacke ich dann die neue Karte) müsste das doch funktionieren, oder? Wenn nein, wie geht es richtig? mit dem alten typ-File getestet Ein typ-File benutze ich gar nicht. Viele Grüße, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, für mich bleibt die wichtige Frage: Steht dort ein Weißes P auf blauen Grund? Mit allen Rechten für den Kraftfahrer und allen Pflichten für die Gemeinde oder Stadt? Oder ist es nur eine Parkordnung mit allen Nachteilen für den Kraftfahrer? Ich glaube, ich war vor vielen Jahren schon einmal dort, hatte aber den Pkw unten in der Stadt stehen lassen. Ich kann mich an die Flächen noch dunkel erinnern, aber nicht mehr an die Beschilderung. Aber mal so nebenbei die Frage: Ist denn klar geworden, warum ich das so getrennt behandelt wissen möchte? Rolf -Ursprüngliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Im Auftrag von Henry Loenwind Gesendet: Donnerstag, 5. Juni 2008 21:59 An: Openstreetmap allgemeines in Deutsch Betreff: Re: [Talk-de] Overlapping ways bei einer area Rolf Gehring wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hallo, das sind in meinem Augen im eigentlichen Sinne keine Parkplätze. Ich gehe mal davon aus, dass dort auch kein Weißes P auf blauen Grund steht. Nur weil der OP kein besseres Beispiel gefunden hat, heißt das noch lange nicht, dass es solche Parkplätze nicht gibt. Mein Beispiel ist bei Google leider vor lauter Bäumen nicht zu sehen: Heidelberg, über dem Schloß. Ein richtiger Parkplatz, sogar mit eigenen Fahrspuren, der auf einer Längsseite durch nichts von der Straße getrennt ist. Naja, ausser den Begrenzungslinien der einzelnen Parkbuchten... cu Henry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de -BEGIN PGP SIGNATURE- Version: PGP Desktop 9.5.3 (Build 5003) Charset: iso-8859-1 wj8DBQFISFKFX/cdferISG0RAvVOAJ41+Y4iqRjIhgE3BNS1lKNVaYUn6ACfXiKD Y4ZiopSgW101ihG/HEoXNjM= =Essv -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deuts chland
Moin, Sind wir da schon zwecks Alternative weiter? Habe da noch paar provisorisch getaggte Höfe... solange das nicht besonders eindeutig ist, könntest Du doch die Bauernhöfe mit flächenverbrauch=bauernhof und flächenverbrauch=landwirtschaftlich_genutzte_fläche versehen, oder? So fügtest Du eindeutige Informtationen zu unserem Datenbestand hinzu, die sich später mal konvertieren lassen, wenn sich andere Tags durchgesetzt haben. Gruß, ce ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie und wo Mailingliste einrichten?
Am Donnerstag 05 Juni 2008 schrieb Holger Schrader: Hallo, Danke für die Tipps. Ich meinte schon eine ML in der OSM´ler aus einer Stadt oder einem Landkreis miteinander kommunizieren können. openstreetmap.org/.de wär natürlich sinniger, aber wenn das ein Problem darstellt, frag mich nochmal, dann kann ich das bei mir auch hosten. -- Hanno Böck Blog: http://www.hboeck.de/ GPG: 3DBD3B20 Jabber/Mail:[EMAIL PROTECTED] signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Flyer sind bald alle
2008/6/4 Sven Geggus [EMAIL PROTECTED]: Frederik Ramm [EMAIL PROTECTED] wrote: Die Bilder sind selbst gemacht bzw. aus zur Veroeffentlichung frei gegebenem Pressematerial. Wenn Du sowieso gerade am ändern bist, vielleicht nimmst Du statt nem GPSmap nen Etrex Vista oder Legend. hatten die nicht so komische Probleme mit Abweichungen in Tracks? Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Landwirtschaftliche Flächen in Deuts chland
Heiko Jacobs schrieb: Moin Zitat von Bernd Wurst [EMAIL PROTECTED]: Am Donnerstag, 5. Juni 2008 schrieb Torsten Breda: Worauf man sich sicherlich einigen kann, ist die Bezeichnung von landuse=farm bei innerstädtischen landwirtschaftlichen Flächen. Das widerspricht aber dem verlinkten Wiki-Eintrag: Landuse=farm meint den Landwirtschaftlichen Betrieb, der ja nicht als landuse=residential, industrial oder ähnlichem zu taggen ist. Gemeint ist also der Bauernhof mit direkt angrenzenden Nebengebäuden, Gewächshäusern, Jauchegrube usw. Meist ist das ganze auch umzäunt. Genau... Nee, das ist Unfug. Den eigentlichen Bauernhof kann man sehr gut als residential taggen und das ganze bewirtschaftete (oder auch brachliegende) Land ist landuse=farm. Mehr industrielle Höfe kann man meinetwegen auch als industrial verbuchen. Auf jeden Fall ist es sehr wichtig, das ganze Land zu taggen, damit man sieht, wo Bäume stehen und wo nicht. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Hallo! Am 5. Juni 2008 17:55 schrieb Sven Grüner [EMAIL PROTECTED]: Raphael Studer schrieb: Deine Ausführungen zu landuse=forest und natural=wood finde ich noch interessant. Somit würde das bedeuten. Ich mache eine grosse Fläche landuse=forest, darin eine etwas kleinere Fläche (ca .5 Meter weniger) natural=wood. Überall wo jetzt eine Strasse durch den Wald geht, trenne ich den natural=wood auf und zieh die Strasse durch, das landuse=forrest last ich aber (siehe Angehaengtes Bild). Ja genau. Ich will auch nicht behaupten, dass das jetzt besonders praktikabel ist, geschweige denn, dass ich es selber so machen würde. Aber rein von der Logik die natural= und landuse= woanders innehaben wäre es so. Wo genau haben sie so eine Logik inne? Wenn ich zwei Seen habe, zwischen denen ein schmaler Damm mit Straße verläuft dann mache ich ja auch nicht ein großes natural=water und lege den Highway mittenrein. Gleiches gilt bei Inseln, die man korrekterweise per Multipolygon ausschneiden sollte und nicht ein weiteres natural=land drüber klatscht. Klar, bei zwei Seen zeichnet man auch zwei Seen ein - aber das eine Straße, die durch einen Wald führt, daraus nun zwei Wälder macht, finde ich nicht unbedingt. Ein Industriegelände besteht auch nicht aus zig Flächen, nur weil man für die Straßen ein Schachbrettmuster haben. Das ist eine Fläche, in der Straßen und Gebäude liegen. Die Unterscheidung ziwschen natural=wood für Urwälder und landuse=forrest für bewirtschaftete Wälder finde ich total absurd. Das sind zwei vollkommen verschiedene Eigenschaften die da gegenüber gestellt werden. Ersteres besagt, was an einem Ort physisch anzutreffen ist und der landuse fasst die ganze Gegend thematisch zusammen, ohne zu sagen, was dort nun genau ist. Mal ganz unvoreingenommen: Was erwartest du in einem landuse=forest (Managed forest or woodland plantation / Forst, Landwirtschaftlich genutzter Wald) zu finden? Für den Laien (wie mich) unterscheidet sich das ganze von einem Naherholungsgebiet ohne forstwirtschaftliche Nutzung, oder auch einem ganz unbewirtschaftetem Gebiet nicht sonderlich - da sind halt Bäume. Den Grund warum man es trotzdem eintragen sollte wenn man es weiß was im dunklen Wald so vor sich geht, nennst du ja selber: Das eine beschreibt das Physische, das andere die Nutzung - und diese Werte werden nicht gegenüber, sondern nebeneinander gestellt. Das wäre als ob ich das Gewicht des Apfels mit der Farbe der Birne vergleiche. Nein, das wäre so als würdest du die Funktion = Frucht und die Nutzung = Nahrung für beide erfassen würdest, während ein Stechapfel die Nutzung = Gift bekommt. Wenn das dann mal jemand nach Gewicht und Farbe filtern will - bitte. Übrigens: Wenn natural nur bei Objekten verwendet werden darf, die so Menschen-fern entstanden sind wie ein Urwald, sollten wir uns schleunigst neue Tags für Seen, Küsten, Sümpfe, Strände, etc. überlegen. Sehe ich wirklich so: Ein Baggerloch sollte man schon irgendwie als solches kennzeichnen können - auch renaturierte / rekultivierte Gebiete können wir bisher nicht vernünftig eintragen. Da könnten ein paar Tags nicht schaden. Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] [Leicht OT] Rekorde
Hallo zusammen, ich habe soeben meinen persönlichen Upload-Rekord von 1074 hochzuladenen Änderungen mit 5207 Änderungen um fast das fünffache überboten... Puh... ich sage euch, das war ganz schön anstrengend. Ich sitze ja auch seit neun Uhr gestern Abend über JOSM. Trotzdem ist nun meine Region um einiges reicher... Ich bin mal auf das gerenderte Ergebnis gespannt. Der Upload dauerte übrigens über 32 Minuten. Und da in letzter Zeit die Telek0m des öfteren mitten drin die Verbindung kappt waren das ganz schön spannende Minuten... Ich sah das Unheil schon vor mir: 3500 Nodes doppelt... Gut das es diesmal auf Anhieb geklappt hat. Was waren eigentlich eure persönlichen Rekorde in Sachen Änderungen zum Hochladen? Grüße und gute Nacht! Michael signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [Leicht OT] Rekorde
Michael Bemmerl schrieb: ich habe soeben meinen persönlichen Upload-Rekord von 1074 hochzuladenen Änderungen mit 5207 Änderungen um fast das fünffache überboten... Schön, sehr schön -- aber warum machst du keine Zwischenuploads ?-) -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] [Leicht OT] Rekorde
Hallo. Am Freitag, 6. Juni 2008 schrieb Michael Bemmerl: Was waren eigentlich eure persönlichen Rekorde in Sachen Änderungen zum Hochladen? Aufgrund einschlägiger Erfahrungen mit meiner DSL-Verbindung und JOSM habe ich mir angewöhnt, wann immer es geht die Änderungen sofort hochzuladen. Aber einmal habe ich eine halbe Kleinstadt offline gemapped, gespeichert und später hochgeladen. War aber nicht viel, vielleicht 200 Änderungen oder sowas... Gruß, Bernd -- Das Leben ist eine endlose Aneinanderreihung von demütigenden Niederlagen, bis man sich nur noch wünscht, Flanders wäre tot. - Homer Simpson signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Florian Lohoff wrote: Die Straße oder der Weg im Openstreetmap wiederum ist keine grenze sondern eine mitte. D.h. das wiederbenutzen von punkten der straße fuer eine angrenzende flaeche mag schoen fuer den renderer oder auch praktisch sein - aber in meinen augen eben falsch weil das waldstueck nicht in der mitte der straße beginnt (nein - es stehen keine baeume in der mitte der straße) sondern an deren seitenstreifen. Mal abgesehen davon, dass wir z.Z. jenseits der aktuellen Datengenauigkeit diskutieren: Beginnt ein Wald eigentlich am aeussersten Baumstamm, oder gehoert da auch noch die Flaeche unter seinen Aesten hinzu? Die zweite Variante entspricht eher meiner Wahrnehmung, wenn ich unter den Baeumen bin, bin ich auch im Wald. Nach dieser Auslegung, wuerde der Wald dann aber haeufig durchaus innerhalb (oder sogar jenseits) der Strassenflaeche beginnen, und auch Wege und Strassen durch den Wald wuerden innerhalb der Waldflaeche liegen. Da z.Z. die meisten Waldgebiete anhand von Luftbildern eingetragen werden, duerfte auch die haeufigere Nutzung fuer die zweite Variante sprechen. Momentan vermeide ich das mehrfache Nutzen von Nodes fuer Wege und Flaechen aus der rein praktischen Erwaegung, dass ich das bei spaeteren Erweiterungen der Daten eher hinderlich finde. Wahrscheinlich kann ich aber nur noch nicht richtig mit JOSM umgehen. Gruss Torsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Routingfaehige Garminkarten
Am Mittwoch, 4. Juni 2008 22:12 schrieb Frederik Ramm: Hallo, Ich für meinen Teil ich wäre gerne bereit jemandem 20€ zukommen zu lassen, wenn der in Zukunft regelmäßig aktuelle, routingfähige OSM Karten irgendwo zum Download bereitstellt. (Da habe ich schon mehr Geld für nutzlosere Dinge ausgegeben) Ich wuerde eigentlich gern jemandem 20€ zukommen lassen, damit der die existierende freie Software um die Faehigkeit erweitert, Routingkarten zu machen, anstatt €20 fuer eine Lizenz auszugeben ;-) Ja, ich wäre auch sehr interessiert. Wenn nur noch ein paar Bytes im Header fehlen könnte man sich die Information was diese bedeuten evtl. vom Entwickler von cGPSmapper für ein paar Euro abkaufen. Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Overlapping ways bei einer area
Stefan Schwan schrieb: Am 5. Juni 2008 17:55 schrieb Sven Grüner [EMAIL PROTECTED]: Die Unterscheidung ziwschen natural=wood für Urwälder und landuse=forrest für bewirtschaftete Wälder finde ich total absurd. Das sind zwei vollkommen verschiedene Eigenschaften die da gegenüber gestellt werden. Ersteres besagt, was an einem Ort physisch anzutreffen ist und der landuse fasst die ganze Gegend thematisch zusammen, ohne zu sagen, was dort nun genau ist. Ja, sehe ich auch so. Mal ganz unvoreingenommen: Was erwartest du in einem landuse=forest (Managed forest or woodland plantation / Forst, Landwirtschaftlich genutzter Wald) zu finden? Für den Laien (wie mich) unterscheidet sich das ganze von einem Naherholungsgebiet ohne forstwirtschaftliche Nutzung, oder auch einem ganz unbewirtschaftetem Gebiet nicht sonderlich - da sind halt Bäume. In einem landwirtschaftl. genutzten Wald muss man (vor allen Dingen in Hessen) damit rechnen, dass tracks regelm#257;ßig bis zur Unbenutzbarkeit verhunzt sind. Sehe ich wirklich so: Ein Baggerloch sollte man schon irgendwie als solches kennzeichnen können - auch renaturierte / rekultivierte Gebiete können wir bisher nicht vernünftig eintragen. Da könnten ein paar Tags nicht schaden. Jein ;) Manchmal ist weniger mehr. Es wäre gut, den Grundbestand der Haupttags erstmal nicht zu erweitern und stattdessen einfach zus#257;tzlich Attribute zu setzen. -- Karl Eichwalder ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-es] Autovía Salamanca-Bejar
Hola, alguien ha pintado la carretera entre Salamanca y Bejar como autovía. Ha debido ser un viajero del tiempo porque yo estuve por allí hace dos semanas y todavía no existe. Un saludo, Miguel -- __ Miguel R. luaces [EMAIL PROTECTED] Facultade de Informática Tf. (34) 981 167000 ext. 1254 Universidade da Coruña Fax. (34) 981 167160 _ http://lbd.udc.es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-es
Re: [Talk-es] Autovía Salamanca-Bejar
On Thu, 2008-06-05 at 17:22 +0200, Miguel R. Luaces wrote: Hola, alguien ha pintado la carretera entre Salamanca y Bejar como autovía. Ha debido ser un viajero del tiempo porque yo estuve por allí hace dos semanas y todavía no existe. hmm, como estuve hace poco por ahí, no sé si he sido yo, yo pinté la autovía A-62 entre Valladolid y Salamanca, no sé si es a la que te refieres, puesto que por Béjar no recuerdo haber pasado. Y por donde yo fui, todo era autovía, hasta la entrada a Salamanca -- Rodrigo Moya [EMAIL PROTECTED] ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-es
Re: [Talk-es] Identificación de carretera de Colmenar M607
Buenas, la M-607 la mejoraron hasta ser una autopista entre Madrid y Colmenar Viejo. Más allá (de Colmenra Viejo), en un punto determinado (que han ido prolongando, por lo que ahora mismo no sé hasta donde llega) volvía a ser una vía primary porque perdía alguna(s) característica(s) de las autovías. Quizá por eso mantenga el color naranja, como la M-503, porque no toda es autovía, sino sólo algunos tramos... En una de las salidas de Tres Cantos a la M-607, la del km 21 en dirección Madrid, hay un cartel antiguo que anuncia la carretera con fondo verde como la C-607 :) Un saludo, Jonás. El 3/06/08, Rodrigo Moya [EMAIL PROTECTED] escribió: On Mon, 2008-06-02 at 14:28 +0200, Iván Sánchez Ortega wrote: El Lunes, 2 de Junio de 2008, Pablo Gómez escribió: Entiendo que tal y como lo planteas, rige el azul antes que el blanco. Sí. Fondo azul con referencia en naranja = autovía. Y las autovías, quedamos en que son highway=motorway. (Sobre el diferenciar autopistas y autovías (si es que se necesita hacer), se puede hacer viendo la primera letra de la referencia, si es A o AP o R). y con toll=yes|no ¿no? -- Rodrigo Moya [EMAIL PROTECTED] ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-es -- Jonás Andradas Skype: jontux LinkedIn: http://www.linkedin.com/in/andradas GPG Fingerprint: 5A90 3319 48BC E0DC 17D9 130B B5E2 9AFD 7649 30D5 Keyservers: wwwkeys.eu.pgp.net | pgp.rediris.es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-es
Re: [Talk-cz] Plochy vod v OSM
No ja jsem se zbavil IDcek OSM, takze jsem usetril spoustu mista. IDcko s indexem by zabralo mnohdy vice nez cela geometrie a atributy. Proto mam vsechny primitiva precislovana (nova ID se pouzivaji v routingu) a tim usetrim hodne mista. Pokud by nekdo potreboval puvodni ID muze se pouzit nejaky prevod IDcek z novych na puvodni. Software je ale jako prohlizecka. Neni navrzen jako editor (i kdyz editovat geometrie jde) a tudiz jsem od tohoto oprosten. Moje priorita je minimalizace mista. Velikosti datasetu nejsem omezen. Myslim, ze by stejny model mohl postihnout cely svet bez ujmy na rychlost. Umi dynamicky pripojovat dalsi datasety, ktere se pri renderingu chovaji jako jeden. Pote se muze vygenerovat napr. CR, SK apod. A clovek si stahne mapy jen co potrebuje, nahraje do adresare data a ma je spojene. Velikost se da odhadnout z bz2. Docela to vychazi, ze je to priblizne 25% osm.bz2 souboru. Nyni jsem s vyvojem casove na stiru, ale uz to aspon umi ty diry. Naportoval jsem na WinCE, kde vse bezi OK, ale neni moc rychle i presto, ze jsem zrychlil puvodni rendering. Delam tedy na rychlem draft rendereru, ktery bude pouzit pri tahani mysi a po zastaveni mapu vyhladi, vykresli detaily, pisma apod. Docela uz to chodi, ale ted nemam moc cas uklidit kod a udelat release. Jinak k josm-ng. Vas ani tak nepali velikost datoveho souboru, takze bych pouzil sqlite, ktery se na tohle hodi vyborne. Je rychly, maly, jednoduchy. Nad databazi si udelate abstrakci get..., set..., remove..., nebo klidne JPA, ale to uz je asi kanon na brabce. Petr Nejedly napsal(a): Tomas Kolda napsal(a): Takze pre alpha je zde: http://www.web2net.cz/osm/dist.zip Zatim to neumi nazvy cehokoliv (v databazi jiz jsou), zoom maximalne 1:10 (ostatni nejsou vygenerovany) a je tam naprosto zakladni nastaveni barvicek. Nejsou vsechny dle OSM, ale tak jak se to libi mne. Hlavne highways jsou uplne jinak. Pri nejvetsim zoomu (1:1) jsou cervene videt features, ktere nemaji nastaveny vzhled (barvy apod.). Je tam videt i ta chyba s Berounkou... Vratil bych se k tomuhle. Jak velky dataset zvladnete a jak by byla velka ta databaze pod tim. Germany.osm (7.5M nodes, 1M ways)? Planet.osm (200M nodes, 20M ways)? Do josm-ng jsem udelal mirnou opravu smerem k moznosti prace s jeste vetsimi datasety - vyclenil jsem z DataSetu implementaci storage a od ni pozaduju zhruba nasledujici API: getNode(long) getWay(long) getRelation(long) getPrimitives(Bounds, DeailLevel) implementaci getPrimitives(Bounds, DetailLevel) zrejme mate (vicevrstvy spatial index), zbytek je vcelku trivialni (pridavny jednorozmerny index). Ja zatim na tuhle datovou strukturu nemam cas :-) tak vse drzim v pameti, coz se pro czechia.osm stale da ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-cz
[OSM-talk-fr] Traduction française de potlatch
Bonjour, Je relaie un message de la liste anglophone. Richard Fairhurst, l'auteur de potlatch, cherche des traducteurs. Vous pouvez lui écrire à [EMAIL PROTECTED] si ça vous intéresse. Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction française de potlatch
Je consacre déjà pas mal de temps à la traduction du wiki. Et en plus, je ne suis pas un grand utilisateur (ni un grand fan je dois avouer) de Potlatch mais si personne d'autre ne se porte candidat, je veux bien servir de roue de secours. Les pages Potlach sur le wiki ont été essentiellement traduites par Dega, Grumly et plus récemment Wekk. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction française de potlatch
Je veux bien mettre la main la pte mais il me faudra une roue de secours pour me corriger. Cela me permettra de connaitre un peu mieux Potlatch, enfin j'espere!! Pieren a crit: Je consacre dj pas mal de temps la traduction du wiki. Et en plus, je ne suis pas un grand utilisateur (ni un grand fan je dois avouer) de Potlatch mais si personne d'autre ne se porte candidat, je veux bien servir de roue de secours. Les pages Potlach sur le wiki ont t essentiellement traduites par Dega, Grumly et plus rcemment Wekk. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction française de potlatch
Comme Pieren je ne suis pas grand utilisateur de Potlatch mais je pourrais tout à fait jeter un oeil aux traductions pour relire tout ça. Renaud. 2008/6/5 Megaten [EMAIL PROTECTED]: Je veux bien mettre la main à la pâte mais il me faudra une roue de secours pour me corriger. Cela me permettra de connaitre un peu mieux Potlatch, enfin j'espere!! Pieren a écrit : Je consacre déjà pas mal de temps à la traduction du wiki. Et en plus, je ne suis pas un grand utilisateur (ni un grand fan je dois avouer) de Potlatch mais si personne d'autre ne se porte candidat, je veux bien servir de roue de secours. Les pages Potlach sur le wiki ont été essentiellement traduites par Dega, Grumly et plus récemment Wekk. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction française de potlatch
J'ai contact Richard pour la suite donner. Renaud Martinet a crit: Comme Pieren je ne suis pas grand utilisateur de Potlatch mais je pourrais tout fait jeter un oeil aux traductions pour relire tout a. Renaud. 2008/6/5 Megaten [EMAIL PROTECTED]: Je veux bien mettre la main la pte mais il me faudra une roue de secours pour me corriger. Cela me permettra de connaitre un peu mieux Potlatch, enfin j'espere!! Pieren a crit : Je consacre dj pas mal de temps la traduction du wiki. Et en plus, je ne suis pas un grand utilisateur (ni un grand fan je dois avouer) de Potlatch mais si personne d'autre ne se porte candidat, je veux bien servir de roue de secours. Les pages Potlach sur le wiki ont t essentiellement traduites par Dega, Grumly et plus rcemment Wekk. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-talk-fr] Traduction française de potlatch
Pareil pour une relecture, il n'y a pas de problèmes. Tu nous tiens au courant, Megaten. 2008/6/5 Megaten [EMAIL PROTECTED]: J'ai contacté Richard pour la suite à donner. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
Re: [OSM-ja] 7/12,13 アイルランドで St ate of The Map 2008
[#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;] wrote: http://www.stateofthemap.org/registration/ この写真をみてください。昨年の参加者です。 45名ほどに見えます。 今年の参加者リスト見つけました http://wiki.openstreetmap.org/index.php/State_Of_The_Map_2008/Who%27s_going%3F 同程度の人数ですね。 行く経路が示されているのがOSMっぽいです。みんなでＧＰＳ取りながら 行くみたいですね。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ja
Re: [OSM-ja] 7/12,13 アイルランドで St ate of The Map 2008
http://www.stateofthemap.org/registration/ この写真をみてください。昨年の参加者です。 45名ほどに見えます。 http://wiki.openstreetmap.org/index.php/State_Of_The_Map_2007 昨年のプログラムでは、のべ35名が発表しています。 つまり、、、しゃべらないだたのお客さんは、10名ほど らしいということです。 ＯＳＭの活動についての国際会議です。 宿泊はvenueですね。 http://www.stateofthemap.org/venue/ 100 bedrooms on site, Quote “Open Street Map” when booking accommodation. Rates Quoted: €100.00 BB Twin/Double Per night or €70.00 BB Single Per night. Limited Rooms Available, book as soon as possible to avoid disappointment. だそうです。会場は、会議施設とホテルのコンプレックス施設。 ベッド＆ブレッドでこの価格、円安ドル安ユーロ高のせいで、ちょっと高く 感じますね。 三浦 -Original Message- From: [#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;] [mailto:[#x30E1;#x30FC;#x30EB;#x30A2;#x30C9;#x30EC;#x30B9;#x4FDD;#x8B77;] On Behalf Of ikiya Sent: Thursday, June 05, 2008 6:41 PM To: OpenStreetMap Japanese talk Subject: Re: [OSM-ja] 7/12,13 アイルランドで State of The Map 2008 興味はあるので「State Of The Map」のwikiとwebサイトはのぞいてみました。 OSMに関する国際（ユーザー）会議と見えますが、 みなさん、一般ユーザーのレベルで参加されているのでしょうか？ また宿泊は会場のホテルになるのしょうか？ ikiya ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-ja
