Re: [talk-ph] Reviving plan(s) for Tagaytay Mapping party
Last call for confirming the date: May 16 in Tagaytay Is the date OK with everybody joining? I want the group's approval so we can distribute the announcement to all those interested in participating in the mapping party. On Fri, Apr 24, 2009 at 5:07 PM, maning sambale emmanuel.samb...@gmail.com wrote: On Wed, Apr 22, 2009 at 7:47 PM, Eugene Alvin Villar sea...@gmail.com wrote: Maybe it should be May 16 or 17? Sorry, I stand corrected so it's May 16 in Tagaytay maning eugene rally andre ianlopez (85%) murlwe (will try) neil Anymore? Rally proposes to carpool to share fuel costs. -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- -- cheers, maning -- Freedom is still the most radical idea of all -N.Branden wiki: http://esambale.wikispaces.com/ blog: http://epsg4253.wordpress.com/ -- ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-talk] authorization to import Lombardy data in OSM
On Wed, Apr 29, 2009 at 1:11 AM, Frederik Ramm frede...@remote.org wrote: Information about that information goes into the changeset: Why do we known, how did we measure, who gave us permission, and what music did we hear during out editing session. I think you are right, adding information to the changeset will be enough. -S ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
Splitter tries to automatically determine the maximum tile size for a specific area but the data in that area is giving Splitter false clues. This might be caused by e.g. a combination of many POI's but few roads. One way of working around those problem areas is to force Splitter to dimension the tiles so that they fewer nodes using the --max-nodes option. This is what I've done and now most of the world is rendered by Mkgmap without problems, except the ones in Denmark. Carsten Nielsen wrote: Very nice, but what is the reason for exactly those maps not beeing generated yet ? Carsten Nielsen Lambertus skrev: I plan to have those missing tiles for Denmark on http://garmin.na1400.info/routable.php fixed with the next update which is within a week. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] authorization to import Lombardy data in OSM
Simone Cortesi simone at cortesi.com writes: On Wed, Apr 29, 2009 at 1:11 AM, Frederik Ramm frederik at remote.org wrote: Information about that information goes into the changeset: Why do we known, how did we measure, who gave us permission, and what music did we hear during out editing session. I think you are right, adding information to the changeset will be enough. What happens if the Regional Administration of Lombardy would some day offer a major update to the data to be imported now? Can the imported features be identified later so that they could be updated or deleted+inserted again? Update should naturally happen automatically only if no OSM user has touched the feature after initial import. I think that guidelines for updating imported data comes more and more important. We have already imports from AND, Tiger, Canadian, German and African sources, French cadastre, Estonian city data, Italian data, MassGIS etc. OSM is not at all just user contributed data. Perhaps it could be better described as a collection of user contributed imported data enhanced by users. Great deal of the imported data is maintained by the original data providers. It would be a waste of OSM resources not to take the updates as well. -Jukka Rahkonen- ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] authorization to import Lombardy data in OSM
On Wed, Apr 29, 2009 at 10:45 AM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: What happens if the Regional Administration of Lombardy would some day offer a major update to the data to be imported now? Can the imported features be identified later so that they could be updated or deleted+inserted again? Update should naturally happen automatically only if no OSM user has touched the feature after initial import. will the initial import be done automatically? if so, it may be useful to let a new ad-hoc user do it, and later assume that whatever has that user as the last author hasn't been changed this would also help with copyright issues -- Elena ``of Valhalla'' homepage: http://www.trueelena.org email: elena.valha...@gmail.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] authorization to import Lombardy data in OSM
Elena of Valhalla wrote: On Wed, Apr 29, 2009 at 10:45 AM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: What happens if the Regional Administration of Lombardy would some day offer a major update to the data to be imported now? Can the imported features be identified later so that they could be updated or deleted+inserted again? Update should naturally happen automatically only if no OSM user has touched the feature after initial import. will the initial import be done automatically? if so, it may be useful to let a new ad-hoc user do it, and later assume that whatever has that user as the last author hasn't been changed this would also help with copyright issue Why not just use the changeset ID... that's what its there for after all. -- Chris Jones, SUCS Admin http://sucs.org ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] coastline accuracy?
Hi Folks I'm new to mapping, and looking at the newbie list archives I could not see anything that addressed my question, so here I jump into the mainstream. I recently spent some time on a small island in the Mediterranean. As the area was not well covered in Openstreetmap, I took GPS traces of everywhere I went, and used those to add some tracks and roads to the mapping using Potlatch. I was staying very near the east coast, and noticed that tracks near the coast appeared too far inland (further west than expected) when the GPS tracks were plotted. They also seemed too far inland when looking at the Yahoo background layer in Potlatch. But when I travelled many already mapped roads, my tracks overlaid these accurately. Also, repeated journeys roads were tightly overlaid, so I think the GPS unit accuracy was good. Some of the existing roads were apparently in the sea, and my GPS tracks from these roads joined and overlaid the existing mapping almost exactly. Everything seems shifted approximately to the south-west relative to the coastal outline. So what's going on here? Are the coastline traces somehow displaced, and if so, how can this be corrected ? regards Martyn ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
Lambertus wrote: Splitter tries to automatically determine the maximum tile size for a specific area but the data in that area is giving Splitter false clues. This might be caused by e.g. a combination of many POI's but few roads. Not to diminish your work on that front, but I find the tilelayout on your site very strange. Of course it is a work of the splitter, but I would opt for a manual layout, guided by an initial automated process. IMHO the strategy that the Mapsource tiles use is much more logical. Take one big tile, if that has too many nodes, split it in half horizontally, if that has too many nodes split it in half vertically... repeat until you have a sufficient small amount of nodes. Regards, Maarten ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
On Wed, Apr 29, 2009 at 11:25:20AM +0100, mle wrote: So what's going on here? Are the coastline traces somehow displaced, and if so, how can this be corrected ? Coastline traces are often inaccurate, and often displaced. The best option is to adjust them manually. At least in JOSM I can move the landsat layer. So I'll try to match the landsat layer to known features, for example roads visible on the satelitte images. Then, I'll move the coastline manually so that it matches the landsat images A bit tedious, but I'll normally always do it if I map so close to the sea that this accuracy becomes important. -- - Vegard Engen, member of the first RFC1149 implementation team. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
mle schrieb: I was staying very near the east coast, and noticed that tracks near the coast appeared too far inland (further west than expected) when the GPS tracks were plotted. They also seemed too far inland when looking at the Yahoo background layer in Potlatch. [...] So what's going on here? Are the coastline traces somehow displaced, and if so, how can this be corrected ? The Coastlines were mainly bulk imported from PGS, which sometimes is quite inaccurate. Feel free to adjust the coastline according to Yahoo Imagery (if the imagery matches your GPS positions, otherwise you'll have to adjust that first.) -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] GeoQR - Geocoding Video with QRCodes
Hi all, this might be a bit off-topic for OSM Talk, but I thought I'd share this for anyone who fancies doing video surveys with stuff they may already own. This video demonstrates the end-product:- a video with each frame geocoded using QR Codes (those 2D barcode things) and thus individually indexed: http://www.flickr.com/photos/crouchingbadger/3484029269/ It's all explained here: http://www.badgertrack.com/?p=37 Part 2 will explain how it extracts, but I'm still writing that. Cheers Ben -- b...@crouchingbadger.com | http://crouchingbadger.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
Lambertus wrote: Maarten Deen wrote: Lambertus wrote: Splitter tries to automatically determine the maximum tile size for a specific area but the data in that area is giving Splitter false clues. This might be caused by e.g. a combination of many POI's but few roads. Not to diminish your work on that front, but I find the tilelayout on your site very strange. Of course it is a work of the splitter, but I would opt for a manual layout, guided by an initial automated process. Please forgive me for relying on the automated Splitter layout mechanism as I have no intention to manually divide the world into 500 tiles (317 America + 182 Europe/Asia/Africa/Oceania currently). Optimizing the tiles would result in even more, so you'd be talking about e.g 750 tiles. I'm certainly not complaining about your work. It's the reason why I bought a Garmin Nüvi and not a TomTom. Needless to say: patches welcome ofcourse. The definition files for Splitter are: - http://planetosm.oxilion.nl/~lambertus/america.list - http://planetosm.oxilion.nl/~lambertus/eurasia.list IMHO the strategy that the Mapsource tiles use is much more logical. Take one big tile, if that has too many nodes, split it in half horizontally, if that has too many nodes split it in half vertically... repeat until you have a sufficient small amount of nodes. This strategy is afaik exactly what Splitter does. Then it does it in a strange way. I'm sure you've noticed that the edges of the tiles don't line up by just a few 1/100th of a degree in a lot of places. That is inconsistent with a strategy of dividing a tile in half if it has too many nodes. E.g. tiles 63240113 and 63240116. One has a north border of 51.679688, the other 51.635742. And then two tiles further east, 63240120 has a north border of 52.679688 again. BTW: have you seen that Mapsource draws the maps as overlapping? I've attached a screenshot of how Mapsource displays maps 63240105 (yellow), 63240175 (blue, continuing to the top) and 63240179 (green). They all overlap eachother. According to their definitions, they should not overlap, but mapsource apparently disagrees. Any idea why that is? Maarten inline: OSMmapsource.png___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
2009/4/29 Alice Kaerast kaer...@qvox.org: On Wed, 29 Apr 2009 11:25:20 +0100 mle i...@dynoyo.plus.com wrote: I was staying very near the east coast, and noticed that tracks near the coast appeared too far inland (further west than expected) when the GPS tracks were plotted. They also seemed too far inland when looking at the Yahoo background layer in Potlatch. Align the Yahoo imagery with your traces, as it's not always aligned correctly initially. The imagery only ever gives an idea of what is on the ground, we don't the state of the tide when the imagery was taken, there may have been coastal erosion or sea rising/falling since then, etc. You seem confident that your traces are accurate, don't worry about editing existing coastline data if you believe it is incorrect. And remember the coastline should show the mid-tide level. -- Alice Talking of the tide, How should Tidal Roads be marked, The main road the Holy Island in the UK is just tagged Note: Tidal. which just does not seam right. I'm thinking there must be quite a few Roads, Paths etc that can only be used at high tide. Not being anywhere near it I don't feel it right to correct it however Peter. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
Maarten Deen wrote: Lambertus wrote: Maarten Deen wrote: Not to diminish your work on that front, but I find the tilelayout on your site very strange. Of course it is a work of the splitter, but I would opt for a manual layout, guided by an initial automated process. Please forgive me for relying on the automated Splitter layout mechanism as I have no intention to manually divide the world into 500 tiles (317 America + 182 Europe/Asia/Africa/Oceania currently). Optimizing the tiles would result in even more, so you'd be talking about e.g 750 tiles. I'm certainly not complaining about your work. It's the reason why I bought a Garmin Nüvi and not a TomTom. See Garmin...this is why you need to publicize your map format :-) Needless to say: patches welcome ofcourse. The definition files for Splitter are: - http://planetosm.oxilion.nl/~lambertus/america.list - http://planetosm.oxilion.nl/~lambertus/eurasia.list IMHO the strategy that the Mapsource tiles use is much more logical. Take one big tile, if that has too many nodes, split it in half horizontally, if that has too many nodes split it in half vertically... repeat until you have a sufficient small amount of nodes. This strategy is afaik exactly what Splitter does. Then it does it in a strange way. I'm sure you've noticed that the edges of the tiles don't line up by just a few 1/100th of a degree in a lot of places. That is inconsistent with a strategy of dividing a tile in half if it has too many nodes. E.g. tiles 63240113 and 63240116. One has a north border of 51.679688, the other 51.635742. And then two tiles further east, 63240120 has a north border of 52.679688 again. Well, maybe not exactly in half, but the idea is the same. Afaik, the reason why Splitter doesn't split exactly in half is that there is less chance that a polygon is present in too many tiles. BTW: have you seen that Mapsource draws the maps as overlapping? I've attached a screenshot of how Mapsource displays maps 63240105 (yellow), 63240175 (blue, continuing to the top) and 63240179 (green). They all overlap eachother. According to their definitions, they should not overlap, but mapsource apparently disagrees. Any idea why that is? I've seen this with topo maps made with older versions of Mkgmap as well. This might be a bug in Mkgmap or a misunderstanding of the Garmin map format but I don't think it's harmful though. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
On Wednesday 29 April 2009 12:48:06 Alice Kaerast wrote: And remember the coastline should show the mid-tide level. No, it should show the high-tide level. Most coastline data in OSM is based on PGS data, which shows the high-tide level. See: http://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dcoastline#Tidal_position -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
On Wed, 29 Apr 2009 14:39:26 +0200 Cartinus carti...@xs4all.nl wrote: On Wednesday 29 April 2009 12:48:06 Alice Kaerast wrote: And remember the coastline should show the mid-tide level. No, it should show the high-tide level. Most coastline data in OSM is based on PGS data, which shows the high-tide level. See: http://wiki.openstreetmap.org/wiki/Tag%3Anatural%3Dcoastline#Tidal_position It's a good job you pointed that out, I've always been led to believe it was mid-tide level and am going to do some tweaking of some coastlines soon. I'm sure there's either a wiki page or a list post suggesting it should be mid-tide somewhere. -- Alice ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
It's a good job you pointed that out, I've always been led to believe it was mid-tide level and am going to do some tweaking of some coastlines soon. I'm sure there's either a wiki page or a list post suggesting it should be mid-tide somewhere. We should really have both a high tide and a low tide coastline, so I can tag the natural=beach (or mud or whatever) bits between them better. I've tweaked a number of coastlines around here based on traces I've taken when walking along the seafront - mainly to push them far enough out that I was walking on the wall and not in the sea. Oh, and so that the marina car park was on dry land. I've called up the imagery and in some cases it seems the coastlines have been traced off what someone has guessed is the coastline, but can't tell dark patches of saltmarsh or mud from water and in places is quite wrong. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] authorization to import Lombardy data in OSM
2009/4/29 Chris Jones roller...@sucs.org: Elena of Valhalla wrote: On Wed, Apr 29, 2009 at 10:45 AM, Jukka Rahkonen jukka.rahko...@mmmtike.fi wrote: What happens if the Regional Administration of Lombardy would some day offer a major update to the data to be imported now? Can the imported features be identified later so that they could be updated or deleted+inserted again? Update should naturally happen automatically only if no OSM user has touched the feature after initial import. will the initial import be done automatically? if so, it may be useful to let a new ad-hoc user do it, and later assume that whatever has that user as the last author hasn't been changed this would also help with copyright issue Why not just use the changeset ID... that's what its there for after all. The changeset comment would work, rather than ID -- the changesets need to be very small these days, so it takes thousands of IDs for an import. Cheers ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
On Wednesday 29 April 2009 14:57:06 Ed Loach wrote: It's a good job you pointed that out, I've always been led to believe it was mid-tide level and am going to do some tweaking of some coastlines soon. I'm sure there's either a wiki page or a list post suggesting it should be mid-tide somewhere. We should really have both a high tide and a low tide coastline, so I can tag the natural=beach (or mud or whatever) bits between them better. I've tweaked a number of coastlines around here based on traces I've taken when walking along the seafront - mainly to push them far enough out that I was walking on the wall and not in the sea. Oh, and so that the marina car park was on dry land. I've called up the imagery and in some cases it seems the coastlines have been traced off what someone has guessed is the coastline, but can't tell dark patches of saltmarsh or mud from water and in places is quite wrong. Ed ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk Nothing on the tag:natural=coastline page says you can't tag anything on the sea-side of it. See http://wiki.openstreetmap.org/wiki/Tag:natural=wetland And then the extended usage: wetland=tidalflat wetland=saltmarsh wetland=mangrove -- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OSM maps of Denmark for download to Garmin devices
On Wed, Apr 29, 2009 at 5:31 AM, Lambertus o...@na1400.info wrote: Maarten Deen wrote: Lambertus wrote: Maarten Deen wrote: Not to diminish your work on that front, but I find the tilelayout on your site very strange. Of course it is a work of the splitter, but I would opt for a manual layout, guided by an initial automated process. Please forgive me for relying on the automated Splitter layout mechanism as I have no intention to manually divide the world into 500 tiles (317 America + 182 Europe/Asia/Africa/Oceania currently). Optimizing the tiles would result in even more, so you'd be talking about e.g 750 tiles. I'm certainly not complaining about your work. It's the reason why I bought a Garmin Nüvi and not a TomTom. See Garmin...this is why you need to publicize your map format :-) Needless to say: patches welcome ofcourse. The definition files for Splitter are: - http://planetosm.oxilion.nl/~lambertus/america.listhttp://planetosm.oxilion.nl/%7Elambertus/america.list - http://planetosm.oxilion.nl/~lambertus/eurasia.listhttp://planetosm.oxilion.nl/%7Elambertus/eurasia.list IMHO the strategy that the Mapsource tiles use is much more logical. Take one big tile, if that has too many nodes, split it in half horizontally, if that has too many nodes split it in half vertically... repeat until you have a sufficient small amount of nodes. This strategy is afaik exactly what Splitter does. Then it does it in a strange way. I'm sure you've noticed that the edges of the tiles don't line up by just a few 1/100th of a degree in a lot of places. That is inconsistent with a strategy of dividing a tile in half if it has too many nodes. E.g. tiles 63240113 and 63240116. One has a north border of 51.679688, the other 51.635742. And then two tiles further east, 63240120 has a north border of 52.679688 again. Well, maybe not exactly in half, but the idea is the same. Afaik, the reason why Splitter doesn't split exactly in half is that there is less chance that a polygon is present in too many tiles. BTW: have you seen that Mapsource draws the maps as overlapping? I've attached a screenshot of how Mapsource displays maps 63240105 (yellow), 63240175 (blue, continuing to the top) and 63240179 (green). They all overlap eachother. According to their definitions, they should not overlap, but mapsource apparently disagrees. Any idea why that is? I've seen this with topo maps made with older versions of Mkgmap as well. This might be a bug in Mkgmap or a misunderstanding of the Garmin map format but I don't think it's harmful though. Probably the reason for the overlap is nodes shared on a polyline which crosses a tile boundary, to prevent gaps. These shared nodes would extend the boundaries of each tile somewhat into the space of the neighboring tile. Otherwise, each tile would have to have a node exactly on the border, and the map resolution might not allow that. Shared nodes are required in routable maps (the shared nodes are marked as external to allow routing across tiles). Another reason I just thought of, which may explain why the overlap looks so large (larger than could be explained by shared nodes) is possibly the map projection used by MapSource. The projection might distort the map boundaries from a rectangle into something warped, but for simplicity MapSource only draws a straight line (not great circle) between the map boundary segments. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Python API
Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. May I put sources on the dev server ? -- Etienne [1] http://wiki.openstreetmap.org/wiki/PythonOsmApi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
On 29 Apr 2009, at 17:00, Etienne Chové wrote: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. May I put sources on the dev server ? Wouldn't it be better to put them into SVN? Shaun ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GeoQR - Geocoding Video with QRCodes
Hi all, this might be a bit off-topic for OSM Talk, but I thought I'd share this for anyone who fancies doing video surveys with stuff they may already own. Hey, a man after my own heart - I'd have used datamatrix though ;-) The only question I have (and this is not a put down) is why? Any encoding on the video image is going to reduce the quality of the barcode image and thus make it a little harder to read and apart from being cool not many people can read 2D barcodes by eye. Personally I would think encoding the NMEA string into APRS beacons (or the like) onto the audio track would be the way to go. That way it could be done without any processing power in the car - just a GPS, APRS encoder (can be a simple as a PIC or OpenTracker) and a camcorder with a line/mic input. If you are going to process the video you could render the GPS data as a human readable graphic overlay (think speedometer, compass heading, lat/long, etc) onto the video... but why not include a 2D barcode too. Anyway 'way cool', Simon. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
Shaun McDonald a écrit : On 29 Apr 2009, at 17:00, Etienne Chové wrote: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. May I put sources on the dev server ? Wouldn't it be better to put them into SVN? It's what I'd like to say ;-) -- Etienne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
See also the osmparser.py class, that may also be useful. http://trac.openstreetmap.org/browser/applications/editors/django/osmeditor/lib/osmparser.py 2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. May I put sources on the dev server ? -- Etienne [1] http://wiki.openstreetmap.org/wiki/PythonOsmApi ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. COOL! I was thinking of writing such a class myself, but it's great you did it :) . May I put sources on the dev server ? May I suggest keeping it in a git repository so other people than the ones with commit access to the openstreetmap svn can contribute? I have used repo.or.cz which is a free service offered by Petr Baudis, author of many improvements in the git user interface for the osm-helpers improved code. I am probably going to be one of your early adopters :-) -- Regards, EddyP = Imagination is more important than knowledge A.Einstein ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
2009/4/29 Etienne Chové ch...@crans.org: Thomas Wood a écrit : See also the osmparser.py class, that may also be useful. http://trac.openstreetmap.org/browser/applications/editors/django/osmeditor/lib/osmparser.py Interesting... does it work with API 0.6 and changesets ? (see 0.5 inside). Not yet, I was thinking of updating it, since the original author doesn't seem to have... -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
Eddy Petrișor a écrit : 2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. COOL! I was thinking of writing such a class myself, but it's great you did it :) . May I put sources on the dev server ? May I suggest keeping it in a git repository so other people than the ones with commit access to the openstreetmap svn can contribute? I have used repo.or.cz which is a free service offered by Petr Baudis, author of many improvements in the git user interface for the osm-helpers improved code. I am probably going to be one of your early adopters :-) I can put it where ever people want it. I think svn.openstreetmap.org is the best. Where to ask to get svn account ? -- Etienne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
Thomas Wood a écrit : See also the osmparser.py class, that may also be useful. http://trac.openstreetmap.org/browser/applications/editors/django/osmeditor/lib/osmparser.py Interesting... does it work with API 0.6 and changesets ? (see 0.5 inside). -- Etienne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
On Wed, Apr 29, 2009 at 7:37 PM, Etienne Chové ch...@crans.org wrote: Eddy Petrișor a écrit : 2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. COOL! I was thinking of writing such a class myself, but it's great you did it :) . May I put sources on the dev server ? May I suggest keeping it in a git repository so other people than the ones with commit access to the openstreetmap svn can contribute? I have used repo.or.cz which is a free service offered by Petr Baudis, author of many improvements in the git user interface for the osm-helpers improved code. I am probably going to be one of your early adopters :-) I can put it where ever people want it. I think svn.openstreetmap.org is the best. Where to ask to get svn account ? Well, that's the nice thing about git, you don't need to request access from anyone. See more information about the service provided by Petr: http://repo.or.cz/about.html More information about how to create the project and how to create a user to be able to publish your changes is on pages linked from the one above. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. May I put sources on the dev server ? [1] http://wiki.openstreetmap.org/wiki/PythonOsmApi BTW, under which license are publishing your changes? May I suggest one of 'LGPL', 'GPL v2 or later' or 'GPL v3 or later'? I would be fine with either of those, but I think LGPL would be the best choice for such code as a library. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
2009/4/29 Etienne Chové ch...@crans.org: Eddy Petrișor a écrit : 2009/4/29 Etienne Chové ch...@crans.org: Dears, I wrote a python class to communicate with OSM API (read, write, update). For interested users, informations are here [1]. COOL! I was thinking of writing such a class myself, but it's great you did it :) . May I put sources on the dev server ? May I suggest keeping it in a git repository so other people than the ones with commit access to the openstreetmap svn can contribute? I have used repo.or.cz which is a free service offered by Petr Baudis, author of many improvements in the git user interface for the osm-helpers improved code. I am probably going to be one of your early adopters :-) I can put it where ever people want it. I think svn.openstreetmap.org is the best. Where to ask to get svn account ? The machine admin - TomH creates accounts for anyone who requires one. (A few) more details on the wiki - http://wiki.openstreetmap.org/wiki/SVN -- Regards, Thomas Wood (Edgemaster) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
Eddy Petrișor a écrit : 2009/4/29 Etienne Chové ch...@crans.org: [1] http://wiki.openstreetmap.org/wiki/PythonOsmApi BTW, under which license are publishing your changes? May I suggest one of 'LGPL', 'GPL v2 or later' or 'GPL v3 or later'? I would be fine with either of those, but I think LGPL would be the best choice for such code as a library. Until now, all my publcations are GPLv3, and this one yet have it licence header. I don't know differences with LGPL. -- Etienne ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Python API
On Wed, Apr 29, 2009 at 8:10 PM, Etienne Chové ch...@crans.org wrote: Eddy Petrișor a écrit : 2009/4/29 Etienne Chové ch...@crans.org: [1] http://wiki.openstreetmap.org/wiki/PythonOsmApi BTW, under which license are publishing your changes? May I suggest one of 'LGPL', 'GPL v2 or later' or 'GPL v3 or later'? I would be fine with either of those, but I think LGPL would be the best choice for such code as a library. Until now, all my publcations are GPLv3, and this one yet have it licence header. I don't know differences with LGPL. Basically LGPL allows building proprietary or non-GPLed apps linked with LGPL libraries, but in the case of Python modules I am unsure if that would really allow creating proprietary or non-GPLed apps since I am unsure if an import counts as linking. Either way I am fine with GPLv3, too. If you don't feel too strong about it, you might want to add a or later there to ease up possible future migrations to newer versions of the license. -- Regards, EddyP = Imagination is more important than knowledge A.Einstein ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GeoQR - Geocoding Video with QRCodes
Hi Simon, On Wed, Apr 29, 2009 at 5:06 PM, si...@mungewell.org wrote: The only question I have (and this is not a put down) is why? I was fairly confident someone would see the heavy processing flaw :-) Any encoding on the video image is going to reduce the quality of the barcode image and thus make it a little harder to read and apart from being cool not many people can read 2D barcodes by eye. This is true, I'm waiting for the open standard to settle before getting my brain 2D barcode enabled. The reason I chose a QR Code (or any other barcode) is that it's machine readable even in blurry and twisted orientations, making it quite robust on encoded video. Turns out I can record at a resolution lower than it can be normally read. When I enlarge the extracted png to 2x size it still works. Plus QuickMark on Symbian S60 makes a funny noise when it captures that appeals the child in me. ;-) Personally I would think encoding the NMEA string into APRS beacons (or the like) onto the audio track would be the way to go. That way it could be done without any processing power in the car - just a GPS, APRS encoder (can be a simple as a PIC or OpenTracker) and a camcorder with a line/mic input. Yes, definitely audio is the least processor-intensive way of getting a synchronised input. I was mostly faffing. I've seen FSK used, can APRS be recorded onto an audio track then? If you are going to process the video you could render the GPS data as a human readable graphic overlay (think speedometer, compass heading, lat/long, etc) onto the video... but why not include a 2D barcode too. I should be able to do that stuff, but VLC didn't seem to offer much in the way of text overlay, just image overlay. I suppose I could make text into an image with an alpha channel. Anyway, this isn't really a big deal for me, just an interesting exercise in faffing. Anyway 'way cool', Simon. Thanks :-) Ben -- b...@crouchingbadger.com | http://crouchingbadger.com ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Zonal restrictions.
Hi, I'm looking for a way to map restrictions for a zone. This includes things like maxspeed, maxweight and parking restriction. I want to avoid having to place those tags on all the roads inside the zone, specially for large zones, since it's very easy to forget one. What currently comes closest to what I want is an area with a place= tag, but the meaning of that is not clearly defined, and you can't do everything with that. So I want to have a way to mark all roads inside the zone to have the restriction for that zone. It should probably also have a way to indicate that you're inside the built-up area. If the same type of restriction (for instance maxspeed) is placed both on the zone and the highway itself, the one for the highway should be used. For a previous discussion about this, see: http://wiki.openstreetmap.org/wiki/Talk:OSM_tags_for_routing/Maxspeed#Inside_.2F_outside_built-up_area Kurt ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
What currently comes closest to what I want is an area with a place= tag, but the meaning of that is not clearly defined, and you can't do everything with that. I think what you really want is an implicit relation, where the road ways inherit maxspeed from the relation, and you define the relation to say that all ways in some area of some type should be in the relation. I'm a little worried that this will get too complicated, but heading down the path: Define a polygon (er, closed way) to denote the area for which ways get the inherited properties. I think this notion is just about tag inheritance and not tied to any administrative boundary. For example, in Mass in the US we have the notion of thickly settled (businesses on both sides, houses close together) where the speed limit is 30 mph and otherwise it is 40 mph. You could capture these with polygons to save tagging time, but there is no defined district. On the polygon put a maxspeed tag. On the polygon put a special inverse_relation tag that somehow defines how to match ways within the polygon that the maxspeed tag should apply to. Sort of a SQL select statement :-) Convince all the routing (and renderers that show speed?) implementations to parse and use this new kind of inverse relation. Plan B would be to add editor support to put maxspeed tags on all ways of type 'highway=foo' that don't have them. So there'd be a lot of tags, but maybe easy to add. We might also want to encode maxspeed to record the rules, but also have some typical_speed to record the speed at which traffic moves when it isn't congested, extracted from tracklogs. pgpnQeKRk4UUH.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Rendering of footways with bicycle=yes
Right now, ways highway=footway or highway=path,foot=designated where riding a
bicycle is allowed with bicycle={yes,designated} are rendered as normal
footways, so there is no way to see that they are open for bikes.
Is there a chance this could be shown on Mapnik, or at least on the cyclemap?
Maybe a mixed blue-red line, or even dashes for the designated vehicle type,
and dots for the one with yes?
Regards, Marc
signature.asc
Description: This is a digitally signed message part.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Zonal restrictions.
Kurt Roeckx schrieb: I'm looking for a way to map restrictions for a zone. This includes things like maxspeed, maxweight and parking restriction. I want to avoid having to place those tags on all the roads inside the zone, specially for large zones, since it's very easy to forget one. Well, - if you use tags to mark a zone, you can forget them just as easily - adding all ways to a relation isn't easier than tagging all of them - if you mark the entrances of the zone, you (or someone adding a track leaving the zone) can forget an entrance, which is much worse than forgetting a single tag because this error might affect areas far outside the zone - polygons indeed can save work, but suffer from problems e.g. with layered roads The advantages of zonal mapping for quality are, however, only minor. Forgetting a tag on a single way isn't that much of a problem. It will either have only minor effects or be easily spotted by someone. This, in my opinion, isn't enough to compensate for the potential problems: - zonal mapping can be harder for newbies to understand, depending on editor support. Making simple road attributes hard to understand is a no-go. - zonal mapping makes it more difficult to write software evaluating the information, so less people will be able or willing to create cool stuff with OSM. Those who still do will have less time for other features. - some options for zonal mappings (such as polygons) have performance disadvantages. This makes providing OSM services more expensive or causes slower software. Therefore, I suggest that you map zones _in addition_ to directly adding tags with the information to the streets. This serves your stated purpose of avoiding errors: Zone information can be automatically compared with tag information to make sure that all streets in the zone have the required information. It would even be possible to create editor plugins for the task of adding the zone's tags to the streets inside it on demand. Most of this applies primarily to small-scale zones. I don't suggest that everyone uses tags to define which country an object is in. The built-up areas are probably a border case. I'm not entirely sure whether tagging of individual highways is a good option here. It might still be, though, because it can also serve as a I have checked for explicit access restrictions (such as maxspeeds) and there are none marker. Tobias Knerr ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] osm.xml, Filter, what tags are available?
Hello, looking into osm.xml i see Rules with Filters like: Filter[tourism] = 'attraction'/Filter How can i find out what tags (right wording? I mean keywords like 'tourism') are available? What values could they have? Background is that i want to write an own Rule (with Filter) for country names, i want to highlight a country and render a map, so i want to make other countries a bit darker so i can still see them but see the borders of the highlighted country clearly. So i guess the tags i want to filter are in world_borders. Under what tag are country names stored? Does that make sense? Is it clear what i want to do? It would be great if anybody got a hint on this. Best regards, Torsten. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm.xml, Filter, what tags are available?
Hi, i just found out using a hex editor that the rule i need is: Filter[CNTRY_NAME] = 'Germany'/Filter It would be great to know if there is another way than using a hex editor, has anybody got a hint? Best regards, Torsten. Am Mittwoch, 29. April 2009 21:22:34 schrieb Torsten Mohr: Hello, looking into osm.xml i see Rules with Filters like: Filter[tourism] = 'attraction'/Filter How can i find out what tags (right wording? I mean keywords like 'tourism') are available? What values could they have? Background is that i want to write an own Rule (with Filter) for country names, i want to highlight a country and render a map, so i want to make other countries a bit darker so i can still see them but see the borders of the highlighted country clearly. So i guess the tags i want to filter are in world_borders. Under what tag are country names stored? Does that make sense? Is it clear what i want to do? It would be great if anybody got a hint on this. Best regards, Torsten. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of footways with bicycle=yes
Why not tag it as a cycleway? Then it will display as a cycleway. How is it
different from anything else that might be tagged as a cycleway?
Richard
On Wed, Apr 29, 2009 at 7:35 PM, Marc Schütz schue...@gmx.net wrote:
Right now, ways highway=footway or highway=path,foot=designated where
riding a bicycle is allowed with bicycle={yes,designated} are rendered as
normal footways, so there is no way to see that they are open for bikes.
Is there a chance this could be shown on Mapnik, or at least on the
cyclemap? Maybe a mixed blue-red line, or even dashes for the designated
vehicle type, and dots for the one with yes?
Regards, Marc
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] osm.xml, Filter, what tags are available?
El Miércoles, 29 de Abril de 2009, Torsten Mohr escribió: looking into osm.xml i see Rules with Filters like: Filter[tourism] = 'attraction'/Filter I suppose you're talking about the mapnik stylesheets. How can i find out what tags (right wording? I mean keywords like 'tourism') are available? What values could they have? Anything that is in the data backend specified in the mapnik XML config file. That would be columns in the PostGIS DB (for OSM data), or data in the shapefiles (for the world boundaries). You can either run osm2pgsql with different parameters, or replace the world boundaries shapefiles with your own, or some other solution. Cheers, -- -- Iván Sánchez Ortega i...@sanchezortega.es If everything seems under control, you're just not going fast enough. - Mario Andretti signature.asc Description: This is a digitally signed message part. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GeoQR - Geocoding Video with QRCodes
Yes, definitely audio is the least processor-intensive way of getting a synchronised input. I was mostly faffing. I've seen FSK used, can APRS be recorded onto an audio track then? APRS is a packet radio technique for HAMs which uses a standardised data frame which is AFSK encoded to transmit on the 2m band, perfect for audio recording. http://en.wikipedia.org/wiki/Automatic_Packet_Reporting_System I would suggest this, as there are many ways to encode and decode it. One hardware encoder is the OpenTracker project: http://www.argentdata.com/products/otplus.html Cheers, Simon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
There are large parts of tropical coastlines where the coast is marked as the outside edge of mangrove swamps. These are covered with water most of the time, and adjacent to the sea, so are below the high tide line, but are considered to be part of the land. You can't take a boat through them, and they're covered with trees. These have been discussed on the mailing lists several times. The general consensus seems to be that if it's covered in plants, it's inside the coastline, even if there happens to be water cover as well. In some places, we're talking about differences of 15-20km or so in where the coastline goes, so it's easy to see what paper maps have done, and every one I've checked includes coastal swamps (fens?) and mangrove flats on the land side of the coast. 2009/4/30 Cartinus carti...@xs4all.nl: I can't find anything about moving the coastline away from the high-tide line in either: http://wiki.openstreetmap.org/wiki/Talk:Tag:natural=wetland or http://wiki.openstreetmap.org/wiki/Talk:Tag:natural=coastline The second page e.g. talks about a sandbank at the coast of the isle of Wight. Which, according to that discussion, should be on the sea-side of the coastline. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] GeoQR - Geocoding Video with QRCodes
On Apr 29, 2009, at 3:43 AM, Ben Ward wrote: This video demonstrates the end-product:- a video with each frame geocoded using QR Codes (those 2D barcode things) and thus individually indexed: This is really keen, but the movie studios manage to keep their audio and video tracks synchronized using a clapper. The timing is constant; it's just a question of having the audio and video synched. Well, same thing for a GPX file and a video file. Match the number of seconds into the video against the number of seconds into the GPX tracks, and you're all set. -- Russ Nelson - http://community.cloudmade.com/blog - http://wiki.openstreetmap.org/wiki/User:RussNelson r...@cloudmade.com - Twitter: Russ_OSM - http://openstreetmap.org/user/RussNelson ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] coastline accuracy?
Hi All Thanks for the replies, I re-examined my tracks, existing roads and the Yahoo layer - if only we had an extra zoom level or two it would be more obvious ... The island in question is Menorca. The road that I travelled every day, due to a one way traffic system, is along the edge of an east-facing limestone cliff with a sharp vertical drop to sea level. So high water and low water are the practically the same from a satellite view. The road-to-cliff edge distance is mostly about 1-2 times the GPS stated accuracy. The GPS tracks were consistently plotted further west than expected relative to the PGS data coastline, which at that point matches the Yahoo layer pretty well. Repeat journeys matched very well. Looking at other thin promontories, this was consistent along the coastline. Some inland roads also appear displaced. I then loaded the same GPS tracks into another well known satellite viewer which allows higher zoom levels. They all seemed to have a more accurate relation to the coast. I checked this at various locations around the island and a consistent shift is seen. So local coastal adjustments won't be sufficient. My naive conclusion is that both the whole PGS and Yahoo layers need to be shifted, together, in the south west direction to get everything lined up with the road data. Is this possible and acceptable? If so, any hints as to how to do this would be welcome. regards, Martyn ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Export to PDF from command line
Hi, is it possable to get a pdf extract using the DOS command line? Perhaps a toggle switch with xapi? Thanks, Sam ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] dorpscentrum verzopen
Geen relatie gebruiken De huidige server kan daar nog niks mee. Heb ik ook al eens gemerkt en gemeld, maar daar is nog niets mee gedaan. Gewoon 2 of meer gesloten polygonen gebruiken, Waarbij de binnenste de omgekeerde draairichting heeft. Je kan ook 2 polygonen in de vorm van een C gespiegeld tegen elkaar leggen en de 8 hoekpunten mergen om een eiland te maken. De huidige server kan daar nog niks mee. Heb ik ook al eens gemerkt en gemeld, maar daar is nog niets mee gedaan. Gert gremmen -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens YRS Verzonden: woensdag 29 april 2009 16:53 Aan: talk-nl@openstreetmap.org Onderwerp: [OSM-talk-nl] dorpscentrum verzopen Weet iemand waarom Mapnik ons dorpcentrum ineens laat onderlopen? Het is door een soort eiland doordat de omsluitenden vaarten op elkaar uit komen. Ik heb daarvoor een Relation gebruikt volgens het boekje. Het werd in eerste instantie ook goed gerenderd maar ineens is er alleen maar water. Is er iets veranderd en moet ik iets aanpassen? http://www.openstreetmap.org/?lat=51.98916lon=4.50128zoom=17layers=B0 00FTF Vast dank voor de reactie ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] dorpscentrum verzopen
ce-test, qualified testing bv - Gert Gremmen wrote: Geen relatie gebruiken De huidige server kan daar nog niks mee. Heb ik ook al eens gemerkt en gemeld, maar daar is nog niets mee gedaan. Hoe kom je daar nu weer op? http://tile.openstreetmap.nl/?zoom=17lat=51.98898lon=4.50042layers=B00F Gewoon 2 of meer gesloten polygonen gebruiken, Waarbij de binnenste de omgekeerde draairichting heeft. Je kan ook 2 polygonen in de vorm van een C gespiegeld tegen elkaar leggen en de 8 hoekpunten mergen om een eiland te maken. En vervolgens komt iemand zoals ik langs, die er weer een multipolygonrelatie van maakt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] dorpscentrum verzopen
En als je er dan iets aan wijzigt (met Potlatch) dan staat de boel weer onderwater Ik heb de meerwaarde nog niet ontdekt. Regelmatig kom ik mismaakte relaties tegen, Of relaties die geen relatie hebben met de werkelijkheid, Maar er zijn omdat het kan . Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Lennard Verzonden: woensdag 29 april 2009 17:58 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] dorpscentrum verzopen ce-test, qualified testing bv - Gert Gremmen wrote: Geen relatie gebruiken De huidige server kan daar nog niks mee. Heb ik ook al eens gemerkt en gemeld, maar daar is nog niets mee gedaan. Hoe kom je daar nu weer op? http://tile.openstreetmap.nl/?zoom=17lat=51.98898lon=4.50042layers=B0 0F Gewoon 2 of meer gesloten polygonen gebruiken, Waarbij de binnenste de omgekeerde draairichting heeft. Je kan ook 2 polygonen in de vorm van een C gespiegeld tegen elkaar leggen en de 8 hoekpunten mergen om een eiland te maken. En vervolgens komt iemand zoals ik langs, die er weer een multipolygonrelatie van maakt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] dorpscentrum verzopen
Ik heb een enigszins verwant probleem. 2 gebouwen delen dezelfde muur, maar ik wil ze apart een naam kunnen geven. het gaan om een oranjerie en een galerij van het kasteel alden-biesen bij Bilzen. - maak ik 2 gesloten lussen voor elk gebouw, waarbij ik de nodes hergebruik? (hoe doe je dat netjes in JOSM/potlatch?) - teken ik alle muren en maak er dan gebouwen van met relaties, zodat er geen 2 segmenten op elkaar liggen? alvast bedankt, Sebastiaan 2009/4/29 ce-test, qualified testing bv - Gert Gremmen g.grem...@cetest.nl: En als je er dan iets aan wijzigt (met Potlatch) dan staat de boel weer onderwater Ik heb de meerwaarde nog niet ontdekt. Regelmatig kom ik mismaakte relaties tegen, Of relaties die geen relatie hebben met de werkelijkheid, Maar er zijn omdat het kan . Gert -Oorspronkelijk bericht- Van: talk-nl-boun...@openstreetmap.org [mailto:talk-nl-boun...@openstreetmap.org] Namens Lennard Verzonden: woensdag 29 april 2009 17:58 Aan: OpenStreetMap NL discussion list Onderwerp: Re: [OSM-talk-nl] dorpscentrum verzopen ce-test, qualified testing bv - Gert Gremmen wrote: Geen relatie gebruiken De huidige server kan daar nog niks mee. Heb ik ook al eens gemerkt en gemeld, maar daar is nog niets mee gedaan. Hoe kom je daar nu weer op? http://tile.openstreetmap.nl/?zoom=17lat=51.98898lon=4.50042layers=B0 0F Gewoon 2 of meer gesloten polygonen gebruiken, Waarbij de binnenste de omgekeerde draairichting heeft. Je kan ook 2 polygonen in de vorm van een C gespiegeld tegen elkaar leggen en de 8 hoekpunten mergen om een eiland te maken. En vervolgens komt iemand zoals ik langs, die er weer een multipolygonrelatie van maakt. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] dorpscentrum verzopen
ce-test, qualified testing bv - Gert Gremmen wrote: En als je er dan iets aan wijzigt (met Potlatch) dan staat de boel weer onderwater Ik zie niet in wat de editor ermee te maken heeft. De boel staat ook niet onder water in de database, slechts op dit moment in de rendering. De data boet niets aan waarde in. Ik heb de meerwaarde nog niet ontdekt. Regelmatig kom ik mismaakte relaties tegen, Ik denk dat dat vaak zal komen door onbekendheid met de juiste tagging. Of relaties die geen relatie hebben met de werkelijkheid, Maar er zijn omdat het kan . Als er geen relatie met de werkelijkheid is, dan maakt het ook niet uit of het een relatie is of een polygon of een way. Het hoort dan niet in de OSM db. -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Original-Nachricht Datum: Tue, 28 Apr 2009 16:19:47 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Maxspeed map Je länger ich bei OSM dabei bin, umso mehr gefallen mir solche eigentlich total uneleganten Lösungen, denn irgendwie geht das einfach ratz-fatz, keiner muss irgendwelche hässlichen Implikationen beachten und man hat sofort ein Ergebnis. Und das Ergebnis kommt und geht mit jeder neuen Interpretation. Mal ein ganz simpler Vorschlag: Erfasst Schilder! Erfasst sie direkt und präzise und jeder kann sie zu jeder Zeit als dass interpretieren was sie sind. Erfasst ein Tempolimit mit Anfangsschild und Aufhebung und mit einer Relation, die Anfang und Ende verbindet, ist alles beschrieben, incl. der Richtung. Erfasst Ortsschilder als solche. Wenn alle Ortschilder eines Stadt/Dorfgebietes erfasst sind, ist exakt beschrieben, welche Strassen drin und welche draussen sind. Ein Algo, der in ein solches lokales Netz hineinscannt, ist nicht die Welt. Zusammen mit einem angenäherten Polygon, lassen sich Ausbrecher (Strassen ohne Schild) leicht abfangen. Ein Schild ist objektiv erkenn- und verifizierbar. Die Geschichte einen Schildes (hier wurde am x.x.200x das Ortschild verschoben, hier ein Temolimit geändert) ist ein interessante Information. Ist mit dem Schild die Quelle der Beschränkung erfasst, kann man problemlos alles mit redundanten und sich widersprechenden maxspeed-Attributen fluten. Denn dann hat man ein Normal, mit dem man rausfinden kann, warum die alle eingetragen wurden. Wenn man das dann überhaupt noch herausfinden will ;) Grüsse Hubert -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Hallo. Am Dienstag 28 April 2009 16:19:47 schrieb Bernd Wurst: Je länger ich bei OSM dabei bin, umso mehr gefallen mir solche eigentlich total uneleganten Lösungen, denn irgendwie geht das einfach ratz-fatz, keiner muss irgendwelche hässlichen Implikationen beachten und man hat sofort ein Ergebnis. Die Diskussion läuft in die gleiche Richtung wie beim letzten Mal und dabei denke ich bei fast jedem Posting, dass sich hier einige leicht merkbefreit verhalten. Schließlich wird schon wieder mit wilden Implikationen gefuchtelt, obwohl das keiner bisher auswertet oder vor hat, es auszuwerten. Mein pragmatischer Weg (keine Diskussionsgrundlage sondern eine Aussage) für das Tagging von impliziten Geschwindigkeitsbeschränkungen ist: maxspeed=50 maxspeed:authority=city oder maxspeed=100 maxspeed:authority=unlimited Wenn dann (um bei der unwahrscheinlichen Analogie zu bleiben) Angie oder die Autofahrerpartei in zwei Jahren das Limit innerorts auf 65 km/h erhöhen, dann kann man per Script alles was bisher wie oben getagged war auf das neue Limit umstellen. Per explizitem Schild gesetzte 50 bleiben dann erhalten. Daten-Nutzer müssten dagegen genau gar nichts beachten sondern werten nur maxspeed aus. So (genaugenommen ohne das zweitere Tag, denn ich halte es für sehr unwahrscheinlich, dass das Limit zu meinen Lebzeiten geändert wird) mache ich das jedenfalls. Gruß, Bernd -- Fachbegriffe der Informatik (#416): Hubraum Raum für den Etagenverteiler (Marc Haber) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Hallo. Am Mittwoch 29 April 2009 08:40:57 schrieb qbert biker: Und das Ergebnis kommt und geht mit jeder neuen Interpretation. Nein, bei einem maxspeed=50 bleibt eben nicht viel Raum für wilde Interpretationen. Gruß, Bernd -- Eine geschiedene, kinderlose Ostdeutsche und ein schwuler Liberaler an der Spitze von Union und FDP - das wäre ohne Rot-Grün nicht möglich gewesen. - Daniel Cohn-Bendit (DER SPIEGEL, 19. August 2005) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Garry schrieb: Dann mach Dir mal Gedanken für was man maxspeed in erster Linie einsetzt: Warnung vor Geschwindigkeitsübertretung. Und: Berechnung der Zeit, die man über diese Strecke von A nach B braucht. (Schnellste Route). Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Garry schrieb: marcus.wolsc...@googlemail.com schrieb: On Tue, 28 Apr 2009 11:11:34 +0200, Philipp li...@dodekatex.de wrote: Wir mappen die Realität. Und in der Realität ist da keine Einbahnstraße. Da ist da eine Fahrbahn ohne bauliche Trennung. Dem stimme ich zu. Wenn da ein Stück weit nur eine Strasse ist, dann eben auch nur ein way mit highway=motorway_link und oneway=false . Ich warte immer noch auf eine einleuchtende Erklärung was diesen Mehraufwand bei Verlust an Funktionssicherheit für Mapper und Anwendungen zum jetztigen Zeitpunkt (wo noch keine durchgezogenen Linien/Wendeverbote vorhanden sind) rechtfertigt. Sorry, aber ich behaupte, für diesen Spezialfall *motorway_link* ist das Wendeverbot bereits zum jetzigen Zeitpunkt vorhanden (implizit). Von daher gibt es dort keinen Verlust an Funktionssicherheit und daher ist es kein Mehraufwand, sondern schlicht nur Aufwand, diese Information zu erfassen (Mapper: keine bauliche Trennung) bzw.auszuwerten (Anwendung: Wendeverbot, da motorway_link). Wenn Du trotzdem den baulich nicht getrennten Teil als getrennte oneways erfasst - und damit in den Daten eine bauliche Trennung vorgaukelst - geht genau diese Information verloren. Fiktiv: Künftige Verkehrsanalytiker wundern sich, wieso es bei dieser Autobahnauffahrt so oft zu Geisterfahrern kommt, obwohl doch bereits eine bauliche Trennung laut der ihnen voliegenden OSM-Daten vorhanden ist - sie würden ja sonst eine zusätzliche Leitplanke empfehlen ... Auch ich möchte die Daten gerne so schnell wie möglich für ein Navi einsetzen können - aber ich möchte auch die Realität so erfassen, dass solche evtl. Sicherheitslücken erkannt werden können. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
On Wed, Apr 29, 2009 at 12:02:25AM +0200, Robert S. wrote: Naja, als Fehler/'bug' würd ich das nicht bezeichnen - wenn, dann ist es eher eine unnötige Renundanz. Fehler wäre es eher wenn da '70' statt '7' steht. Es gibt keienn numerischen Wert der richtig ist - 7 ist Rechtsprechung aber nicht StVO - Da steht Schrittgeschwindigkeit - wenn ueberhaupt muss das maxspeed=walk sein aber auch das ist obsolete weil living_street eben eine geschwindigkeit impliziert ... Ist dieses implizieren eigentlich rechtlich vorrangig? Ich habe hier nämlich einen Fall, dasteht in einer 'living_street' ein normales Tempo-30-Schild... Sollte das also erfasst werden oder nicht? Hatten wir ja schon - geht eigentlich nicht - Nach StVO vertragen sich die beiden Schilder nicht - Verkehrsberuhigt ist Schrittgeschwindigkeit. Da kann man ja nicht einfach noch nen Geschwindigkeitsschild dazu haengen. Ich habe so einen fall auch schonmal gesehen - da hatte aber jemand das 30er Schild falschrum aufgehaengt - d.h. es haette eigentlich die Zone30 am ende der verkehrsberuhigung wiedereroeffnen sollen. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Original-Nachricht Datum: Wed, 29 Apr 2009 09:03:37 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map Hallo. Am Mittwoch 29 April 2009 08:40:57 schrieb qbert biker: Und das Ergebnis kommt und geht mit jeder neuen Interpretation. Nein, bei einem maxspeed=50 bleibt eben nicht viel Raum für wilde Interpretationen. Wenn ich in die Diskussion so reinlese komme ich da auf ganz andere Ergebnisse, z.B. auch beim Thema Spielstrasse, da ist nicht mal die Zahl selber fix. Das dazugehörige Schild dagegen ist fix, warum nicht also konkret dieses als solches erfassen? Ohne das warum ist die Info maxspeed=50 nur die Hälfte wert und paradoxerweise wäre das warum einfacher und präziser zu erfassen. Oft hat ein Ort mit 50 Strassen nur eine Handvoll Ortsschilder. Spielstrassen, Tempo-30-Zonen, Ortsbereiche, sonstige Tempolimits - alle sind als Subnetze beschreibbar, von denen man nur die Begrenzungsknoten wissen muss. Dann weiss man nicht nur dass es da etwas gibt, sondern auch warum. Und nochmal: Es ist nichts dagegen einzuwenden, alle Strassen der Welt mit max_speed Eintragungen zu fluten, aber wer die Schilder dazu einträgt, leistet auch wertvolle Arbeit. Vielleicht redundant, aber nützlich. Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
On Tue, Apr 28, 2009 at 11:06:05PM +0200, Garry wrote: Es gibt Strassen die innerorts mehr als 50km/h (60km/, 70km/h) erlauben. aber Ende dieser Strecken steht dann 50km/h - fährt man von der anderen Seite in diese Strasse von ausserorts ein hat man nur das Ortschild mit den 50km/h. Ein konssequnentes maxspeed=[zahlenwert] hat kein Problem damit, ein impliziter Wert schafft hier wieder konflikte. Das 50kmh schild am ende von 50kmh Strecken innerorts steht da weil Zeichen 282 explizit nicht innerorts stehen soll: Das Zeichen 278 darf nicht verwendet werden, wenn auf der folgenden Strecke die zulässige Höchstgeschwindigkeit anderweitig beschränkt ist (z.B. innerhalb geschlossener Ortschaften, bei Geschwindigkeitstrichtern); in solchen Fällen ist statt dessen das Zeichen 274 aufzustellen. Initial ging es ja auch um maxspeed=no/none was in meinen Augen einfach nur klar macht das keine weitere beschraenkung existiert. Innerorts ist das schwierig zu nutzen. Ausserorts ist es einfach weil dann 100 gilt. D.h. ich habe das durchaus genutzt um auf Landstraßen Abschnitte ohne Geschwindigkeitsbeschraenkung zu markieren (Einfach nach dem Motto - ist erfasst - keine Beschraenkung). Fuer mich ist das eben nicht Ich kann so schnell fahren wie ich will was im Prinzip ja eh nirgends gegeben ist. Die Idee war eben dann maxspeed=none d.h. nicht numerische Sonderwerte auszudehnen auf andere Bereiche wo sich das evtl lohnt - also - maxspeed=city oder aehnliches. Aber es ist schon richtig das das alles wieder verkompliziert. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] josm, api0.6 und precondition failed und internal server error
Frederik Ramm schrieb: josm lädt alle änderungen mit einem rutsch per http POST request (atomar) hoch und nicht jede änderung einzeln per http PUT Du kannst mal probieren, im Einsteinmodus osm-server.atomic-upload=false zu setzen, dann sollte das alte Verhalten wieder eingestellt werden. Ist allerdings ziemlich ungetestet es scheint tatsächlich ziemlich ungetestet zu sein: PUT http://www.openstreetmap.org/api/0.6/changeset/create... OK PUT http://www.openstreetmap.org/api/0.6/node/create... Bad Request Error body: Cannot parse valid node from xml string node visible=true lat=49.545965080078574 lon=8.472035570361482/. changeset id missing offenbar fehlt die changeset id bei einem create. und eigentlich ist das mit dem diff-upload besser, weil es schneller geht und garantiert ist, dass das ganze nicht in irgendeinem halbfertigen Zustand abbricht... das ist mir schon klar und das hatte ich auch in meiner ursprungsmail geschrieben. aber wenn die daten gar nicht hochgeladen werden können, dann finde ich das noch plöder. grüße frank ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Georg Feddern schrieb: Auch ich möchte die Daten gerne so schnell wie möglich für ein Navi einsetzen können - aber ich möchte auch die Realität so erfassen, dass solche evtl. Sicherheitslücken erkannt werden können. Da sagst du was Wahres. Halten Sie sich rechts. sagt mein Tomtom schon heute öfters an solchen Stellen, wenn die Strecke lang genug ist. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Hallo. Am Mittwoch 29 April 2009 09:41:14 schrieb qbert biker: Wenn ich in die Diskussion so reinlese komme ich da auf ganz andere Ergebnisse, z.B. auch beim Thema Spielstrasse, da ist nicht mal die Zahl selber fix. Das dazugehörige Schild dagegen ist fix, warum nicht also konkret dieses als solches erfassen? Sicherlich nichts dagegen! Ohne das warum ist die Info maxspeed=50 nur die Hälfte wert Das würde ich für meine Miniwelt nicht behaupten, denn ich sehe in den Geschwindigkeitsbeschränkungen eigentlich nur eine Information: Da kann/soll/darf man nicht schneller fahren. Spielstrassen, Tempo-30-Zonen, Ortsbereiche, sonstige Tempolimits - alle sind als Subnetze beschreibbar, von denen man nur die Begrenzungsknoten wissen muss. Dann weiss man nicht nur dass es da etwas gibt, sondern auch warum. Und nochmal: Es ist nichts dagegen einzuwenden, alle Strassen der Welt mit max_speed Eintragungen zu fluten, aber wer die Schilder dazu einträgt, leistet auch wertvolle Arbeit. Vielleicht redundant, aber nützlich. Richtig, als Zusatzinformation ist das exzellent und stört sicherlich keinen. Aber in Anbetracht der geschätzt 100 möglichen Schreibweisen für die selbe Implikation wäre mit der einfach zu verstehende und missverständnisfreie Zahlenwert den man einfach nur auslesen muss extrem wichtig. Schilder als Information klasse, aber nicht unbedingt für daraus kann man theoretisch bestimmt irgendwann mal vielleicht die Beschränkungen ableiten sondern als Zusatzinfo. Gruß, Bernd -- Lieber häßlich als blöd oder beides signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Tobias Knerr wrote: Gerrit Lammert schrieb: maxspeed=de:city maxspeed=at:motorway maxspeed=it:trunk ... Aber bitte nicht so, dass macht logisch keinen Sinn. Besser maxspeed:de=city etc. Ohne jetzt generell die Idee bewerten zu wollen: maxspeed=de:city (oder city:de o.ä.) ist eindeutig sinnvoller, es handelt sich bei de:city um einen Wert für die Höchstgeschwindigket, nämlich deutsche Stadtgeschwindigkeit. Es handelt sich _nicht_ um eine deutsche Höchstgeschwindigkeit der Straße, in dem Sinne, dass man der selben Straße noch eine italienische Höchstgeschwindigkeit verpassen könnte -- genau das kann man mit maxspeed:de etc. aber tun. Und genau das kann man z.B. mit deutschen und italienischen Namen (name:de, name:it) tun, dort ist das aber im Gegensatz zu maxspeed gewollt. OK, nach der Logik dann aber bitte maxspeed=city:de Die Idee ist, das Dinge hinter dem ':' immer Verfeinerungen des vorherigen Merkmals sind und als Näherung auch ohne dieses funktionieren. maxspeed=city macht noch Sinn, maxspeed=de jedoch nicht. Insgesamt finde ich (wie andere auch schon gesagt haben) eine solche explizite Angabe des 'de', wenn es für alle Orte innerhalb des de-Polygons gilt, aber redundant. Gerrit ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
qbert biker schrieb: Wenn ich in die Diskussion so reinlese komme ich da auf ganz andere Ergebnisse, z.B. auch beim Thema Spielstrasse, da ist nicht mal die Zahl selber fix. Das dazugehörige Schild dagegen ist fix, warum nicht also konkret dieses als solches erfassen? Die Idee ist in sofern gut, als dass es wirklich stimmt: Wo kein Schild steht, gilt die Umgebung (Zone 30, Stadt, Außerorts, Autobahn. Das kann das Navi erkennen. Falls nicht, wenigstens der Exportfilter. Ich finde, hier wird sich echt zu viele Gedanken um die Navis gemacht.Dabei werden die Dinger immer intelligenter. Und, wie schon geschrieben, vieles kann auch schon der Exportfilter prüfen. Einen Nachteil hat die Idee: Man sieht nicht, falls ein Schild vergessen wurde. Ein maxspeed=context sollte also dann erlaubt sein. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wanderkarte tot?
http://opentiles.com/nop/ Not Found The requested URL /nop/ was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Gruss Sven -- Kernel panic: I have no root and I want to scream (Linux Kernel Error Message) /me is gig...@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Gerrit Lammert schrieb: maxspeed=de:city (oder city:de o.ä.) ist eindeutig sinnvoller, es handelt sich bei de:city um einen Wert für die Höchstgeschwindigket, nämlich deutsche Stadtgeschwindigkeit. OK, nach der Logik dann aber bitte maxspeed=city:de Völlig ok, mir gings um die Entscheidung zwischen Wert und Schlüssel. Vielleicht sollte man noch ein maxspeed=city:DE draus machen (wegen des Einwands Sprache vs. Land). Insgesamt finde ich (wie andere auch schon gesagt haben) eine solche explizite Angabe des 'de', wenn es für alle Orte innerhalb des de-Polygons gilt, aber redundant. Na ja, wenn es kein zusätzlicher Aufwand bei der Eintragung ist (und das ist es in der Regel nicht, dank Autovervollständigung, Vorlagen, Kopieren bestehender Tags oder was der Editor noch so bietet) kann man dem Auswerter ja auch das Hantieren mit Länderpolygonen ersparen. Ganz trivial, auch aus Performancesicht, ist das schließlich nicht, wenn man erst mal für jede Straße einen Inklusionstest fahren muss. Wenn man schon auf die möglicherweise leichtere Eintragung per Polygon verzichtet, sollte man das auch konsequent auf allen Hierarchieebenen tun, sonst hat man zumindest hinsichtlich des nötigen Codes beim Auswerter wenig gewonnen. Wenn man wirklich nicht mehr als eine einfache Tagumsetzung verlangt, schätze ich, dass das wegen des geringen Aufwands sehr schnell in Anwendungen Einzug halten kann. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
On Wed, Apr 29, 2009 at 12:17:59AM +0200, Philipp wrote: Und nein, es gibt auch Strecken außerhalb der Autobahn auf denen du Vollgas geben darfst... Es wäre wirklich sinnig, auf den Strecken was zum taggen zu haben, um zu zeigen, dass sie nicht vergessen wurden. Eben - nur das war mein ansinnen und vom rumgucken auf der Karte scheint es mehr mapper als nur mich zu geben die maxspeed=none bzw als equivalent maxspeed=no verwenden. Ich finde das eigentlich ziemlich intuitiv. Die simple routing applikation die einfach via regex /^\d+$/ auf die maxspeeds matched macht das richtige und droppt die zusatztags und machts halt wie im moment fuer die berechnung der geschwindigkeit/ankunftszeit nach best guess - d.h. ausserorts Landstraße irgendwelche 60-80 und autobahn mit 100. Navis die das mitparsen haben so gut wie keinen vorteil ausser vielleicht Heinz Rennfahrer seinem Navi gesagt hat das er auf der Autobahn einen langfristigen schnitt von 200 schafft wo das navi dann vielleicht irgendwelche Autobahn Nebenstrecken bevorzugt weil er da eben seinen 12 Zylinder so richtig durchpusten kann. Wenn die Navis dann intelligenter werden, wir alle polygone haben koennen die navis automatisch auch die richtige geschwindigkeit (Landstraße 100, Autobahn ∞ bzw Richtgeschwindigkeit) anzeigen. Flo -- Florian Lohoff f...@rfc822.org +49-171-2280134 Those who would give up a little freedom to get a little security shall soon have neither - Benjamin Franklin signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Original-Nachricht Datum: Wed, 29 Apr 2009 09:51:03 +0200 Von: Bernd Wurst be...@bwurst.org An: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Betreff: Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map Das würde ich für meine Miniwelt nicht behaupten, denn ich sehe in den Geschwindigkeitsbeschränkungen eigentlich nur eine Information: Da kann/soll/darf man nicht schneller fahren. Vielleicht ist manchmal die Miniwelt dann doch zu klein? Das Schild ansich kann Aufofahrerinfo sein, Markierungsmarke, historische Information (wie verändert sich der Schilderwald) und einiges mehr. Maxspeed ist nur eine lokale Autofahrerinfo ohne Hintergrund. Ich finde es durchaus interessant, ob jetzt die Stadt eine neue Tempo-30-Zone eingeführt hat. Das geht aus den maxspeed-Angaben, wenn überhaupt, nur indirekt hervor. Eine Relation über die Knoten der Schilder erklärt dagegen die Zone als Gesamtobjekt. Richtig, als Zusatzinformation ist das exzellent und stört sicherlich keinen. Für den einen ist es Zusatzinfo und für den anderen ist es die Hauptinfo. Aber in Anbetracht der geschätzt 100 möglichen Schreibweisen für die selbe Implikation wäre mit der einfach zu verstehende und missverständnisfreie Zahlenwert den man einfach nur auslesen muss extrem wichtig. Aber nur autobezogen. Für eine Info wie, 'das xyz ist hinter dem Zone-30 Schild' ist es untauglich. Die gehaltvollere Information (was _und_ warum) kann die weniger gehaltvolle (nur was) ersetzen, umgekehrt ist es schwierig bis unmöglich. Schilder als Information klasse, aber nicht unbedingt für daraus kann man theoretisch bestimmt irgendwann mal vielleicht die Beschränkungen ableiten Nicht irgendwann, das geht heute schon. Die Information ist ja nicht weg, nur weil sie ein Renderer oder Router derzeit nicht interpretieren kann. Und, wir mappen doch nicht für Renderer oder Router ;) Grüsse Hubert -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Wanderkarte tot?
Hi! Sieht so aus - kann mich auch nicht mehr auf dem Server einloggen. Hab Ian benachrichtigt. bye Nop Sven Geggus schrieb: http://opentiles.com/nop/ Not Found The requested URL /nop/ was not found on this server. Additionally, a 404 Not Found error was encountered while trying to use an ErrorDocument to handle the request. Gruss Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
Original-Nachricht Datum: Wed, 29 Apr 2009 09:54:08 +0200 Von: Philipp li...@dodekatex.de An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map Einen Nachteil hat die Idee: Man sieht nicht, falls ein Schild vergessen wurde. Gut, da gibt es schon Möglichkeiten, die Plausibilität zu testen. Wenn die Spielstrasse in Hintertupfing plötzlich 198473278 Strassen umfasst und bis nach China geht, ist etwas schiefgelaufen ;) Prinzipiell kann man Zonen mit ähnlichen Methoden prüfen, wie sie derzeit bei normalen Maxspeed-Angaben gemacht werden. Man rendert mit dem Algorithmus drüber und sieht schnell, wo etwas geflickt werden muss. Ansonsten stimme ich nochmal zu. Maxspeed soll nicht verdrängt oder gar verboten werden. Wenn beide Infos parallel verfügbar ist, ist das zwar etwas redundant, schadet aber nicht. Grüsse Hubert -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Schilder und Redundanz, war Re: Maxspeed map
qbert biker schrieb: Von: Philipp li...@dodekatex.de Einen Nachteil hat die Idee: Man sieht nicht, falls ein Schild vergessen wurde. Gut, da gibt es schon Möglichkeiten, die Plausibilität zu testen. Wenn die Spielstrasse in Hintertupfing plötzlich 198473278 Strassen umfasst und bis nach China geht, ist etwas schiefgelaufen ;) Das meinte ich nicht. Ich meinte: Man sieht nicht, wo man eventuell vergessen hat, etwas zu taggen, wenn es normal ist, dass kein maxspeed angegeben wurde. Also man sollte etwas angeben können, auch wenn gerade keine Schilder etwas regeln. Grüße Philipp ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Tobias Knerr schrieb: Völlig ok, mir gings um die Entscheidung zwischen Wert und Schlüssel. Vielleicht sollte man noch ein maxspeed=city:DE draus machen (wegen des Einwands Sprache vs. Land). Ok das schein vernünftig zu sein! Eigentlich bin ich zwar auch eher für die von Garry bevorzugte einfachste Minimallösung das direkten taggens des Zahlenwertes, aber die länderspezifischen Defaultwerte hätten auch Ihren Vorteil: maxspeed=motorway:DE kann je nach Verkehrsmittel unterschiedlich interpretiert werden, also im PKW-Modus als no/none/unlimited/gar nichts LKW-Modus als 80 oder ein maxspeed=non_motorway:DE (oder maxspeed=primary:DE oder wie auch immer) kann so interpretiert werden: PKW-Modus als 100 klein-LKW-Modus als 80 LKW-Modus als 60 Gruß, Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Fehlerhafter Upload oder nicht?
Sebastian Masch schrieb: Moin Ich habe gestern ein paar Gebäude in Rostock hochgeladen: http://www.openstreetmap.org/browse/changeset/1004996 Hat auch alles fehlerlos geklappt, obwohl es ein großer Upload war, und beim nochmaligen Download ist auch alles da. Auch die Renderer sind zügig angesprungen, allerdings rendern diese nur jedes zweite Haus. Man siehts gut sichtbar an der halb leergefegten Gartenstadt und der eigentlich zweiteiligen DKB-Arena. Es fehlen keine Tiles nur Häuser ... Fehlt mir nur die Geduld oder ist der Upload doch schief gelaufen? http://www.openstreetmap.org/?lat=54.08496lon=12.08093zoom=17layers=0B00FTF Sieht doch OK aus? Evtl. ist beim diff-processing bei mapnik nicht alles mit 'rübergekommen. Sollte sich nächste Woche spätestens rauswachsen. -- Dirk-Lüder Deelkar Kreie Bremen - 53.0952°N 8.8652°E signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Unterwegs zwischen Köln und Bonn: Ein Interview mit Mapper Cyclop
SB79 schrieb: beim OSMBonnblog gibt es ein Interview mit Mapper Cyclop, der zwischen Köln und Bonn für OSM besonders aktiv ist. Interessierte finden das Interview hier: http://tinyurl.com/c3ud3u Danke, interessant. Gewundert hat mich dass er noch mit Potlatch arbeitet. ;-) Ich arbeite fast ausschließlich mit Potlatch, weil es der einzige Editor ist, den ich bisher ausprobiert habe, bei dem ich Objekte editieren kann, die auf ein größeres Gebiet verteilt sind. Z.B. bei JOSM ist man immer auf kleinen Gebiet beschränkt. Natürlich ist Potlatch recht langsam, aber immer noch schneller, als wenn ich ständig neue Gebiete einladen müsste. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Aufkleber?
Am 28. April 2009 21:17 schrieb Tobias Wendorff tobias.wendo...@uni-dortmund.de: Ich persönlich finde Form-Aufkleber schöner, also wenn die passend zum Logo ausgestanzt sind - aber die sind teurer, weil sie extra in einen Schneidplotter eingelegt werden müssen :-( Das OSM-Logo in einem runden Aufkleber finde ich nicht sooo toll. +2, habe ich auch schon vorgeschlagen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] MapOf
Jonas Krückel (John07) schrieb: t...@h hat einen neuen Server bekommen, spaetz ist noch nicht ganz fertig mit der Migration von allen Dingen (MapOf wurde nicht explizit erwähnt, aber ich gehe davon aus, dass das zusammenhängt) Gruß Jonas Lt. Platform-Status ist der Umzug fertig, bei MapOf kommt aber immer noch der 500-Fehler :-( Habe mir zwar inzwischen selbst eine php-Lösung gebastelt, aber die scheint ein wenig langsam zu sein... -- Gruß Mario signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Stefan Dettenhofer (StefanDausR) schrieb: Tobias Knerr schrieb: Völlig ok, mir gings um die Entscheidung zwischen Wert und Schlüssel. Vielleicht sollte man noch ein maxspeed=city:DE draus machen (wegen des Einwands Sprache vs. Land). Ok das schein vernünftig zu sein! Eigentlich bin ich zwar auch eher für die von Garry bevorzugte einfachste Minimallösung das direkten taggens des Zahlenwertes, aber die länderspezifischen Defaultwerte hätten auch Ihren Vorteil: maxspeed=motorway:DE kann je nach Verkehrsmittel unterschiedlich interpretiert werden, also im PKW-Modus als no/none/unlimited/gar nichts LKW-Modus als 80 oder ein maxspeed=non_motorway:DE (oder maxspeed=primary:DE oder wie auch immer) kann so interpretiert werden: PKW-Modus als 100 klein-LKW-Modus als 80 LKW-Modus als 60 Gruß, Stefan wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] PLZ-Suche
Funktioniert die PLZ-Suche? Ich suchte nach Bühl, aber da gabs zu viele Einträge. Also ergänzte ich die PLZ, aber da kamen genauso viele Einträge. PLZ alleine gab überhaupt keinen Treffer. Gruss, Markus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Suche
Markus schrieb: Funktioniert die PLZ-Suche? Wo? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] cross check mit bug report
hi, wer auch ab und zu mit den waycheck listen arbeitet - für cross check und hessen gibt es das nun mit bug reports: http://www.gary68.de/osm/qa/c1/c1_hessen.htm http://www.gary68.de/osm/qa/c3/c3_hessen.htm http://www.gary68.de/osm/qa/c5/c5_hessen.htm bei weiteren wünschen, für andere bundesländer, bitte melden. will das halt nur nicht generell machen. ciao gerhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 schrieb Philipp: Guenther Meyer schrieb: ja und? keine geschwindigkeitsbegrenzung heisst in deutschland nunmal 100. Nein. doch, auf normalen strassen ist das so. Und nein, es gibt auch Strecken außerhalb der Autobahn auf denen du Vollgas geben darfst... richtig, autobahnaehnlich ausgebaute strassen. Es wäre wirklich sinnig, auf den Strecken was zum taggen zu haben, um zu zeigen, dass sie nicht vergessen wurden. richtig, deswegen schlage ich vor auch alles zu taggen: und zwar entweder mit defaults fuer die drei hauptkategorien wie auf jedem grenzuebergang angegeben, das wurde ja nicht nur von mir so vorgeschlagen, oder direkt mit einer numerischen angabe. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 schrieb Garry: Zumal eine Tempo-30-Zone ja auch noch andere Dinge bedeutet: - wenn nicht anders angegeben: rechts-vor-links Gilt das nicht immer auf innerörtlichen Strassen? das gilt immer, wenn keine vorfahrtstrasse oder andere entsprechende beschilderung da steht. - sie wird nicht durch Ortsschilder aufgehoben das waere mir jetzt aber neu... - die Gefahr von spielenden Kindern ist erhöht Sehe ich auch nicht direkt durch die Temp30Zone gegeben sondern mehr dadurch dass man sich ausserhalb der Durchgangsstrassen bewegt. richtig, damit muss man in wohngebieten generell rechnen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Am Mittwoch 29 April 2009 schrieb Garry: naja, es ist einfacher, das gleich einzutragen, wenn man eh schon dabei ist. das ganze spaeter nachzutragen, und evtl nochmal rauszufahren um sich die gegebenheiten anzuschauen, ist wesentlich komplexer. Wenn es schon etablierte Tags für alles gäbe würde ich Dir ja vielleicht zustimmen, aber so steht zu befürchten dass man sowieso nochmal hin muss weil dass was Du jetzt schon tagst dann wenn es relevant wird ganz anderst getaggt wird. Kein Problem wenn Du es sowieso machen würdest, aber ich finde es schade für die die sich genötigt sehen alles richtig machen zu wollen und dann beliebig viel Zeit in solchen Details verlieren die sie sonst in die Vervollständigung des Strassennetzes investieren würden. dann sollte man schleunigst dafuer sorgen, dass man tags dafuer etabliert. aber selbst wenn nicht - die informationen sind auf jeden fall interessant, es kann ja nicht schaden, diese ueberhaupt einzutragen. denn wenn die information schon mal in der datenbank vorhanden ist, dann kann man diese im falle der einfuehrung oder konsensbildung eines etwaigen schemas immer noch umwandeln. wer so detailiert mappen will, sollte die moeglichkeiten, was alles interessant sein koennte, angeboten bekommen. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE +1 signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Guenther Meyer schrieb: Am Mittwoch 29 April 2009 schrieb Garry: Zumal eine Tempo-30-Zone ja auch noch andere Dinge bedeutet: - wenn nicht anders angegeben: rechts-vor-links Gilt das nicht immer auf innerörtlichen Strassen? das gilt immer, wenn keine vorfahrtstrasse oder andere entsprechende beschilderung da steht. da macht es doch eher Sinn Vorfahrtsstraßen zu erfassen. -- Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 schrieb Florian Lohoff: On Wed, Apr 29, 2009 at 12:17:59AM +0200, Philipp wrote: Und nein, es gibt auch Strecken außerhalb der Autobahn auf denen du Vollgas geben darfst... Es wäre wirklich sinnig, auf den Strecken was zum taggen zu haben, um zu zeigen, dass sie nicht vergessen wurden. Eben - nur das war mein ansinnen und vom rumgucken auf der Karte scheint es mehr mapper als nur mich zu geben die maxspeed=none bzw als equivalent maxspeed=no verwenden. Ich finde das eigentlich ziemlich intuitiv. ich weiss nicht. wenn ich sowas lese, wuerde ich erstmal annehmen, dass es dort keine geschwindigkeitsbeschraenkung gibt, ich also so schnell fahren darf, wie ich will... das ist die einfachste und direkteste interpretation von maxspeed=none. wenn das tag was anderes bedeuten soll, dann ist es schlicht und einfach ungluecklich gewaehlt. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Hallo. Am Mittwoch 29 April 2009 13:44:00 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE Könnt ihr diese Prosa-Werte bitte in einen unbenutzten Key bzw. einen Subkey auslagern, so dass die Pragmatiker maxspeed auf den an Ort und Stelle gültigen Wert setzen können? Danke. Gruß, Bernd -- Eine Unterschrift enthüllt immer den Charakter eines Menschen. Und manchmal sogar seinen Namen... signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Autobahnauffahrt
Am 28. April 2009 21:54 schrieb Garry garr...@gmx.de: Ich warte immer noch auf eine einleuchtende Erklärung was diesen Mehraufwand bei Verlust an Funktionssicherheit für Mapper und Anwendungen zum jetztigen Zeitpunkt (wo noch keine durchgezogenen Linien/Wendeverbote vorhanden sind) rechtfertigt. Ich warte immer noch auf eine Erklärung von dir, worin dieser riesige Mehraufwand bestehen soll, von dem du hier die ganze Zeit groß erzählst. Was bitte spricht dagegen,*eine* Fahrbahn [1] auch als *einen* way zu mappen, wie es bei Openstreetmap schon seit Ewigkeiten üblich ist? Wenn dir das Wendeverbot so wichtig ist, etabliere doch bitte einen tag dafür, aber schmeiß nicht Fahrbahnen und Fahrspuren (-Wikipedia...) durcheinander. Deine Funktionssicherheit ist in diesem Falle in etwa dasselbe, wie einen Poller auf einer Straße als ein kurzes Stück Fußweg zu mappen, weil openrouteservice und mkgmap noch keine Punkt-Hindernisse beachten. [1] http://de.wikipedia.org/wiki/Fahrbahn#Fahrbahn ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb: Hallo. Am Mittwoch 29 April 2009 13:44:00 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE Könnt ihr diese Prosa-Werte bitte in einen unbenutzten Key bzw. einen Subkey auslagern, so dass die Pragmatiker maxspeed auf den an Ort und Stelle gültigen Wert setzen können? Danke. Gruß, Bernd setz in deiner Applikation einfach motorway:DE = 130, city:DE = 50 und default:DE = 100 dann funzt auch dein Tempomat. Gruß Mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Am Mittwoch 29 April 2009 schrieb Bernd Wurst: Hallo. Am Mittwoch 29 April 2009 13:44:00 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE Könnt ihr diese Prosa-Werte bitte in einen unbenutzten Key bzw. einen Subkey auslagern, so dass die Pragmatiker maxspeed auf den an Ort und Stelle gültigen Wert setzen können? Danke. bloss nicht! sonst laesst sich das nicht mehr unterscheiden: ein maxspeed=default:DE bedeutet, man darf 100 fahren, weil es da dort keine explizite beschilderung gibt. dagegen bedeutet ein maxspeed=100, dass dort wirklich ein 100-schild steht. von der wirkung das gleiche, aber trotzdem nicht dasselbe. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb: Hallo. Am Mittwoch 29 April 2009 13:44:00 schrieb Mario Salvini: wir hätten also schonmal als neuen Vorschlag: maxspeed=motorway:DE maxspeed=city:DE müsste man also nur noch überlegen, wie man das Kind tauft, wenns außerorts aber nicht eine Autobahn ist. mein Vorschlag wäre: maxspeed=default:DE Könnt ihr diese Prosa-Werte bitte in einen unbenutzten Key bzw. einen Subkey auslagern, so dass die Pragmatiker maxspeed auf den an Ort und Stelle gültigen Wert setzen können? Danke. Meinst Du so: maxspeed=50 und maxspeed:default=city:DE bzw. maxspeed=100 und maxspeed:hgv=60 und maxspeed:default=default:DE aber pflegt das jemand wirklich so? Stefan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Secondary in Tunnel unter Autobahn - Mapnik
sieht aus wie ein bug. Kleine Randbemerkung: (kenne nicht die Situation vor Ort und gehe daher davon aus, dass es sich um einen Tunnel und nicht um eine Brücke handelt, also so wie gemappt): ich würde eher den Tunnel mit Layer=-1 kennzeichnen als die Straße mit Layer=1, da vermutlich der Tunnel nach unten geht, oder? Ansonsten wäre es m.E. eher eine Brücke. Semantisch spielt es allerdings keine Rolle. Situation ist folgende: Autobahn, in dem Bereich mit vier(!) Fahrspuren pro Fahrtrichtung, plus hier die Auffahrt, auf einem Damm von ca. 15m Höhe. Die Straße ist für die Durchtunnelung von ca. 60m nicht abgesenkt, Layer=0 ist also korrekt. Die Tunnel-Definition länger als breit hier mehrfach zu, schätzungsweise 3:1. http://maps.google.de/ maphp?ll=50.084072,8.618385spn=0.000536,0.001611t=hz=20 Zumindest von der Wahrnehmung fährt man dort als Anlieger durch einen Tunnel. Von der Brücke bekommt man auf der Autobahn wirklich nichts mit, selbst wenn man drauf achtet. Allein deshalb halte ich es für sinnvoll, das zu mappen, was man sieht, selbst wenn es konstruktiv vielleicht anders ist. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Hallo. Am Mittwoch 29 April 2009 15:53:42 schrieb Mario Salvini: setz in deiner Applikation einfach motorway:DE = 130, city:DE = 50 und default:DE = 100 dann funzt auch dein Tempomat. Ich programmiere keine Anwendung, ich möchte nur beim mappen gerne diese Werte nicht verwenden müssen und edit-wars verhindern. Wenn mir ein maxspeed=(walk/city/default/motorway/foobar) unterkommt, möchte ich gerne den richtigen Wert in ein spezielles Tag auslagern können und maxspeed mit dem numerischen, aktuell gültigen Wert füttern. Denn ein numerisches maxspeed kann jeder auswerten, nicht nur derjenige der 178 verschiedene Prosa-Werte (in etwa so viele wird es geben, wenn jede Lokalgruppe sich eine eigene Syntax ausdenkt) parsen und mit zig verschiedenen länderspezifischen Werten vorbelegen zu müssen. Versuche bitte mal kurz einen Moment lang den Schaum vorm Mund weg zu wischen und überleg dir, was eigentlich dagegen spricht, den Grund des Limits *zusätzlich* zum numerischen Momentanwert zu erfassen? Ich finde die Idee, das zu erfassen ja ganz gut, nur ist mir unklar, warum das nicht parallel existieren darf. Gruß, Bernd -- Ich moechte Windows kaufen. Sind Sie verrueckt? Gehoert das zu den Lizenzbedingungen? signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ-Suche
PLZ alleine gab überhaupt keinen Treffer. Falls Du die Karte bei Openstreetmap.org meinst: Dort gibt es in der Suche keine PLZ-Unterstützung. Wenn Du die Karte bei Openrouteservice.de meinst: Dort funktioniert die PLZ- Suche hervorragend. -jha- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Hallo. Am Mittwoch 29 April 2009 16:02:23 schrieb Guenther Meyer: bloss nicht! sonst laesst sich das nicht mehr unterscheiden: ein maxspeed=default:DE bedeutet, man darf 100 fahren, weil es da dort keine explizite beschilderung gibt. dagegen bedeutet ein maxspeed=100, dass dort wirklich ein 100-schild steht. Ein maxspeed=100 bedeutet erstmal nur, dass man da maximal 100 km/h fahren darf. Mit maxspeed:authority oder einem beliebigen entsprechenden Tag könnte man dann spezifizieren, *warum* das so ist: Schild, generelles Limit, ... Gruß, Bernd -- Die richtige Medizin kann eine Erkältung in sieben Tagen heilen. Ohne Medizin würde sie glatt eine Woche dauern. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Hallo. Am Mittwoch 29 April 2009 16:04:41 schrieb Stefan Dettenhofer (StefanDausR): maxspeed=50 und maxspeed:default=city:DE bzw. maxspeed=100 und maxspeed:hgv=60 und maxspeed:default=default:DE So in der Art, ja. Dann kannst du bei landesweiten Änderungen alle die in der korrekten alten Kombination stehen einfach umtaggen und die anderen bleiben wie gehabt. aber pflegt das jemand wirklich so? Nein. Aber egal was ihr hier tolles ausheckt, in der Praxis wird sich durchsetzen, dass man den aktuell gültigen numerischen Wert an die Straßen tagged, da würde ich jede Wette eingehen. Gruß, Bernd -- Fachbegriffe der Informatik (#165): SuSE Nürnberger Windows (Andreas Gradert) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
Bernd Wurst schrieb:
Hallo.
Am Mittwoch 29 April 2009 15:53:42 schrieb Mario Salvini:
setz in deiner Applikation einfach motorway:DE = 130, city:DE = 50 und
default:DE = 100 dann funzt auch dein Tempomat.
Ich programmiere keine Anwendung, ich möchte nur beim mappen gerne diese
Werte
nicht verwenden müssen und edit-wars verhindern.
Wenn mir ein maxspeed=(walk/city/default/motorway/foobar) unterkommt, möchte
ich gerne den richtigen Wert in ein spezielles Tag auslagern können und
maxspeed mit dem numerischen, aktuell gültigen Wert füttern.
Denn ein numerisches maxspeed kann jeder auswerten, nicht nur derjenige der
178 verschiedene Prosa-Werte (in etwa so viele wird es geben, wenn jede
Lokalgruppe sich eine eigene Syntax ausdenkt) parsen und mit zig
verschiedenen
länderspezifischen Werten vorbelegen zu müssen.
Versuche bitte mal kurz einen Moment lang den Schaum vorm Mund weg zu wischen
und überleg dir, was eigentlich dagegen spricht, den Grund des Limits
*zusätzlich* zum numerischen Momentanwert zu erfassen? Ich finde die Idee,
das
zu erfassen ja ganz gut, nur ist mir unklar, warum das nicht parallel
existieren darf.
Gruß, Bernd
Hi Bernd,
mein Post scheint falsch angekommen zu sein, denn eigentlich bin ich
völlig entspannt und bin weit entfernt von Schaum vorm Mund. :)
Was gegen eine konkrete Zahl spricht ist die tatsache, dass wenn keine
explizite Begrenzung durch Schilder vorhanden ist es keine die konkrete
Zahl gibt. Außerorts gilt z.B. für PKWs 100 km/h für LKWs 60 km/h. Wenn
man jetzt an diesen Stellen maxspeed=default:DE auffindet und die
Applikation dann
default:DE {
maxspeed:matorcar=100
maxspeed:hgv=60
...
}
festlegt haben wir mit einem einzigen Tag in der DB alle anderen
Spezifikationen sauber erfasst. Und falls eine Regiereung da eine
Änderung beschließt ist nur eine Stelle zu ändern und nicht 100.000 km
Way erneut zu prüfen.
Synergien und Akkuratheit sprechen einfach sehr dafür es über Prosa zu
erfassen :)
Lieben Gruß
Mario
___
Talk-de mailing list
Talk-de@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Maxspeed map
http://wiki.openstreetmap.org/wiki/DE:MaxSpeed_Karte Stefans Farbwahl finde ich persönlich deutlich intuitiver. Besonders das = 100 in rot irritiert enorm. Die schmaleren Linien gefallen mir aber besser :) just my 2 cents Florian Lohoff schrieb: Hi, nachdem ich ja mehrfach diskussionen zu einer oft geupdateten MaxSpeed map angestossen habe habe ich mich selber an die Arbeit gemacht. Hier ist das ergebniss: http://maxspeed.osm.lab.rfc822.org Ab z12 linien vector overlay auf den Straßen und ab z16 Schilder auf den Straßen mit den jeweiligen speeds. Update derzeit Stuendlich ... Legende: none - Gestrichelt duenn schwarz =7km/h - Gepunktet blau =30km/h - Gestrichelt blau =50km/h - Durchgezogen blau =70km/h - Durchgezogen gruen =100km/h - Durchgezogen rot Fehler - Gestrichelt dick rot Als fehler derzeit maxspeed auf highway=living_street oder nicht parsebare speeds a la 7km/h oder 30;50;30 Derzeit laeuft das dingen hauptsaechlich mit dem FireFox (2.0, 3.1, 3.5) und mit dem IE so leidlich 1) Im moment habe ich wenig meinung weiter an IE Problemen zu arbeiten aber patches oder hinweise nehme ich gerne. Opera soll gehen - Safari ungetestet Flo 1) Ab z16 werden schilder dargestellt die im IE leider nicht gehen - d.h. das Schild erscheint aber nicht der Speed im Schild ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
