Re: [talk-ph] post-typhoon pablo/bopha imagery from atrium/unosat
Dear everyone, We are closing this task since the Disaster Charter has ended and the WMS is now unavailable. Thanks to all who contributed. We intend to communicate the availability of this data to local agencies working with the reconstruction efforts as well as local universities who are conducting disaster related research in the affected areas. Here's a short animation of your tremendous work in the past month: https://dl.dropbox.com/u/2096185/pablo2.gif Thanks again! On Fri, Dec 28, 2012 at 7:17 PM, maning sambale emmanuel.samb...@gmail.com wrote: Dear everyone, Post-disaster imagery in selected areas in Mindanao affected by Typhoon Pablo/Bopha is now available for tracing in OSM. This imagery is currently available through JOSM and you need to agree with the Astrium/UNOSAT license to access them. Full details on how to use the imagery is available in the individual tasks below: - Montevista - http://tasks.hotosm.org/job/130 - New Bataan - http://tasks.hotosm.org/job/131 - Cateel - http://tasks.hotosm.org/job/132 - Baganga - http://tasks.hotosm.org/job/133 If there are problems with accessing the imagery, just ask here. Thanks! -- 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: [talk-ph] When will OSM reach 1 million registered members?
Yes, we've reached it! http://www.openstreetmap.org/stats/data_stats.html http://opengeodata.org/1-million-openstreetmappers An interesting take by Harry Wood on the 1M number: http://www.openstreetmap.org/stats/data_stats.html On Fri, Dec 28, 2012 at 8:47 PM, maning sambale emmanuel.samb...@gmail.com wrote: Another interesting question is that by next year, osm IDs will reach the upper bounds of 32bit unsigned integer. Some of the osm tools are not yet 64bit compliant. The devs are aware and we hope critical tools will be ready once we reach that limit which some projections will be by Feb 2013. Maning Sambale (mobile) On Dec 28, 2012 2:12 AM, Eugene Alvin Villar sea...@gmail.com wrote: According to this website http://resultmaps.neis-one.org/100 this milestone will be reached sometime next week. Of course, not all of those registered members will contribute to the map. Only about 20% have ever edited anything on the map and there are currently only about 15,000 active users every month. But 1 million is such a nice round number so there's a bit of fanfare for this. :) ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph -- 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-be] Addresses in Belgium
On Sat, Dec 22, 2012 at 03:23:15PM +0100, Sander Deryckere wrote: The first thing you notice is that there are a lot of features with housenumber information, but without street information. While other information (such as city) can be determined from closed boundaries. It's often ambiguous and hard to determine the street from other OSM features. Osmose counts alot of errors in Belgium because of that. See: http://osmose.openstreetmap.fr/errors/graph.png?country=belgium About 50% of those are because of missing addr:street or associatedStreet relation. It would in general be a good thing that we try and fix all those errors. Kurt ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk-be] Addresses in Belgium
The associatedStreet relation has the streetname in 'name', not in addr:street. I also found some relations where this was done incorrectly. It is possible to fix all of them in one go. Advise me if you want me to do so. Polyglot 2013/1/7 Joren joren.libreoff...@telenet.be Op 07-01-13 00:35, Kurt Roeckx schreef: On Sat, Dec 22, 2012 at 03:23:15PM +0100, Sander Deryckere wrote: The first thing you notice is that there are a lot of features with housenumber information, but without street information. While other information (such as city) can be determined from closed boundaries. It's often ambiguous and hard to determine the street from other OSM features. Osmose counts alot of errors in Belgium because of that. See: http://osmose.openstreetmap.**fr/errors/graph.png?country=**belgiumhttp://osmose.openstreetmap.fr/errors/graph.png?country=belgium http://tools.geofabrik.de/**osmi/?view=addresseslon=4.** 41356lat=51.10370zoom=14**baselayer=Geofabrikopacity=1.** 00overlays=no_addr_street,**street_not_foundhttp://tools.geofabrik.de/osmi/?view=addresseslon=4.41356lat=51.10370zoom=14baselayer=Geofabrikopacity=1.00overlays=no_addr_street,street_not_found Geofabrik shows that there are many 'bugs' in the city 'Reet' ... but when I examine it, some/all houses are tagged with 'associatedStreet streetname, etc'... Is this the correct tagging, or do we need to delete that tag, and tag them with 'addr:street'? About 50% of those are because of missing addr:street or associatedStreet relation. It would in general be a good thing that we try and fix all those errors. Thanks in advance, Joren __**_ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-behttp://lists.openstreetmap.org/listinfo/talk-be ___ Talk-be mailing list Talk-be@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-be
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
On 6 January 2013 01:54, Eugene Alvin Villar sea...@gmail.com wrote: I prefer landuse areas to be darker than the default light gray background color in the Standard rendering. This makes it obvious (especially on LCD screens where lightness/luminance of colors vary depending on the viewing angle) that there is a tagged area there. You could make the case that the farmuse area could be lighter than it is now and/or use a different hue than brown, but don't make it as light as the default background color. +1 In the first proposal, I find it very difficult to see the difference between the farmland and the non-tagged areas. It's a bit easier in the second proposal. It could maybe be made a bit lighter, but not by that much. What's the lightness of the current landuse=residential grey? What does it look like if you match the farmland colour to that? Robert. (full text and images at https://docs.google.com/open?id=0B6J5ZA1hu93bYm9IWXdlVHM1N1U ) Recently landuse=farmland (or simply landuse=farm) has been added to fields near me. This has led to a discussion about how the rendering 'looks' with some arguing that it doesn't look that good. I believe that this may be due to the shade of colour used – specifically the farmland 'brown' is not as luminous as the default 'grey' (actually I think it 'lightness' rather than 'luminosity' that matters to the human eye but I got very confused when searching the two). Consider the image below, showing current rendering: https://docs.google.com/open?id=0B6J5ZA1hu93bZDBTN2dZZkpDenc On the left we have farmland tagged. The 'brown' has a Lightness value of 83 percent (luminance of 85%). Compare this to the default canvas 'grey', which has 93 percent Lightness (and 93 percent luminance). Now consider the following (and please check your screen calibration at http://www.photofriday.com/calibrate.php ). I have taken the farmland 'brown' and raised it's Lightness to the same 93 percent as the default 'grey' (that is, I have left the Hue and Saturation the same): https://docs.google.com/open?id=0B6J5ZA1hu93bSzk5NDZVMm5GZkE In this final image, I have adjusted the Hue and Saturation to provide more of a 'green': https://docs.google.com/open?id=0B6J5ZA1hu93bZXhzdVJMVU44X2M What are your thoughts? Which do you prefer? Have I gone too 'light' with the change and should some value in-between be used instead? Am I barking up the wrong tree? -- Robert Whittaker ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
Thanks for the initial feedback. I also had one off list in support of the light green. Please keep them coming. I will play with a couple more shades this evening and post an update. Rob On Sunday, 6 January 2013, Eugene Alvin Villar sea...@gmail.com wrote: I prefer landuse areas to be darker than the default light gray background color in the Standard rendering. This makes it obvious (especially on LCD screens where lightness/luminance of colors vary depending on the viewing angle) that there is a tagged area there. You could make the case that the farmuse area could be lighter than it is now and/or use a different hue than brown, but don't make it as light as the default background color. On Sun, Jan 6, 2013 at 6:18 AM, Rob Nickerson rob.j.nicker...@gmail.com wrote: Hi All, (full text and images at https://docs.google.com/open?id=0B6J5ZA1hu93bYm9IWXdlVHM1N1U ) Recently landuse=farmland (or simply landuse=farm) has been added to fields near me. This has led to a discussion about how the rendering 'looks' with some arguing that it doesn't look that good. I believe that this may be due to the shade of colour used – specifically the farmland 'brown' is not as luminous as the default 'grey' (actually I think it 'lightness' rather than 'luminosity' that matters to the human eye but I got very confused when searching the two). Consider the image below, showing current rendering: https://docs.google.com/open?id=0B6J5ZA1hu93bZDBTN2dZZkpDenc On the left we have farmland tagged. The 'brown' has a Lightness value of 83 percent (luminance of 85%). Compare this to the default canvas 'grey', which has 93 percent Lightness (and 93 percent luminance). Now consider the following (and please check your screen calibration at http://www.photofriday.com/calibrate.php ). I have taken the farmland 'brown' and raised it's Lightness to the same 93 percent as the default 'grey' (that is, I have left the Hue and Saturation the same): https://docs.google.com/open?id=0B6J5ZA1hu93bSzk5NDZVMm5GZkE In this final image, I have adjusted the Hue and Saturation to provide more of a 'green': https://docs.google.com/open?id=0B6J5ZA1hu93bZXhzdVJMVU44X2M What are your thoughts? Which do you prefer? Have I gone too 'light' with the change and should some value in-between be used instead? Am I barking up the wrong tree? Regards, Rob Note: To focus discussion I want to avoid the argument that some people see farmland as the default and therefore it does not need to be tagged – it is a legitimate land-use tag and if people want to tag it then let them. ___ 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 Farmland not 'Light' enough?
When using OSM on my phone, windscreen mount, whilst driving I find the biggest contrast problem is the green of forests can mask the green of trunk roads, where the road passes through forest Would be nice is the forest green could be lighter. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
Rob Nickerson wrote This has led to a discussion about how the rendering 'looks' with some arguing that it doesn't look that good. I believe that this may be due to the shade of colour used – specifically the farmland 'brown' is not as luminous as the default 'grey'. +1 What's more: The brown of farmland and the orange of secondary roads are very close and offer no contrast. A secondary road running through farmland is pretty much obfuscated and very hard to notice. bye Nop -- View this message in context: http://gis.19327.n5.nabble.com/Rendering-of-Farmland-not-Light-enough-tp5742980p5743016.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can Google use our data?
It's clearly preposterous that both Jose Fredy's think their edits have been copied to Google. @Fredy - Is there really a locality called Granates when there is an existing 'Granales' right next to it? Dave F. On 05/01/2013 16:34, Fredy Rivera wrote: In Colombia abused google, copy your data and makes them small changes, notice the Camino viejo I did it with my own GPS. http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlemaplon=-75.18985lat=4.82902zoom=15 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Changeset Comments
Forwarding to newbies. On 03/01/2013 11:11, Frederik Ramm wrote: Hi, once in a while I encounter mappers who don't understand what changeset comments are good for and why they should use them. I was kind of tired of repeating the same things over and over so I wrote up a wiki page here: http://wiki.openstreetmap.org/wiki/Good_Changeset_Comments Before someone asks, this is not intended to be a policy of any sort; it is just meant as a page that you can recommend for reading if someone doesn't understand what changeset comments are for. You're welcome to improve this, add/remove examples, or translate into other languages. Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
On Sun, 2013-01-06 at 05:19 -0800, NopMap wrote: Rob Nickerson wrote This has led to a discussion about how the rendering 'looks' with some arguing that it doesn't look that good. I believe that this may be due to the shade of colour used – specifically the farmland 'brown' is not as luminous as the default 'grey'. +1 What's more: The brown of farmland and the orange of secondary roads are very close and offer no contrast. A secondary road running through farmland is pretty much obfuscated and very hard to notice. +1 I must admit I agree here, although so far less noticeable as very little farmland is tagged. I have never tagged farmland, after all if its not built up, woodland or outdoor leisure space/country park then its farmland. I would prefer to simply see the field boundaries mapped and unless there is some way to distinguish between arable and pasture then farmland does not really offer much that isn't obvious. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New History tab for openstreetmap.org (beta)
Great! I was hoping OWL would resurrect itself at some point. Love the 'show previous geometry' colour coding for emended tags. Things I've noticed: RSS gives this error: We're sorry, but something went wrong. Scroll bar Gets 'stuck' as I move it down some of the lettering doesn't scroll (Firefox 17.01, Shockwave Flash 11.5 r502) Appears to work OK in IE (Haven't got Chrome) When I click on an entity the pop-up balloon sometimes obscures it making it hard to see the changes in geometry. Could the balloon be positioned further away or make it movable? Requests: Could the permalink be designed to display the history side-bar? Open click-able pages into new tab as default (personal preference) Instead of having the 'next page' icon could a continuous scroll be employed (similar to how twitter gets older messages)? When hovering the mouse over an edit in the History bar the entities for that edit dim to a light shade. Wouldn't it be better if it was the other way around all others dimmed while the edit your interested in were emphasised (something similar to the way relations are highlighted in Potlatch)? Thanks for a superb tool that will save a lot of time for checking edits. Dave F. On 03/01/2013 23:01, Paweł Paprota wrote: Hi all, ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
On 01/06/2013 02:34 PM, Philip Barnes wrote: I would prefer to simply see the field boundaries mapped and unless there is some way to distinguish between arable and pasture then farmland does not really offer much that isn't obvious. That's why a lot of people use farm(land) only for arable land and grass for grasslands. -- --- m.v.g., Cartinus ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
Hi Farmyards are about the right shade. Fields eg landuse=farmland is slight too dark could do with lightening. My preference would be to still with a brown rather than a green (far too many items are already green - sports pitches are too dark IMO). On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: http://www.openstreetmap.org/browse/way/35032990 Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough?
On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. -- Lennard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] House Numbers
What about addr:interpolation? Do you count all the housenumbers in between, or only the ones on the ends? I think all should be counted. And not because I use those a lot :) Janko (1373) Mihelić ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
On 06/01/2013 15:01, Lennard wrote: On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. So a similar mess to mkgmap/garmin maps where it assumes there can be only one primary tag. Never been able to understand why this quite simple problem can't be sorted. Cheers Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] New History tab for openstreetmap.org (beta)
Hi Dave, Thanks for your feedback - it is exactly what I was hoping for. Things I've noticed: RSS gives this error: We're sorry, but something went wrong. Thanks, I'll fix that. Scroll bar Gets 'stuck' as I move it down some of the lettering doesn't scroll (Firefox 17.01, Shockwave Flash 11.5 r502) Appears to work OK in IE (Haven't got Chrome) Yes, I'm seeing it on Firefox 17 on Windows (on Linux it's OK). Not sure what's going on but this looks very similar to the following more general problem: https://github.com/openstreetmap/openstreetmap-website/issues/162 When I click on an entity the pop-up balloon sometimes obscures it making it hard to see the changes in geometry. Could the balloon be positioned further away or make it movable? Yeah, I noticed that too, not sure yet how to handle this properly. Requests: Could the permalink be designed to display the history side-bar? Good idea, I added it here: https://github.com/ppawel/openstreetmap-website/issues/4 Open click-able pages into new tab as default (personal preference) Hmm, not sure what to do here. I also prefer using new tabs but for that I always use middle click. Instead of having the 'next page' icon could a continuous scroll be employed (similar to how twitter gets older messages)? I thought about that but there's one problem - if there is continuous scroll then you will get more and more changesets by scrolling down. And that means that the user probably expects all of them to be displayed and that's problematic because browser performance/responsivity decreases very sharply as the number of geometry features grows beyond some point. This still needs to be solved even now with pages limited to 15 changesets - in some cases there is just too much stuff to show and the browsers freezes. I would love some thoughts on how to best solve this problem in a way that is not too complicated for the user. When hovering the mouse over an edit in the History bar the entities for that edit dim to a light shade. Wouldn't it be better if it was the other way around all others dimmed while the edit your interested in were emphasised (something similar to the way relations are highlighted in Potlatch)? OK, I will tweak color configuration. Thanks for a superb tool that will save a lot of time for checking edits. I'm glad to hear people like it. I hope it will do more than just save time. I think it really brings OSM data to life and shows that it is really a wiki-like mapping project where anyone can change anything. Anyway, thanks again for your feedback. For the future don't hesitate to create Github issues here if you want: https://github.com/ppawel/openstreetmap-website/issues I will add a report a problem/idea link to the beta version, maybe it will help with getting more feedback. Paweł ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
2013/1/6 Dave F. dave...@madasafish.com: On 06/01/2013 15:01, Lennard wrote: On 6-1-2013 15:51, Dave F. wrote: On a related topic; if a field has a barrier tag it changes colour rendering at zoom 16: That's because having a landuse on it as well pushes it into the polygon table. It's subsequently rendered as a barrier area, ie. with the barrier=hedge fill. So a similar mess to mkgmap/garmin maps where it assumes there can be only one primary tag. Never been able to understand why this quite simple problem can't be sorted. The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Usually the hedge would have to be interrupted anyway, so the multipolygon approach could also be used to add more detail and have a part of the outline free from the barrier tag). An alternative is to expect that whoever makes a map out of the data will duplicate the geometry and use one way as linear feature and the other as area, but how would you know looking at a closed way if this hedge is linear or mapped as polygon? These issues will probably be solved automatically with a new area type for osm objects. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
On Sun, 2013-01-06 at 17:24 +0100, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Would you not use gate and/or stile tags? Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
2013/1/6 Philip Barnes p...@trigpoint.me.uk: On Sun, 2013-01-06 at 17:24 +0100, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? Would you not use gate and/or stile tags? Yes, you can do this, but the problem of mixing up linear and polygon features has nothing to do with it. Cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
On 06/01/2013 16:24, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. I completely disagree with this. He mapped it accurately as a field with a fence around it. The fact the renderer intentionally put in some code that's unable to handle it is *not* the mappers fault. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. But it's not a multi-polygon. Don't tag/map inaccurately for the renderer. (Strange btw., because how would you then access the field? Usually the hedge would have to be interrupted anyway Err... a POI barrier? , so the multipolygon approach could also be used to add more detail and have a part of the outline free from the barrier tag). An alternative is to expect that whoever makes a map out of the data will duplicate the geometry and use one way as linear feature and the other as area, but how would you know looking at a closed way if this hedge is linear or mapped as polygon? I'm only a hobbiest programmer but why can't an IfThenElse statement with a DoWhile loop solve the problem? I'm not sure how Mapnik works, but assuming it's the same principle as mkgmap (it has the same problem), the renderer shouldn't jump to another file table just because it finds one renderable object. It should also know that barriers are either linear of POI as it's on the perimeter of a polygon it's easy to distinguish. These issues will probably be solved automatically with a new area type for osm objects. cheers, Martin I think it's a 'new' way of rendering that will be the solution. Regards Dave F. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
2013/1/6 Dave F. dave...@madasafish.com: On 06/01/2013 16:24, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. I completely disagree with this. He mapped it accurately as a field with a fence around it. The fact the renderer intentionally put in some code that's unable to handle it is *not* the mappers fault. no, he mapped ambiguously and that's the reason why he gets into trouble. A field with a fence around it could for instance be mapped as fenced=yes on the field (one object in this case, using an attribute for the fence). If you want to map a field and a fence, use 2 objects, one for the field and one for the fence. This matters also when you add more tags, and where it would not be clear to which object they refer to, stupid example: start_date=1968 : is this the fence or the field? cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] uMap Project: OSM everywhere
This looks beautiful. Very easy to use, and that's most important. I'm bookmarking it and looking forward for new releases :) A great feature would be the draw line along road like Google has. I'm not sure how that could be done without having your own router machine. Maybe borrowing OSRM-s routing capacity is possible? Janko Mihelić 2013/1/3 Yohan Boniface yohanbonif...@free.fr Hi, This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). The goal of the project is to provide an app for easy creation of slippy maps for *non technical* end user, with POI, polygons, etc., and embed/share them all over the Big Internet. This project comes *without* any hosting service SaaS like: it just provides the app and will let interested people host (and customize) their own instances. It's in alpha state, I'm preparing the 0.1 release. Here are the already covered features: - create/edit/delete maps - choose the tile layers - add/edit/delete Markers, Polyline, Polygon - manage categories of POIs, to change icon or colors all at once - import GeoJSON and KML from a file or an URL - login/logout - manage permissions (choose who can edit: only owner, selected editors or everybody) - choose icon type - add pictograms to icons (closed list for now) - change icon color (from POI itself or for a group of POIs) - choose the licence of the datas - manage a caption for the map - get an iframe to spread the map - all is i18n compliant Nice features to add in the future: - import POIs from XAPI - upload custom icons - add download option for getting data in GeoJSON - better mobile UI - choose colors from a palette - ... About the modules: * Leaflet-Storage [1]: Leaflet plugin, built on top of Leaflet.Draw et Leaflet.Hash, handling all the client (JavaScript) part; it doesn't know nothing about the backend, so one can also create a Rails, Node or whatever backend * django-leaflet-storage [2]: Leaflet-Storage backend django powered; it's an app, so reusable out the uMap project * uMap [3]: Django project gluing the previous modules, which goal is only to have a plug'n play solution, with some more CSS than the default neutral modules How to help? - test on http://umap.fluv.io and add issues for bugs or enhancements - add new translations (only French has been done) - host an (alpha) instance - code (python, JavaScript, HTML, CSS... or other if one wants to create his own backend) :) Thanks in advance for feedback and help, Happy Open 2013! Yohan [1] https://github.com/**yohanboniface/Leaflet.Storagehttps://github.com/yohanboniface/Leaflet.Storage [2] https://github.com/**yohanboniface/django-leaflet-**storagehttps://github.com/yohanboniface/django-leaflet-storage [3] https://bitbucket.org/**yohanboniface/umaphttps://bitbucket.org/yohanboniface/umap __**_ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talkhttp://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Multi tag rendering (Was Rendering of Farmland not 'Light' enough?)
Martin Koppenhoefer dieterdre...@gmail.com writes: 2013/1/6 Dave F. dave...@madasafish.com: On 06/01/2013 16:24, Martin Koppenhoefer wrote: The problem is with the mapper mixing up linear and polygon features on the same osm object. I completely disagree with this. He mapped it accurately as a field with a fence around it. The fact the renderer intentionally put in some code that's unable to handle it is *not* the mappers fault. no, he mapped ambiguously and that's the reason why he gets into trouble. A field with a fence around it could for instance be mapped as fenced=yes on the field (one object in this case, using an attribute for the fence). If you want to map a field and a fence, use 2 objects, one for the field and one for the fence. This matters also when you add more tags, and where it would not be clear to which object they refer to, stupid example: start_date=1968 : is this the fence or the field? A perhaps unreasonable view, stated overly strongly: The real issue is that there isn't a formal data model that defines semantics from a collection of objects. Neglecting the issue about breaks in fences (which is really a separate nit), a closed way with an area tag and a line barrier tag can be deemed to mean both. There's a similar issue with a point that has foo=bar and baz=bam tags, where normally a point only has one. So one approach is that renderers (including mkgmap) have to essentially process tags, remove them, and try again. The other is to prohibit multiple semantics on an object, and make people use relations. Both are arguably reasonable choices; the project should define one of them as the standard approach. Then, one can say whether the tagging or the renders/transformers are wrong. pgpsKp63TFvDu.pgp Description: PGP signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough? Updated Proposals
Hi all, Thanks for the feedback. I have tested some other shades: https://docs.google.com/open?id=0B6J5ZA1hu93bMzVMQ1Z1SHFqcmM Any additional comments are very welcome. Rob On 5 January 2013 22:18, Rob Nickerson rob.j.nicker...@gmail.com wrote: Hi All, (full text and images at https://docs.google.com/open?id=0B6J5ZA1hu93bYm9IWXdlVHM1N1U ) Recently landuse=farmland (or simply landuse=farm) has been added to fields near me. This has led to a discussion about how the rendering 'looks' with some arguing that it doesn't look that good. I believe that this may be due to the shade of colour used – specifically the farmland 'brown' is not as luminous as the default 'grey' (actually I think it 'lightness' rather than 'luminosity' that matters to the human eye but I got very confused when searching the two). Consider the image below, showing current rendering: https://docs.google.com/open?id=0B6J5ZA1hu93bZDBTN2dZZkpDenc On the left we have farmland tagged. The 'brown' has a Lightness value of 83 percent (luminance of 85%). Compare this to the default canvas 'grey', which has 93 percent Lightness (and 93 percent luminance). Now consider the following (and please check your screen calibration at http://www.photofriday.com/calibrate.php ). I have taken the farmland 'brown' and raised it's Lightness to the same 93 percent as the default 'grey' (that is, I have left the Hue and Saturation the same): https://docs.google.com/open?id=0B6J5ZA1hu93bSzk5NDZVMm5GZkE In this final image, I have adjusted the Hue and Saturation to provide more of a 'green': https://docs.google.com/open?id=0B6J5ZA1hu93bZXhzdVJMVU44X2M What are your thoughts? Which do you prefer? Have I gone too 'light' with the change and should some value in-between be used instead? Am I barking up the wrong tree? Regards, Rob Note: To focus discussion I want to avoid the argument that some people see farmland as the default and therefore it does not need to be tagged – it is a legitimate land-use tag and if people want to tag it then let them. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] uMap Project: OSM everywhere
On 01/06/2013 07:21 PM, Janko Mihelić wrote: This looks beautiful. Very easy to use, and that's most important. I'm bookmarking it and looking forward for new releases :) Thanks! :) A great feature would be the draw line along road like Google has. I'm not sure how that could be done without having your own router machine. Maybe borrowing OSRM-s routing capacity is possible? Damn, this one is not an easy one, but you're right, coupling with a router machine could be really useful. I flag the idea for future me :) [1] By the way, the last days, I've added some users suggestions: - GPX support for batch import - geolocation control (locate user using HTML5 API) - jump to location control (smart geocoding using Nominatim) Plus there is now a German translation and part of an italian one :) Thanks for tests, help and feedback! Yohan [1] for reference: https://github.com/yohanboniface/Leaflet.Storage/issues/23 Janko Mihelić 2013/1/3 Yohan Boniface yohanbonif...@free.fr mailto:yohanbonif...@free.fr Hi, This email for introducing the uMap project. TL;DR: http://umap.fluv.io/ (demo site). The goal of the project is to provide an app for easy creation of slippy maps for *non technical* end user, with POI, polygons, etc., and embed/share them all over the Big Internet. This project comes *without* any hosting service SaaS like: it just provides the app and will let interested people host (and customize) their own instances. It's in alpha state, I'm preparing the 0.1 release. Here are the already covered features: - create/edit/delete maps - choose the tile layers - add/edit/delete Markers, Polyline, Polygon - manage categories of POIs, to change icon or colors all at once - import GeoJSON and KML from a file or an URL - login/logout - manage permissions (choose who can edit: only owner, selected editors or everybody) - choose icon type - add pictograms to icons (closed list for now) - change icon color (from POI itself or for a group of POIs) - choose the licence of the datas - manage a caption for the map - get an iframe to spread the map - all is i18n compliant Nice features to add in the future: - import POIs from XAPI - upload custom icons - add download option for getting data in GeoJSON - better mobile UI - choose colors from a palette - ... About the modules: * Leaflet-Storage [1]: Leaflet plugin, built on top of Leaflet.Draw et Leaflet.Hash, handling all the client (JavaScript) part; it doesn't know nothing about the backend, so one can also create a Rails, Node or whatever backend * django-leaflet-storage [2]: Leaflet-Storage backend django powered; it's an app, so reusable out the uMap project * uMap [3]: Django project gluing the previous modules, which goal is only to have a plug'n play solution, with some more CSS than the default neutral modules How to help? - test on http://umap.fluv.io and add issues for bugs or enhancements - add new translations (only French has been done) - host an (alpha) instance - code (python, JavaScript, HTML, CSS... or other if one wants to create his own backend) :) Thanks in advance for feedback and help, Happy Open 2013! Yohan [1] https://github.com/__yohanboniface/Leaflet.Storage https://github.com/yohanboniface/Leaflet.Storage [2] https://github.com/__yohanboniface/django-leaflet-__storage https://github.com/yohanboniface/django-leaflet-storage [3] https://bitbucket.org/__yohanboniface/umap https://bitbucket.org/yohanboniface/umap _ talk mailing list talk@openstreetmap.org mailto:talk@openstreetmap.org http://lists.openstreetmap.__org/listinfo/talk http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] talk Digest, Multi tag rendering
Hi Philip, The problem is with the mapper mixing up linear and polygon features on the same osm object. You could tag a way with barrier=hedge and then add this way as outer way to a multipolygon relation tagged with landuse=farmland. (Strange btw., because how would you then access the field? This problem can hardly be found here, most farm- or grassland is surrounded by water. On the other hand, the field might be surrounded by a fence. Sofar I never noticed farmland with landuse grass, tagged with a fence.I know however that its a lot of work when, you start to tag all the waterways between the fields. I would tag a gate since its logic to know the place of the entrances or a stile to leave the field without damaging the fencelines. Another example is a corral that has a fence, but its gets dark after adding the fence to the field, should a corral also get a gate ?Whats the use of the tag fence surrounding farmland ? But if theres a hedge tag it. Im curious whtas gonna be. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Rendering of Farmland not 'Light' enough? Updated Proposals
On 6 January 2013 19:13, Rob Nickerson rob.j.nicker...@gmail.com wrote: Thanks for the feedback. I have tested some other shades: https://docs.google.com/open?id=0B6J5ZA1hu93bMzVMQ1Z1SHFqcmM I think the first of the new ones under Update 1 (lighter brown; same lightness as landuse=residential) looks fine. I don't really like any of the other new ones though -- I think they're all too green (and we already use greens for lots of other things). Robert. -- Robert Whittaker ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can Google use our buildings
I'm not sure if this link has been posted before, but for those wondering how Google got their new buildings, there is a link at PC Magazine http://www.pcmag.com/article2/0,2817,2411232,00.asp. Apparently they recently uploaded 25M buildings done through an automated image recognition software. I've manually added most of the buildings in the city of Gilroy ( http://tools.geofabrik.de/mc/?lon=-121.56369lat=37.00553zoom=17) so I was curious to find out where they got their data from. I thought maybe the city or county had a secret source that I hadn't found. And I checked everywhere I could to find buildings that could have been imported. I was wondering if OSM could do the same thing. Could we buy as a group a program like Feature Analyst, eCognition or Imagine Objective and add buildings that way? We could combine the buildings with any existing address points available. I checked into it earlier this year and one program was about $2,000. But the money could be quickly raised. I know I would be willing to donate. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can Google use our buildings
On 2013-01-06, at 7:50 PM, Nathan Mixter nmix...@gmail.com wrote: I was wondering if OSM could do the same thing. Could we buy as a group a program like Feature Analyst, eCognition or Imagine Objective and add buildings that way? We could combine the buildings with any existing address points available. I checked into it earlier this year and one program was about $2,000. But the money could be quickly raised. I know I would be willing to donate. I know an import of multispectral imagery derived building outlines was proposed about a year ago and rejected. I imagine other automaticity generated outlines would have the same issues. The imports list should have a more complete discussion of the issues found. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can Google use our buildings
I understand what why you're saying this, Nathan, but remember these
images are all, relatively, out of date. I would rather that gaps were
left to be filled with what's is actually on the ground rather than what
was there a few years ago.
I take pride that my city has newest buildings roads mapped in OSM
before *any* other mapping service. (I'm still getting around to adding
the old, been there for centuries, houses)
Having all areas filled with polygons of buildings doesn't actually
encourage users to refill it with up to date data. More often than not,
they think because *some* data is mapped it must be correct go map
elsewhere.
Personally I'd rather have (slightly) less, but more accurate data than
blanket inaccurate data. When I first started ('09) I thought the opposite.
On 07/01/2013 00:50, Nathan Mixter wrote:
I'm not sure if this link has been posted before, but for those
wondering how Google got their new buildings, there is a link at PC
Magazine http://www.pcmag.com/article2/0,2817,2411232,00.asp.
Apparently they recently uploaded 25M buildings done through an
automated image recognition software.
I've manually added most of the buildings in the city of Gilroy
(http://tools.geofabrik.de/mc/?lon=-121.56369lat=37.00553zoom=17) so
I was curious to find out where they got their data from. I thought
maybe the city or county had a secret source that I hadn't found. And
I checked everywhere I could to find buildings that could have been
imported.
I was wondering if OSM could do the same thing. Could we buy as a
group a program like Feature Analyst, eCognition or Imagine Objective
and add buildings that way? We could combine the buildings with any
existing address points available. I checked into it earlier this year
and one program was about $2,000. But the money could be quickly
raised. I know I would be willing to donate.
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] OpenStreetMap Future Look
I've been a mapper for just a short while. A little over 1 and a half. I'm surprised how much I like mapping in OSM. There is a real empowerment. For example, at our last mapping party, I met the mayor of the town we held the meetup. He was getting ready to kick of their Centennial celebration. I was able to help by mapping the brand new visitor's center that they were getting ready to open the following day. At the same event I ran into to folks that were changing the name of their mobile home park to a brand new co-op. With their help I was able to enter in the boundaries of the park along with the new name. I wonder about the future of OSM, where it is going and how it's getting there. I've been a Fedora (linux) user since the inception of Fedora. I like how Red Hat provides the employees to work with the community to solve problems. How does that happen in OSM? In my short time I see some weakness. For example, our last mapping party, it would have been nice to invite local mappers to join us. But there isn't an easy way. Since OSM doesn't have a regular announcement means, there is no real easy method to reach out. It would be nice to be able to use the OSM mail application to announce meet ups within x distance of the meetup location. We're mappers, how hard can it be to run a query? Another concern I have is the OSM main map. We have Wikipedia and website links as well as telephone numbers. Shouldn't our flagship home page have links for points of interest? Those are just two areas that need work. As I read this mailing list there are other global issues similar to mine. It seems to me that OSM needs a full time staff that can work with the community to build OSM for the future. I would think that at the rate we are growing, we need to be planning for a much bigger future. -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Can Google use our buildings
Dave -
What is the collection date of the imagery used? I couldn't find reference
to it.
What would be the measure of relatively out of date? Outside of newly
developed areas, even imagery that is 5 years old could reasonably be
expected to be ~95% accurate over most of the country. (Based on building
completion estimates). So, isn't much of what's actually on the ground
actually depicted in imagery that's only a few years old?
Is there measured proof that filled maps are never QA'd? If so, why does
Google offer tools to do just that? If there is no proof, what is the basis
of your hypothesis?
What would stop OSMers from QAing this type of data collection prior to
inclusion in OSM?
Why is accuracy the primary measure of concern here? As opposed to, say:
completeness or consistency?
Would it be that big of a problem if someone mapped somewhere other than
where these building images are, as long as they were mapping?
Thanks, Jeff
On Sun, Jan 6, 2013 at 5:28 PM, Dave F. dave...@madasafish.com wrote:
I understand what why you're saying this, Nathan, but remember these
images are all, relatively, out of date. I would rather that gaps were left
to be filled with what's is actually on the ground rather than what was
there a few years ago.
I take pride that my city has newest buildings roads mapped in OSM
before *any* other mapping service. (I'm still getting around to adding the
old, been there for centuries, houses)
Having all areas filled with polygons of buildings doesn't actually
encourage users to refill it with up to date data. More often than not,
they think because *some* data is mapped it must be correct go map
elsewhere.
Personally I'd rather have (slightly) less, but more accurate data than
blanket inaccurate data. When I first started ('09) I thought the opposite.
On 07/01/2013 00:50, Nathan Mixter wrote:
I'm not sure if this link has been posted before, but for those wondering
how Google got their new buildings, there is a link at PC Magazine
http://www.pcmag.com/article2/0,2817,2411232,00.asp. Apparently they
recently uploaded 25M buildings done through an automated image recognition
software.
I've manually added most of the buildings in the city of Gilroy (
http://tools.geofabrik.de/mc/?lon=-121.56369lat=37.00553zoom=17) so I
was curious to find out where they got their data from. I thought maybe the
city or county had a secret source that I hadn't found. And I checked
everywhere I could to find buildings that could have been imported.
I was wondering if OSM could do the same thing. Could we buy as a group a
program like Feature Analyst, eCognition or Imagine Objective and add
buildings that way? We could combine the buildings with any existing
address points available. I checked into it earlier this year and one
program was about $2,000. But the money could be quickly raised. I know I
would be willing to donate.
___
talk mailing
listtalk@openstreetmap.orghttp://lists.openstreetmap.org/listinfo/talk
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
--
Jeff Meyer
Global World History Atlas
www.gwhat.org
j...@gwhat.org
206-676-2347
www.openstreetmap.org/user/jeffmeyer
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] OpenStreetMap Future Look
Maybe the home page should not have a map on it (it's only a sample of what is in the database anyway, which will always be lacking some feature). Instead it could have links to openlinkmap.org (which is what you seem to want), hikebikemap.de, http://demo.3liz.com/osmtransport/ and many more fine examples of other ways to represent the available data. Polyglot 2013/1/7 Clifford Snow cliff...@snowandsnow.us I've been a mapper for just a short while. A little over 1 and a half. I'm surprised how much I like mapping in OSM. There is a real empowerment. For example, at our last mapping party, I met the mayor of the town we held the meetup. He was getting ready to kick of their Centennial celebration. I was able to help by mapping the brand new visitor's center that they were getting ready to open the following day. At the same event I ran into to folks that were changing the name of their mobile home park to a brand new co-op. With their help I was able to enter in the boundaries of the park along with the new name. I wonder about the future of OSM, where it is going and how it's getting there. I've been a Fedora (linux) user since the inception of Fedora. I like how Red Hat provides the employees to work with the community to solve problems. How does that happen in OSM? In my short time I see some weakness. For example, our last mapping party, it would have been nice to invite local mappers to join us. But there isn't an easy way. Since OSM doesn't have a regular announcement means, there is no real easy method to reach out. It would be nice to be able to use the OSM mail application to announce meet ups within x distance of the meetup location. We're mappers, how hard can it be to run a query? Another concern I have is the OSM main map. We have Wikipedia and website links as well as telephone numbers. Shouldn't our flagship home page have links for points of interest? Those are just two areas that need work. As I read this mailing list there are other global issues similar to mine. It seems to me that OSM needs a full time staff that can work with the community to build OSM for the future. I would think that at the rate we are growing, we need to be planning for a much bigger future. -- Clifford OpenStreetMap: Maps with a human touch ___ 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: [Talk-de] temporaeres Festival-Gelaende
Hallo, bei mir vor Ort findet jedes Jahr das Hurricane Festival in Scheeßel statt. Die Laufwege, Bühnen, Toiletten usw. stehen aber jedes Jahr anders. Daher ist das Gelände nur als Wiese erfasst. Mit freundlichen Grüßen Stephan aka smarties Original-Nachricht Datum: Thu, 3 Jan 2013 22:43:02 +0100 Von: Christian H. Bruhn br...@arcor.de An: talk-de@openstreetmap.org Betreff: [Talk-de] temporaeres Festival-Gelaende Hallo! Das Gelände des Wacken-Open-Air-Festivals [1] ist in OSM recht detailliert gemappt [2]. Allerdings ist das Gelände (mit Auf- und Abbau) nur wenige Wochen im Jahr Festivalgelände. Den Rest des Jahres ist es normale landwirtschaftliche Nutzfläche. Ich würde sagen, die Daten haben in OSM nichts zu suchen. Es könnte sich aber jemand die Mühe machen, bei Veranstaltungsbeginn die Objekte reinzunehmen und nach Beendigung wieder zu löschen (so wie schon oft beim Hamburger Dom geschehen. Wäre es alternativ eine Lösung, die Objekte in einen speziellen Namensraum (z.B. woa:*) zu verschieben? Allerdings sind die Eintragungen aus 2011. Ich weiß nicht, in wie fern die Wege und Bühnen jedes Jahr gleich sind. Ich will da jetzt nichts ohne Rücksprache verändern und wüßte gerne, ob man dem Ersteller eine Alternative anbieten kann. Christian [1] http://de.wikipedia.org/wiki/Wacken_Open_Air [2] http://www.openstreetmap.org/?lat=54.0253lon=9.3815zoom=14layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Uebermaessiges taggen von highways mit oneway=no...
Hallo, das mit den oneway=no finde ich noch einigermaßen OK. Extrem wird es erst wenn ich in der Norddeutschen Tiefeben und sogar auf den Nordseeinsteln ständig so merkwürdige Dinge finde wie z.B.: snowmobile=yes auf tausenden Wegen. Wohlgemerkt auch auf den Nordseeinseln! Ich hatte auch schon mal elephant=yes. Habe das aber dann locker entfernt da die deutsche Stvo kein explizites Verbot für Elefanten hat. Manchmal kommen mir User unter die sogar in der Wüste eintragen würden das der Weg für Snowmobile freigegeben ist weil dort kein Schild steht das es verboten ist! Als Fehler markiert JOSM wenn ein Weg embarkment=no oder cutting=no hat. Daher kann man den Fehler dann korrigieren und das entfernen. Mit freundlichen Grüßen Stephan aka smarties Original-Nachricht Datum: Thu, 03 Jan 2013 15:27:16 +0100 Von: Werner Poppele popp...@hm.edu An: talk-de@openstreetmap.org Betreff: Re: [Talk-de] Uebermaessiges taggen von highways mit oneway=no... Frederik Ramm wrote: Hi, On 01/03/2013 08:27 AM, Werner Poppele wrote: Es waere schoen, wenn jemand sich das mal anschauen koennte und mir die Meinung dazu bitte mitteilen wuerde und wie und ob das korrigiert werden sollte. Es sieht fuer mich so aus, als ob da jemand einfach nur in einem Tagging-Preset alles moeglichst gewissenhaft ausfuellen wollte (und dabei moeglicherweise noch gestoehnt hat, dass er fuer jeden Weg so viele Haekchen setzen muss...). Schonmal den direkten Kontakt gesucht? (Wenn auch aeltere Changeset-Kommentare des betreffenden Benutzers, Maler, auf eine gewisse Genervtheit hindeuten z.B. http://www.openstreetmap.org/browse/changeset/13326651 - aber ich bin sicher, man kann ihm das erklaeren.) Vielleicht sollte man auch im JOSM-Preset deutlicher darauf hinweisen, dass keine Einstellung (bei sowas wie oneway) durchaus zulaessig ist ;) Bye Frederik Ich bin bei der Diskussion zum Thema Eintrag von Standardwerten - wie wohl viele - hin- und hergerissen. Auf der einen Seite finde ich den Standardwert von maxspeed=50 durchaus fuer sinnvoll, auf der anderen Seite ist beispielsweise der Standardwert oneway=no bei Zufahrten zu Haeusern ein bisschen uebertrieben. Falsch ist es ganz klar nicht. Streitfaelle wird es wohl bei dem Thema immer geben. Ich werde mit dem User Maler Kontakt aufnehmen. Vielen Dank fuer die Rueckmeldungen WernerP ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Martin Koppenhoefer dieterdre...@gmail.com wrote: naja, Köln ist wohl doch gerade ein Fall, wo ich den lateinischen Namen als name:la eintragen würde. Colonia Claudia Ara Agrippinensium, ich sehe gerade, das hat schon jemand in OSM eingetragen. Für damalige Verhältnisse war das glaub schon ein place=city [1]. http://pelagios.dme.ait.ac.at/maps/greco-roman/ Worauf ich raus will: Für solche Sachen eignet sich eine Spiezialkarte wie diese mit Spezialdatenbank, die sich ja kaum noch ändert, wenn es keine neuen Forschungsergebnisse gibt, erheblich besser als OSM Sven -- The term any key does not refer to a particular key on the keyboard. It simply means to strike any one of the keys on your keyboard or handheld screen. (Compaq FAQ Entry 2859) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Römerstraße (was: Demo mehrsprachige Karte)
Joachim Kast osm...@dd1gj.de wrote: Manchmal werden Sie sogar so genannt: http://www.openstreetmap.org/browse/way/4703133 http://taginfo.openstreetmap.org/tags/name=R%C3%B6merstra%C3%9Fe Gibts immerhin 2333 mal :) Das kann nun aber in 3 Fällen auftreten: 1. Rein neuzeitlicher Straßenname 2. Neuzeitlicher Straßenname aufgrund einer Römerstraße am selben Ort 3. Oberschlauer Mapper, der eine ehemalige Römerstraße mit name=Römerstraße getaggt hat. Ein solcher Fall wäre beispielsweise das hier: http://www.openstreetmap.org/browse/way/33573321 Gruss Sven -- Das Internet wird vor allem von Leuten genutzt, die sich Pornografie ansehen, während sie Bier trinken, es ist daher für Wahlen nicht geeignet (Jaroslaw Kaczynski) /me is giggls@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] temporaeres Festival-Gelaende
Hallo, das Wacken-Open-Air kenne ich zwar nicht, aber für das Taggen von Veranstaltungsgeländen und dessen Objekten, die regelmäßig gleich vorhanden sind, aber einen großen Teil des Jahres gar nicht existieren, brauchen wir eine einheitliche Tagging-Konvention. Das Problem mit temporären Objekten ist hier in München z.B. mit Oktoberfest und Tollwood auch schon auffällig geworden. Da hatten zunächst einige versucht, die Zelte mit tmp_building, tmp:building o.ä. zu markieren und dann zur Zeit das tmp o.ä. herauszunehmen/editieren. Das entfernen/hinzufügen ist aber nicht praktikabel, weil der, der das mal getaggt hat, das in den seltensten Fällen überwachen kann. Ein User hat dann mal was -IMHO recht sinnvolles- dazu vorgeschlagen (das z.B. auch für saisonbedingte Schließungen von Wegen u.ä. angewendet werden kann) und das dann auch für die Wiesn-Zelte angewandt: http://wiki.openstreetmap.org/wiki/Proposed_features/temporary Ich denke, genau dieses Taggingschema würde für jedes Festival-Gelände passen. Leider scheint die Diskussion bislang im Sande verlaufen zu sein. Genauer nachdenken müsste man nochmal über die Gültigkeitszeiträume und da ähnlich Öffnungszeiten, Betriebszeiten u.ä. die gleichen Konvertionen anwenden, aber, es müssen da auch soclhe Sachen wie letzter Sonntag im August o.ä. unmisverständlich dargestellt werden. Wenn sich die Zeiten ändern muss man entweder auch ungenauere Zeitangabe unterstützen oder man behandelt das dann nach Bekanntwerden des neuen Termins wie jede andere notwendig Korrektur der Karte... Hagen Gesendet: Donnerstag, 03. Januar 2013 um 22:43 Uhr Von: Christian H. Bruhn br...@arcor.de An: talk-de@openstreetmap.org Betreff: [Talk-de] temporaeres Festival-Gelaende Hallo! Das Gelände des Wacken-Open-Air-Festivals [1] ist in OSM recht detailliert gemappt [2]. Allerdings ist das Gelände (mit Auf- und Abbau) nur wenige Wochen im Jahr Festivalgelände. Den Rest des Jahres ist es normale landwirtschaftliche Nutzfläche. Ich würde sagen, die Daten haben in OSM nichts zu suchen. Es könnte sich aber jemand die Mühe machen, bei Veranstaltungsbeginn die Objekte reinzunehmen und nach Beendigung wieder zu löschen (so wie schon oft beim Hamburger Dom geschehen. Wäre es alternativ eine Lösung, die Objekte in einen speziellen Namensraum (z.B. woa:*) zu verschieben? Allerdings sind die Eintragungen aus 2011. Ich weiß nicht, in wie fern die Wege und Bühnen jedes Jahr gleich sind. Ich will da jetzt nichts ohne Rücksprache verändern und wüßte gerne, ob man dem Ersteller eine Alternative anbieten kann. Christian [1] http://de.wikipedia.org/wiki/Wacken_Open_Air [2] http://www.openstreetmap.org/?lat=54.0253lon=9.3815zoom=14layers=M ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Römerstraße (was: Demo mehrsprachige Karte)
Am 6. Januar 2013 15:01 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Joachim Kast osm...@dd1gj.de wrote: Manchmal werden Sie sogar so genannt: http://www.openstreetmap.org/browse/way/4703133 http://taginfo.openstreetmap.org/tags/name=R%C3%B6merstra%C3%9Fe Gibts immerhin 2333 mal :) Das kann nun aber in 3 Fällen auftreten: 1. Rein neuzeitlicher Straßenname 2. Neuzeitlicher Straßenname aufgrund einer Römerstraße am selben Ort 3. Oberschlauer Mapper, der eine ehemalige Römerstraße mit name=Römerstraße getaggt hat. Ein solcher Fall wäre beispielsweise das hier: http://www.openstreetmap.org/browse/way/33573321 Müsste der Fall 1 nicht Römer Straße sein ;-) ? Hast Du dafür mal ein Beispiel aus der echten Welt? Ist beim Beispiel Fall 3 ein grade5 nicht ein bisschen seltsam, wenn tracktype (auch) den Ausbauzustand beschreiben soll? Vorschlag für historische Straßen: historic=road Nach aktueller Nutzung führt allerdings roman_road vor dem generischen road, (street und highway als Wert werden dagegen fast nicht genutzt für historische Straßen). Ich befürworte trotzdem ein schlichtes road, und das Taggen der jeweiligen antiken Baumeister mit historic:civilization [2]. Gruß Martin [1] http://taginfo.openstreetmap.org/search?q=historic%3Droad [2] http://wiki.openstreetmap.org/wiki/Key:historic:civilization ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Römerstraße (was: Demo mehrsprachige Karte)
Die ehemalige Römerstraße zwischen Neuenheim (bei Heidelberg) über Lopodunum (Ladenburg) und Straßenheim (bei Mannheim) ist auf http://pelagios.dme.ait.ac.at/maps/greco-roman/ gut erkennbar, bei Straßenheim http://www.strassenheim.de/historie.html war ein Abzweig nach Worms, der ist aber nicht mehr erkennbar. Bis Straßenheim ist die (erhöhte) Straße (heute Wirtschaftsweg) in der Umgebung als ehemalige Römerstraße gut bekannt und auch in vielen Radwanderkarten so bezeichnet, obwohl dort nirgends ein Schild steht. Auf Heddesheimer Gemarkung wird sie auch als Römerstraße bezeichnet http://www.openstreetmap.org/browse/way/25681003, ich weiß aber nicht, ob das eine offizielle Bezeichnung ist. Mannheim und Ladenburg haben bereits neuzeitliche Römerstraßen, auf deren Gemarkung wurden bei Flurbereinigungen andere neuzeitliche Namen (Ladenburger Weg bzw. Hohe Straße) vergeben. Trotzdem ist sie unter ehemaliger Römerstraße bekannter. Ich habe name = Ladenburger Weg (ehemalige Römerstraße) bzw. name = Hohe Straße (ehemalige Römerstraße) eingetragen, was aber nicht ganz stimmt. Wie würdet ihr den bekannteren Namen ehemalige Römerstraße hinterlegen, so dass er auch angezeigt wird? Bernhard From: Sven Geggus [mailto:li...@fuchsschwanzdomain.de] Sent: Sunday, January 06, 2013 3:01 PM To: talk-de@openstreetmap.org Subject: [Talk-de] Römerstraße (was: Demo mehrsprachige Karte) Joachim Kast osm...@dd1gj.de wrote: Manchmal werden Sie sogar so genannt: http://www.openstreetmap.org/browse/way/4703133 ... Das kann nun aber in 3 Fällen auftreten: 1. Rein neuzeitlicher Straßenname 2. Neuzeitlicher Straßenname aufgrund einer Römerstraße am selben Ort 3. Oberschlauer Mapper, der eine ehemalige Römerstraße mit name=Römerstraße getaggt hat. Ein solcher Fall wäre beispielsweise das hier: http://www.openstreetmap.org/browse/way/33573321 ... ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Demo mehrsprachige Karte
Am 6. Januar 2013 14:49 schrieb Sven Geggus li...@fuchsschwanzdomain.de: Martin Koppenhoefer dieterdre...@gmail.com wrote: naja, Köln ist wohl doch gerade ein Fall, wo ich den lateinischen Namen als name:la eintragen würde. Colonia Claudia Ara Agrippinensium, ich sehe gerade, das hat schon jemand in OSM eingetragen. Für damalige Verhältnisse war das glaub schon ein place=city [1]. http://pelagios.dme.ait.ac.at/maps/greco-roman/ Worauf ich raus will: Für solche Sachen eignet sich eine Spiezialkarte wie diese mit Spezialdatenbank, die sich ja kaum noch ändert, wenn es keine neuen Forschungsergebnisse gibt, erheblich besser als OSM ja klar, gegen eine Spezialdatenbank spricht natürlich nichts (darum gibts ja auch so viele davon), aber so was wie einen alten Namen oder die Kultur, die ein bestimmtes Kulturgut errichtet hat, kann man ja trotzdem in OSM eintragen, vor allem, da wir die Objekte, deren Informationen damit ergänzt werden, normalerweise schon in OSM drin haben. In OSM haben wir oft eine bessere räumliche Auflösung (auf wenige Meter genau), die bei solchen Projekten wie dem verlinkten nicht immer gegeben ist (bei einer Stadt spielt das keine Rolle, aber bei einer Straße oder Einzelgebäuden und Monumenten ist der genaue Verlauf / Lage schon interessant). Klar, es gibt auch archäologische Daten, die noch wesentlich genauer sind als das, was OSM in der Regel hat. Zwar könnte man erwarten, dass sich die Datenbasis nicht mehr ändern würde, sofern es keine Forschungsergebnisse gäbe, aber zum einen ist längst nicht alles digitalisiert und zum anderen gibt es permanent neue Forschungsergebnisse ;-) Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Römerstraße (was: Demo mehrsprachige Karte)
Am 6. Januar 2013 17:56 schrieb Bernhard Weiskopf bweisk...@gmx.de: Ich habe name = Ladenburger Weg (ehemalige Römerstraße) bzw. name = Hohe Straße (ehemalige Römerstraße) eingetragen, was aber nicht ganz stimmt. Wie würdet ihr den bekannteren Namen ehemalige Römerstraße hinterlegen, so dass er auch angezeigt wird? wenn das ein Name ist, der alternativ, evtl. auch nur lokal, benutzt wird, dann könnte man alt_name oder loc_name oder ähnliches als Key dafür verwenden. Dieses Zeugs in Klammern gehört da sicher nicht hin, sofern es nicht Teil des Namens ist. Wenn man dagegen in der Datenbank festhalten will, dass es sich um eine alte Römerstraße handelt, dann würde ich das mit den bereits erwähnten tags tun: historic=road und historic:civilization=ancient_roman Die kann man dann ganz einfach filtern wenn man mal alle Römerstraßen in Europa haben will oder so. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Uebermaessiges taggen von highways mit oneway=no...
Servus, Am 03.01.2013 15:27, schrieb Werner Poppele: Ich bin bei der Diskussion zum Thema Eintrag von Standardwerten - wie wohl viele - hin- und hergerissen. Auf der einen Seite finde ich den Standardwert von maxspeed=50 durchaus fuer sinnvoll, auf der anderen Seite ist beispielsweise der Standardwert oneway=no bei Zufahrten zu Haeusern ein bisschen uebertrieben. Falsch ist es ganz klar nicht. Streitfaelle wird es wohl bei dem Thema immer geben. Ich werde mit dem User Maler Kontakt aufnehmen. Gib doch bitte hier evtl auch kurz Rückmeldung falls du was hörst. Ich bin in der Region um Bad Tölz auch schon auf den User gestoßen - im Endeffekt war ich aber froh, dass sich jemand SO viel Mühe gemacht hat, so dass ich auch gerne über das sehr intensive Tagging hinweggesehen habe :) Grüße Franz ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Römerstraße
Ich nehme an, es handelt sich hierbei um eine Trennung einer Straße (der Römerstraße) in zwei Straßen (Ladenburger Weg und Hohe Straße). Bernhard möchte dort den alten Namen noch hinterlegen, damit man dies per Nominatim oder ähnlich noch findet. MfG MonkZ On 06.01.2013 18:21, Martin Koppenhoefer wrote: Am 6. Januar 2013 17:56 schrieb Bernhard Weiskopf bweisk...@gmx.de: Ich habe name = Ladenburger Weg (ehemalige Römerstraße) bzw. name = Hohe Straße (ehemalige Römerstraße) eingetragen, was aber nicht ganz stimmt. Wie würdet ihr den bekannteren Namen ehemalige Römerstraße hinterlegen, so dass er auch angezeigt wird? wenn das ein Name ist, der alternativ, evtl. auch nur lokal, benutzt wird, dann könnte man alt_name oder loc_name oder ähnliches als Key dafür verwenden. Dieses Zeugs in Klammern gehört da sicher nicht hin, sofern es nicht Teil des Namens ist. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Römerstraße
Am 6. Januar 2013 20:00 schrieb MonkZ i...@monkz.de: Ich nehme an, es handelt sich hierbei um eine Trennung einer Straße (der Römerstraße) in zwei Straßen (Ladenburger Weg und Hohe Straße). Bernhard möchte dort den alten Namen noch hinterlegen, damit man dies per Nominatim oder ähnlich noch findet. wenn der alternative Name der alte offizielle Name einer Straße ist, würde ich old_name verwenden. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] lanes
Hallo, gibt es einen Konsens wie die Verkehrszeichen 295 Fahrstreifenbegrenzung und Fahrbahnbegrenzung 296 Einseitige Fahrstreifenbegrenzung 298 Sperrflächen bei lanes eingetragen werden? Schönen Abend noch Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] lanes
Hi, Schau dir mal den Schlüssel change an: http://wiki.openstreetmap.org/wiki/Proposed_features/change Vg, Martin Am 06.01.2013 um 21:42 schrieb Jörg Frings-Fürst o...@jff-webhosting.net: Hallo, gibt es einen Konsens wie die Verkehrszeichen 295 Fahrstreifenbegrenzung und Fahrbahnbegrenzung 296 Einseitige Fahrstreifenbegrenzung 298 Sperrflächen bei lanes eingetragen werden? Schönen Abend noch Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] lanes
Hi Martin, machmal sieht man(n) den Wald vor lauter Bäumen nicht ;-)) Jörg Am Sonntag, den 06.01.2013, 22:05 +0100 schrieb Martin Vonwald (Imagic): Hi, Schau dir mal den Schlüssel change an: http://wiki.openstreetmap.org/wiki/Proposed_features/change Vg, Martin Am 06.01.2013 um 21:42 schrieb Jörg Frings-Fürst o...@jff-webhosting.net: Hallo, gibt es einen Konsens wie die Verkehrszeichen 295 Fahrstreifenbegrenzung und Fahrbahnbegrenzung 296 Einseitige Fahrstreifenbegrenzung 298 Sperrflächen bei lanes eingetragen werden? Schönen Abend noch Jörg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] R: Aggiornamento dati ortografia strade
Am 05/gen/2013 um 22:54 schrieb Giovanni Fasano g...@gvf.ve.it:
Il 03/01/2013 00:06, Daniele Forsi ha scritto:
{{Bio
|Nome = Ferdinando II de'
|Cognome = Medici
la divisione in nome e cognome è strana ma non ci è indispensabile
La divisione nel template Bio è legata all'ordinamento alfabetico per
cognome. Ovvero prima ordina per cognome e poi per nome (e tutto il resto).
Si, ma de' fa parte del nome o del cognome? Avrei pensato de' Medici e nel
ordinamento Medici, de' sarebbe il cognome.
Ciao,
Martin
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Varie Porta Nuova a Milano
2013/1/5 emmexx emm...@tiscalinet.it: Il 01/05/2013 02:47 PM, sabas88 scrisse: Quei tre buchi devi metterli con ruolo outer (http://wiki.openstreetmap.org/wiki/Multipolygon caso island within an hole). Ok, spero vada bene. Ma il multiplygon rel 2625489 non ha i tag che descrivano. Devo spostare (o copiare) i tag highway=pedestrian e area=yes dalla way 195074660 alla rel 2625489 Prova a guardare sul wiki Multipolygon Examples http://wiki.openstreetmap.org/wiki/Multipolygon_Examples Altra cosa che ho notato usando rendering diversi da Mapnik. In uno dei buchi si intravede la linea del Passante. Anche se il wiki parla esplecittamente di un caso simile (sezione Island within a hole), non so se ciò basti per poter concludere che tutti i rendering (o altre implementazioni) siano in grado di gestire la situazione come lì descritta. Non so se questo sia il caso, ma se continui ad avere problemi (dopo aver messo i tag alla relazione 2625489), prova a creare una nuova relazione che ha come tag natural=water (e gli altri tag della way 199526622), come outer la way 199526622 e come inner la way 195074659 e analogamente per gli altri buchi AnyFile ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Scostamento immagini aeree
Il 06/01/2013 07:32, marco bra ha scritto: mario, mi daresti il riferimento con link osm per le villette a schiera di cui parli Grazie mcheck Sono quelle di Via Migliarini. http://www.openstreetmap.org/browse/changeset/9580322 Ho segnalato le villette, per lo scostamento abbastanza accentuato rispetto agli edifici in vicinanza. Vicino alle villette vedo un_area:yes_ landuse:farm http://www.openstreetmap.org/browse/changeset/13541405 Lo usiamo ancora farm, non era stato sostituito da farmland ? Come sai io osservo, cerco di capire e se posso miglioro, ho scelto Arenzano per la varietà dei toponimi e per la pulizia di lavoro. Ogni tanto guardo nella barra laterale (autore) e vedo, spesso, mcheck.:-) Buona giornata, Mario. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Aggiornamento dati ortografia strade
Il 06/01/2013 10:30, Martin Koppenhoefer ha scritto:
Am 05/gen/2013 um 22:54 schrieb Giovanni Fasano g...@gvf.ve.it:
Il 03/01/2013 00:06, Daniele Forsi ha scritto:
{{Bio
|Nome = Ferdinando II de'
|Cognome = Medici
la divisione in nome e cognome è strana ma non ci è indispensabile
La divisione nel template Bio è legata all'ordinamento alfabetico per cognome.
Ovvero prima ordina per cognome e poi per nome (e tutto il resto).
Si, ma de' fa parte del nome o del cognome? Avrei pensato de' Medici e nel
ordinamento Medici, de' sarebbe il cognome.
de' Medici viene ordinato sotto la M.
In realtà il campo Nome non viene utilizzato solo per il nome ma per
tutto quello che va tolto al cognome per avere l'ordinamento voluto.
Nella maggior parte di casi si tratta del nome ma ci sono appunto delle
eccezioni...
--
Ciao Gio.
___
Talk-it mailing list
Talk-it@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Aggiornamento dati ortografia strade
2013/1/6 Giovanni Fasano g...@gvf.ve.it: Si, ma de' fa parte del nome o del cognome? Avrei pensato de' Medici e nel ordinamento Medici, de' sarebbe il cognome. de' Medici viene ordinato sotto la M. appunto, per quello avrei pensato che si scriverebbe cognome: Medici, de' E' troppo strano Ferdinando II de' come nome. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] R: Aggiornamento dati ortografia strade
Il 06/01/2013 18:24, Martin Koppenhoefer ha scritto: 2013/1/6 Giovanni Fasano g...@gvf.ve.it: Si, ma de' fa parte del nome o del cognome? Avrei pensato de' Medici e nel ordinamento Medici, de' sarebbe il cognome. de' Medici viene ordinato sotto la M. appunto, per quello avrei pensato che si scriverebbe cognome: Medici, de' E' troppo strano Ferdinando II de' come nome. I due campi vengono usati anche per comporre l'incipit della voce e mediawiki su wikipedia non ha funzioni di gestione stringhe. Con i due campi usati cosi basta visualizzarli uno dopo l'altro per avere la visualizzazione corretta... -- Ciao Gio. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Visualizzare amenity specifico
Salve, vorrei sovrapporre alla solita mappa dei marker relativi a una particolare amenity, per esempio voglio vedere dove sono tutte le gelaterie in una certa area. Sembra che da www.openstreetbrowser sia possibile creare nuove regole, quali sono altre soluzioni? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Visualizzare amenity specifico
XAPI Viewer . Esempio : http://osm.dumoulin63.net/xapiviewer/?zoom=14lat=43.5455lon=10.31954layers=0BTicon=icons%2Ffood_ice_cream.n.32.pngrequest=amenity%3Dice_cream FabC Il giorno 06 gennaio 2013 20:20, Ruggero giurr...@gmail.com ha scritto: Salve, vorrei sovrapporre alla solita mappa dei marker relativi a una particolare amenity, per esempio voglio vedere dove sono tutte le gelaterie in una certa area. Sembra che da www.openstreetbrowser sia possibile creare nuove regole, quali sono altre soluzioni? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Scostamento immagini aeree
Mario, mi fa' piacere correggere, in effetti, dette case a schiera risultavano da una edificazione recente rispetto alle date dei satellitari e a causa di cio' le avevo mappate in modo grossolano dal pcn dal quale potevo desumere solo l'area di cantiere... Ora la mappatura dovrebbe essere migliore... Mi togli una curiosità: che metodo usi per rilevare detti scostamenti, usi un metodo automatico ? Ciao Grazie mcheck Il giorno 06 gennaio 2013 14:48, Mario Pichetti mario.piche...@gmail.comha scritto: Il 06/01/2013 07:32, marco bra ha scritto: mario, mi daresti il riferimento con link osm per le villette a schiera di cui parli Grazie mcheck Sono quelle di Via Migliarini. http://www.openstreetmap.org/**browse/changeset/9580322http://www.openstreetmap.org/browse/changeset/9580322 Ho segnalato le villette, per lo scostamento abbastanza accentuato rispetto agli edifici in vicinanza. Vicino alle villette vedo un_area:yes_ landuse:farm http://www.openstreetmap.org/**browse/changeset/13541405http://www.openstreetmap.org/browse/changeset/13541405 Lo usiamo ancora farm, non era stato sostituito da farmland ? Come sai io osservo, cerco di capire e se posso miglioro, ho scelto Arenzano per la varietà dei toponimi e per la pulizia di lavoro. Ogni tanto guardo nella barra laterale (autore) e vedo, spesso, mcheck.:-) Buona giornata, Mario. __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it -- Linux Infinite Freedom I'm writing from this place: http://www.openstreetmap.org/?lat=44.39945lon=8.6798zoom=15layers=M ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-dk] Fugro luftfotos på sydfyn, vest for Svendborg
Hm, jeg kan ikke lige gennemskue, hvorfor nogle af de tiles driller. Måske der er problemer med enkelte af Fugro-billederne. Internt ser jeg følgende fejl: Failed to draw layer named 'fugro'. Could not perform Read/Write on file: Unable to access file. Dog, med lidt held har vi adgang til nyere luftfotos inden for de næste par uger fra Geodatastyrelsen. Så burde der være nyt materiale at trace efter. Som altid må vi lige finde ud af et sted at have det liggende. Jeg må lige se, om jeg kan rydde lidt mere plads frem på serveren eller sætte en ny maskine op. Andre må naturligvis også gerne byde ind, hvis de har masser af serverplads på en server (Fugro fylder ca. 80 GB, jeg gætter på at de her fylder mere) og adgang til at installere software til at spytte grafikfiler tilbage. - Peter 2013/1/6 Anders Lund and...@alweb.dk: Hej, Jeg mapper (on and off) på sydfyn, vest for Svendborg. I dag har jeg tracet huse startende fra den vestlige ende af Svendborg kommune, men jeg løber ind i problemer da fugro dækningen ikke er så god en del steder. Fx i Ollerup, Rantzausminde og den sydlige side af Ulbølle. For eksempel sådan her: http://osm.rasher.dk/?zoom=18lat=55.07236lon=10.42631layers=B0FTF Er der noget man kan gøre, eller skal man forsøge at finde en anden løsning? Venlig hilsen, Anders ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-es] Crear una calle partiendo de otra
On Viernes, 4 de enero de 2013 13:26:45 Javier Fernández Arroyo escribió: estoy usando el editor web, todavía no he probado JOSM, aunque me lo he descargado... Para Potlatch 2, in a nutshell: Click en la calle para seleccionarla. Shift+Click en un punto de la calle para crear un nuevo nodo ahí. Shift+Click en el nodo recién creado para crear una nueva vía a partir de ese nodo. Click en el final de la nueva vía que estás dibujando. Es cuestión de hacerse a los triquitos de Potlatch con shift+click para estas cosas, aunque yo prefiero más usar JOSM y poder cambiar entre los modos de selección y dibujo. -- Iván Sánchez Ortega i...@sanchezortega.es i...@geonerd.org ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 00:47, schrieb Friedrich Volkmann: On 05.01.2013 23:37, Erwin OSM wrote: Nur noch eine Frage! Seit wann muss man *einen Einzelnen* um Zustimmung fragen, wenn man etwas taggen will? Ich finde, das geht doch etwas zu weit!!! Wenn man einen Konsens finden will, fragt man andere, was sie von dieser oder jener Lösung halten. Das ist kein Um-Erlaubnis-Fragen. Ich empfinde es bei diese Diskussion schon so. Viele andere Erfasser taggen eben die maxspeeds auch bei Landesstraßen mit 100 und ich habe den Eindruck, dass Du der Einzige bist, der diese Einträge eben wieder löscht! Ein Konsens kann nicht darin bestehen, dass ein einzelner User (hallo al) ihn festlegt. Und auch nicht darin, dass einer munter drauf los taggt und dann sagt, so das ist jetzt Konsens. Du hast von meinem Mail ein Fullquote gemacht und bist auf keinen einzelnen Satz eingegangen. Wenn man alle Landesstraßen durchgeht, ist das nicht nur viel Arbeit, sondern man muss auch versuchen, das Tagging halbwegs einheitlich zu halten. Also ein highway=secondary im Nordburgenland sollte ungefähr das gleiche sein wie ein highway=secondary im Südburgenland. Genauso ist das mit den maxspeed. Wenn jeder taggt, wie er grad lustig ist, kommt nur ein Chaos heraus. Es taggt nicht jeder wie er gerade lustig ist, es wird nur einfach der maxspeed auch an Landesstraßen erfasst, eben mit 100 km/h, mehr nicht. Man kann leicht schimpfen, wenn man die Arbeit nicht selber macht. In NÖ sind z.B. die L6xxx noch nicht komplett, wär das eine Aufgabe für dich? Weiters möchte ich Dich auf folgende Wikipedia-Seite hinweisen: http://de.wikipedia.org/wiki/Liste_der_Landesstra%C3%9Fen_in_Tirol Und hier bitte auf die Nachweise hinunter scrollen! Ich glaube behaupten zu können, dass mehr als die Hälfte der hier bereits eingetragenen Landesstraßen in Tirol von mir erfasst wurden. So viel zu Deiner Frage, ob es eine Aufgabe für mich wäre ;-) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 00:47, schrieb Friedrich Volkmann: Man kann leicht schimpfen, wenn man die Arbeit nicht selber macht. In NÖ sind z.B. die L6xxx noch nicht komplett, wär das eine Aufgabe für dich? Ich habe mir jetzt gerade die L233 im Burgenland angesehen und kann überhaupt nicht verstehen, warum Du in den ref-Tags die L*-Nummern erfasst. Laut Wiki http://wiki.openstreetmap.org/wiki/DE:Relation:route gehören diese Infos einwandfrei in Relations erfasst, eben vom Type route und haben eben an den Straßen selber nichts verloren! Das selbe an der L 332 usw. usw. Meiner Meinung nach ist das Wiki da eindeutig. Grüße Erwin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Also ich setze refs auch überall! Auch wenn ich so übergeordnete Dinge lieber nur in der Relation hätte! Am 6. Januar 2013 12:57 schrieb Friedrich Volkmann b...@volki.at: On 06.01.2013 11:59, Erwin OSM wrote: Ich habe mir jetzt gerade die L233 im Burgenland angesehen und kann überhaupt nicht verstehen, warum Du in den ref-Tags die L*-Nummern erfasst. Laut Wiki http://wiki.openstreetmap.org/**wiki/DE:Relation:routehttp://wiki.openstreetmap.org/wiki/DE:Relation:route gehören diese Infos einwandfrei in Relations erfasst, eben vom Type route und haben eben an den Straßen selber nichts verloren! Das selbe an der L 332 usw. usw. Meiner Meinung nach ist das Wiki da eindeutig. Wo steht im Wiki, dass ref nicht auf Ways gesetzt werden sollen? Ich kenne keine einzige Straße, wo ref *nur* auf der road-Relation erfasst ist. Dann würde es in den meisten Karten (z.B. Mapnik) gar nicht angezeigt werden, und Nominatim fände es auch nicht. Mir wär es auch lieber, jedes ref nur 1x auf eine Relation zu setzen statt auf hunderttausend Ways. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria __**_ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-athttp://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 13:25, schrieb Soldier Boy: Also ich setze refs auch überall! Auch wenn ich so übergeordnete Dinge lieber nur in der Relation hätte! Mach ich ja im Grunde auch, zusätzlich, denn nur dann werden sie auf Karten dargestellt, aber genau das nennt man doch Mapping für Renderer und das möchten wir doch eigentlich nicht betrieben, oder? ;-) ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 12:57, schrieb Friedrich Volkmann: On 06.01.2013 11:59, Erwin OSM wrote: Ich habe mir jetzt gerade die L233 im Burgenland angesehen und kann überhaupt nicht verstehen, warum Du in den ref-Tags die L*-Nummern erfasst. Laut Wiki http://wiki.openstreetmap.org/wiki/DE:Relation:route gehören diese Infos einwandfrei in Relations erfasst, eben vom Type route und haben eben an den Straßen selber nichts verloren! Das selbe an der L 332 usw. usw. Meiner Meinung nach ist das Wiki da eindeutig. Wo steht im Wiki, dass ref nicht auf Ways gesetzt werden sollen? Ich kenne keine einzige Straße, wo ref *nur* auf der road-Relation erfasst ist. Dann würde es in den meisten Karten (z.B. Mapnik) gar nicht angezeigt werden, und Nominatim fände es auch nicht. Mir wär es auch lieber, jedes ref nur 1x auf eine Relation zu setzen statt auf hunderttausend Ways. Ich habe mittlerweilen das Gefühl, ich bin der letzte, der noch mit Dir diskutiert, scheinbar haben es alle anderen aufgegeben. Es steht auch nicht im Wiki, das MaxSpeed nicht auf Standardstraßen gesetzt werden soll, ganz im Gegenteil, guckst Du hier: http://wiki.openstreetmap.org/wiki/WikiProject_Austria/Schnellstra%C3%9Fen Für mich wird das auch die letzte Meldung zu diesem Thema sein, denn ich kann mich des Eindrucks nicht erwehren, dass Du nicht die Diskussion oder den Konsens suchst, sondern auf Teufel komm raus Dein Tagging-Schema allen anderen aufzwingen willst, und sei es durch das Löschen von Eigenschaften anderer. Ich halte das Löschen für unverschämt! Wünsche allen die hier noch mitlesen einen schönen Sonntag, man sieht sich im nächsten Beitrag vielleicht wieder, Erwin ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
On Sun, 06 Jan 2013 15:18:38 +0100 Erwin OSM erwin@gmx.at wrote: Ich habe mittlerweilen das Gefühl, ich bin der letzte, der noch mit Dir diskutiert, scheinbar haben es alle anderen aufgegeben. gibt auch welche, die ihm einfach großteils zustimmen und nix posten, bis sie indirekt aufgefordert werden. ;) redundante tags sind auf lange zeit äußerst kontraproduktiv, wenn ihr zweck nicht eindeutig erkennbar ist (ggfs ein source oder sonstiger tag dabei steht), weil man sie nicht von echten einträgen (automatisch) unterscheiden kann. insofern ist das löschen dieser redundanten information nicht unverschämt sondern eine verbesserung der daten IMHO (und ich halte das bei vergleichbaren sachen ähnlich). allerdings gibt es ganz offensichtlich unterschiedliche meinungen zu dem thema und ein wirrwarr an taggingschemen (oder gar gegenseitige kampfedits und anfeindungen) sind noch viel schlechter für die datenqualität als redundanz. im sinne dessen wäre es sehr gut, wenn man sich auf ein schema einigen könnte, das eine unterscheidung zwischen defaults und der realen beschilderung ermöglicht. geht das? :) konkrete vorschläge kann ich zu dem thema leider keine machen, da ich mich zu wenig mit den maxspeed tags beschäftigt habe. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 16:14, schrieb Stefan Tauner: On Sun, 06 Jan 2013 15:18:38 +0100 Erwin OSM erwin@gmx.at wrote: Ich habe mittlerweilen das Gefühl, ich bin der letzte, der noch mit Dir diskutiert, scheinbar haben es alle anderen aufgegeben. gibt auch welche, die ihm einfach großteils zustimmen und nix posten, bis sie indirekt aufgefordert werden. ;) Dazu gehöre ich mal vorweg nicht. redundante tags sind auf lange zeit äußerst kontraproduktiv, wenn ihr zweck nicht eindeutig erkennbar ist (ggfs ein source oder sonstiger tag dabei steht), weil man sie nicht von echten einträgen (automatisch) unterscheiden kann. insofern ist das löschen dieser redundanten information nicht unverschämt sondern eine verbesserung der daten IMHO (und ich halte das bei vergleichbaren sachen ähnlich). Wenn er meine Daten gelöscht hätte, dann wäre ich ordentlich angepisst. Ist aber zum Glück nicht der Fall. Ich lese zwar doch das Meiste in Forum und ML, aber dass die 100 Überland nicht eingetragen werden ist mir gänzlich neu, somit habe ich es auch bis jetzt getan. (Weiß noch nicht wie ich weiter verfahre) Ich versuche mich kurz zu fassen: -) Daten von anderen Löschen, weil sie mal Probleme machen KÖNNTEN? Wäre es da nicht sinnvoller die Daten mit einem fixme zu versehen und falls das Wunder geschieht und in Österreich die vmax tatsächlich auf 80 oder 90 gesenkt wird, dann überlegen wie mit den Daten weiter verfahren wird? Oder falls es aufgrund der Redundanz wirklich mal Probleme gibt, könnte ein bot losgelassen werden. -) In Österreich inkludiert 100 auf der Bundesstraße automatische maxspeed:source=rural, denn es ist keine Beschilderung mit 100 km/h auf Bundesstraßen vorgesehen. Den Fall in Wulkaprodersdorf kenne ich nicht, aber ich habe Zweifel, dass die Schilder auf einer Bundesstraße stehen. (In OSM gibt es in der Nähe kein maxspeed=100) -) Ich finde das Eintragen von maxspeed=50 + source:maxspeed=rural aufgrund von Satellitenbilder viel Gefährlicher als irgendwelche Redundanzen! Es erweckt den Eindruck, dass die Straßen schon ordentlich getagged wurden, dabei wurde nur geschätzt. (Ich kann von einem Luftbild innerhalb der Ortsgebiete in meiner Umgebung nicht erkennen, ob dort 30 oder 70 erlaubt sind, was es hier alles gibt). Das ist vortäuschen von Daten, mit welcher Motivation auch immer... -) Was für mich aktuell FÜR ein maxspeed=100 spricht ist, dass wenn Router auf Strecken ohne maxspeed von zulässigen 100 km/h ausgehen, kommt es in manchen Gebieten zu gigantischen Berechnungsfehler, wenn es nur Ortsgebiet wäre. Falls die 100 weiter eingetragen werden, könnte der Router bei nicht mit einem maxspeed versehenen Straßen von 60-70 km/h ausgehen und das Ergebnis wäre trotzdem halbwegs passend. (Sehe ich nicht als Taggen für den Router/Render/etc., da ich ja keine Tags verbiege, damit etwas wo besser aussieht, funktioniert, etc.) LG Jimmy ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
On Sun, 06 Jan 2013 17:02:18 +0100 Jimmy_K jimm...@gmx.at wrote: Am 06.01.2013 16:14, schrieb Stefan Tauner: redundante tags sind auf lange zeit äußerst kontraproduktiv, wenn ihr zweck nicht eindeutig erkennbar ist (ggfs ein source oder sonstiger tag dabei steht), weil man sie nicht von echten einträgen (automatisch) unterscheiden kann. insofern ist das löschen dieser redundanten information nicht unverschämt sondern eine verbesserung der daten IMHO (und ich halte das bei vergleichbaren sachen ähnlich). Wenn er meine Daten gelöscht hätte, dann wäre ich ordentlich angepisst. Ist aber zum Glück nicht der Fall. Ich lese zwar doch das Meiste in Forum und ML, aber dass die 100 Überland nicht eingetragen werden ist mir gänzlich neu, somit habe ich es auch bis jetzt getan. (Weiß noch nicht wie ich weiter verfahre) es gibt keine daten anderer. das sind alles unsere daten. wir sind alle für sie verantwortlich und sie gehen uns auch alle etwas an. das ist die grundlage der lizenz und der große vorteil wie auch ein großes konfliktpotential (offensichtlich :) daß sich mapper mit den von ihnen eingetragenen daten identifizieren, ist zwar menschlich und eine enorme motivation zum mappen, aber verdrängt auch oft den teilenden, sozialen aspekt des projekts. das muß man sich immer wieder vor augen führen bei solchen diskussionen, mir gehts da nicht anders. Ich versuche mich kurz zu fassen: -) Daten von anderen Löschen, weil sie mal Probleme machen KÖNNTEN? Wäre es da nicht sinnvoller die Daten mit einem fixme zu versehen und falls das Wunder geschieht und in Österreich die vmax tatsächlich auf 80 oder 90 gesenkt wird, dann überlegen wie mit den Daten weiter verfahren wird? Oder falls es aufgrund der Redundanz wirklich mal Probleme gibt, könnte ein bot losgelassen werden. das ist ja genau der (mein) punkt: eindeutig machen von wirklicher beschilderung und impliziter regelung. ich habe keine ahnung, ob es in wirklichkeit redundante beschilderung gibt (sprich ob irgendwo 100er schilder stehen, obwohl das sowieso klar ist... hab keinen führerschein ;), aber es würde mich nicht wundern. selbst wenn das nicht so ist, besteht das problem, daß man sofort bei einer änderung einen bot am start haben muß, da ansonsten mapper anfangen die neuen gegebenheiten zu mappen und man dann wieder nicht weiß, was gemeint ist/war... […] -) Ich finde das Eintragen von maxspeed=50 + source:maxspeed=rural aufgrund von Satellitenbilder viel Gefährlicher als irgendwelche Redundanzen! Es erweckt den Eindruck, dass die Straßen schon ordentlich getagged wurden, dabei wurde nur geschätzt. (Ich kann von einem Luftbild innerhalb der Ortsgebiete in meiner Umgebung nicht erkennen, ob dort 30 oder 70 erlaubt sind, was es hier alles gibt). Das ist vortäuschen von Daten, mit welcher Motivation auch immer... da sind wir uns einig, war aber mWn nicht thema dieses threads. -) Was für mich aktuell FÜR ein maxspeed=100 spricht ist, dass wenn Router auf Strecken ohne maxspeed von zulässigen 100 km/h ausgehen, kommt es in manchen Gebieten zu gigantischen Berechnungsfehler, wenn es nur Ortsgebiet wäre. Falls die 100 weiter eingetragen werden, könnte der Router bei nicht mit einem maxspeed versehenen Straßen von 60-70 km/h ausgehen und das Ergebnis wäre trotzdem halbwegs passend. (Sehe ich nicht als Taggen für den Router/Render/etc., da ich ja keine Tags verbiege, damit etwas wo besser aussieht, funktioniert, etc.) man muß das maxspeed ja nicht zwingend entfernen, solange es stimmt. man könnte einen zusätzlichen tag adden, damit es eindeutig wird, daß es nicht explizit ausgeschildert ist (source:maxspeed bietet sich an, aber im grunde ist es vollkommen wuarscht, solange es sicher durchsetzt :) ps: wieso verwenden wir das place eigentlich dermaßen anders, als alle anderen? -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
On 06.01.2013 17:02, Jimmy_K wrote: Wenn er meine Daten gelöscht hätte, dann wäre ich ordentlich angepisst. Nicht bös sein, aber maxspeed=100 auf Freilandstraßen ist keine große schöpferische Leistung. Die kann ein Bot genauso setzen. Da müsstest du noch viel angepisster sein, wenn dir jemand Nodes verschiebt, weil er von einem anderen Orthofoto abzeichnet. Was glaubst du, wie oft meine Daten verhunzt oder gelöscht werden. Darunter z.B. Berggipfel und Höhlen, wo ich extra hunderte km gefahren bin und mich stundenlang durchs Dickicht geschlagen habe um sie einzumessen. Ich schreibe dann meistens die Verhunzer an. Umgekehrt hat mich noch nie wer angeschrieben, dass ich seine Daten verhunzt hätte. Das kommt nämlich nicht oft vor. Auch die 100er-Löschungen sind eine Ausnahme. Allein schon deshalb, weil im von mir bearbeiteten Gebiet wenige 100er gesetzt waren. D.h. auch wenn einige behaupten, dass es Konsens sei, überall maxspeed=100 zu setzen (warum auch immer), spricht der Datenbestand doch eine andere Sprache. Zumindest im Bgld war und ist auf mindestens 99% der Freilandstraßen eben kein maxspeed=100 gesetzt. -) Daten von anderen Löschen, weil sie mal Probleme machen KÖNNTEN? Wäre es da nicht sinnvoller die Daten mit einem fixme zu versehen und falls das Wunder geschieht und in Österreich die vmax tatsächlich auf 80 oder 90 gesenkt wird, dann überlegen wie mit den Daten weiter verfahren wird? fixme zu setzen ist nicht viell was anderes als die Daten gleich zu ändern. Denn fixme heißt, da ist was falsch und gehört geändert, oder zumindest mit einer hohen Wahrscheinlichkeit. Ein fixme ist also nur ein Ändern auf Raten. Oder falls es aufgrund der Redundanz wirklich mal Probleme gibt, könnte ein bot losgelassen werden. Ohne source:maxspeed weiß ein Bot nicht, welche maxspeed=100 echt sind. -) In Österreich inkludiert 100 auf der Bundesstraße automatische maxspeed:source=rural, denn es ist keine Beschilderung mit 100 km/h auf Bundesstraßen vorgesehen. Den Fall in Wulkaprodersdorf kenne ich nicht, aber ich habe Zweifel, dass die Schilder auf einer Bundesstraße stehen. (In OSM gibt es in der Nähe kein maxspeed=100) Kann sein, dass es nicht getaggt ist. Der 100er steht dort, weil die Autobahn fugenlos in eine Autostraße übergeht und sich die Leute erst runterbremsen, wenn sie mehrmals den 100er vor die Nase gehalten bekommen. -) Ich finde das Eintragen von maxspeed=50 + source:maxspeed=rural aufgrund von Satellitenbilder viel Gefährlicher als irgendwelche Redundanzen! Es erweckt den Eindruck, dass die Straßen schon ordentlich getagged wurden, dabei wurde nur geschätzt. (Ich kann von einem Luftbild innerhalb der Ortsgebiete in meiner Umgebung nicht erkennen, ob dort 30 oder 70 erlaubt sind, was es hier alles gibt). Das ist vortäuschen von Daten, mit welcher Motivation auch immer... Hundertprozentige Genauigkeit werden wir nie haben, es ist alles nur eine Annäherung. Man kann nicht ein Gebiet so fertig mappen, so dass es nie wieder wer anschauen muss. Vor 2 Jahren habe ich mühsam halb Favoriten gemappt, das ist inzwischen alles für die Würschte, weil es jetzt die viel genaueren wien.at-Daten gibt, und die Hälfte der Geschäftslokale haben die Besitzer gewechselt. Genauso ist es mit den maxspeed. Die vom Luftbild geratenen maxspeed sind eine Annäherung. Wenn ein Mapper vorbeikommt, macht er eine bessere Annäherung. Der nächste macht es noch genauer. Vielleicht gibt es mal OGD-Daten, dann geht es noch genauer. Und wenn jemand die Tafeln mit Theodolit eingemessen hat, ist es immer noch keine Garantie, dass alles stimmt, denn vielleicht wurden schon am nächsten Tag andere Tafeln aufgestellt. Geodaten aktuell zu halten und zu verbessern, ist kein Projekt, sondern ein Prozess. Aber ich geb dir schon recht, aus den Tags maxspeed=50 + source:maxspeed=AT:urban geht nicht hervor, dass sie nur von Luftbildern her geschätzt sind. Ich würde maxspeed=AT:urban + source:maxspeed=survey/Bing/geoimage.at/OGD/... besser finden. Doch diese Tagging-Variante ist in AT leider nicht üblich. -) Was für mich aktuell FÜR ein maxspeed=100 spricht ist, dass wenn Router auf Strecken ohne maxspeed von zulässigen 100 km/h ausgehen, kommt es in manchen Gebieten zu gigantischen Berechnungsfehler, wenn es nur Ortsgebiet wäre. Drum werden auf highway=tertiary oder höher die maxspeed im Ortsgebiet explizit gesetzt. Falls die 100 weiter eingetragen werden, könnte der Router bei nicht mit einem maxspeed versehenen Straßen von 60-70 km/h ausgehen und das Ergebnis wäre trotzdem halbwegs passend. (Sehe ich nicht als Taggen für den Router/Render/etc., da ich ja keine Tags verbiege, damit etwas wo besser aussieht, funktioniert, etc.) Das ist für die Länder, wo der Erfassungsgrad noch gering ist, sicher eine Möglichkeit. Aber letztlich ist das eine Entscheidung der Entwickler. Unsere Aufgabe ist es, die Daten so bereitzustellen, dass man was draus machen kann. Und da ist eine klare
Re: [Talk-at] burgenländische Landesstraßen
Hallo! Am Sonntag, 06. Januar 2013 21:37 CET, Friedrich Volkmann b...@volki.at schrieb: On 06.01.2013 17:02, Jimmy_K wrote: Wenn er meine Daten gelöscht hätte, dann wäre ich ordentlich angepisst. Nicht bös sein, aber maxspeed=100 auf Freilandstraßen ist keine große schöpferische Leistung. Die kann ein Bot genauso setzen. Da müsstest du noch viel angepisster sein, wenn dir jemand Nodes verschiebt, weil er von einem anderen Orthofoto abzeichnet. Für mich ist es ein Zeichen, dass sich da jemand sicher ist, dass da bestimmt 100 km/h sind, und nicht irgendetwas wie 50 oder 70. Ich glaube nicht, dass da irgendein Bot am Werk gewesen ist. Ich glaube eher, dass das souce:maxspeed=AT:rural einfach nicht als wichtig erachtet oder vergessen worden ist. Alternative zum Löschen des Tags: momentan gilt noch 100 km/h in Fällen wo Geschwindigkeits-Begrenzung Ende als Schild steht. Was spricht dagegen, JETZT bei einem explizit getaggten 100 (in den meisten Fällen) ein source:maxspeed dazu zu geben, statt das maxspeed-Tag zu löschen? (nicht über einen Bot sondern nach Abschätzung im Einzelfall) Was glaubst du, wie oft meine Daten verhunzt oder gelöscht werden. Darunter z.B. Berggipfel und Höhlen, wo ich extra hunderte km gefahren bin und mich stundenlang durchs Dickicht geschlagen habe um sie einzumessen. Ja, das ist dann in diesen Fällen auch nicht optimal gelaufen. Ich schreibe dann meistens die Verhunzer an. Umgekehrt hat mich noch nie wer angeschrieben, dass ich seine Daten verhunzt hätte. Das kommt nämlich nicht oft vor. Auch die 100er-Löschungen sind eine Ausnahme. Allein schon deshalb, weil im von mir bearbeiteten Gebiet wenige 100er gesetzt waren. D.h. auch wenn einige behaupten, dass es Konsens sei, überall maxspeed=100 zu setzen (warum auch immer), spricht der Datenbestand doch eine andere Sprache. Zumindest im Bgld war und ist auf mindestens 99% der Freilandstraßen eben kein maxspeed=100 gesetzt. Wenn ich etwas in der Datenbank dazu füge, dann gehe ich prinzipiell davon aus, dass die Daten von mir nur bessert und nicht verschlechtert werden. Darum kontrolliere ich einmal getaggtes in den seltensten Fällen später nochmals. Ich gehe davon aus, dass es den Leuten, die 100 ergänzt haben es noch gar nicht aufgefallen ist, dass du da am Löschen bist. Hast du die Leute mal angeschrieben und gefragt, woher das 100 in den einzelnen Fällen kommt? Genauso ist es mit den maxspeed. Die vom Luftbild geratenen maxspeed sind eine Annäherung. Wenn ein Mapper vorbeikommt, macht er eine bessere Annäherung. Der nächste macht es noch genauer. ... ich glaube nicht, dass maxspeed von Luftbildern übernommen worden ist (ich hab das auf jeden Fall noch nie gemacht). Und wenn es 50 m oder 100 m zu ungenau ist, ist es doch besser als nichts. Aber deswegen die Ungenauigkeit erhöhen und die 100 km/h komplett zu entfernen halte ich für den falschen Weg. Melde dich bitte, falls du zukünftig solche Aktionen für Oberösterreich planst. -) Was für mich aktuell FÜR ein maxspeed=100 spricht ist, dass wenn Router auf Strecken ohne maxspeed von zulässigen 100 km/h ausgehen, kommt es in manchen Gebieten zu gigantischen Berechnungsfehler, wenn es nur Ortsgebiet wäre. Drum werden auf highway=tertiary oder höher die maxspeed im Ortsgebiet explizit gesetzt. und wenn's einfach noch nicht gesetzt worden ist? Hab mir ein paar Bundesstraßen in OÖ angesehen (z.B. B138 südlich von Sattledt), da fehlt's noch zu großen Teilen. Falls die 100 weiter eingetragen werden, könnte der Router bei nicht mit einem maxspeed versehenen Straßen von 60-70 km/h ausgehen und das Ergebnis wäre trotzdem halbwegs passend. (Sehe ich nicht als Taggen für den Router/Render/etc., da ich ja keine Tags verbiege, damit etwas wo besser aussieht, funktioniert, etc.) Das ist für die Länder, wo der Erfassungsgrad noch gering ist, sicher eine Möglichkeit. Aber letztlich ist das eine Entscheidung der Entwickler. Unsere Aufgabe ist es, die Daten so bereitzustellen, dass man was draus machen kann. Und da ist eine klare Definition Default ist 100 auf alle Fälle nutzbarer als so eine Wischiwaschi-Definition mit inside/outside place. Der Erfassungsgrad für maxspeed ist auch in Österreich noch lange nicht komplett (siehe oben). Ich halte es für eine gute Methode, dem Router mit expliziten 100 etwas zu helfen, um nicht auf eine geschätzte Durchschnittsgeschwindigkeit von 60-70 o.ä. zu kommen. Das sehe ich noch NICHT als Mappen für den Router. Wie möchtest du sonst den Unterschied zwischen noch nicht erfasst und default dem Router bekanntgeben? Gruß Günther ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
On 06.01.2013 22:20, Günther Zin. wrote: Für mich ist es ein Zeichen, dass sich da jemand sicher ist, dass da bestimmt 100 km/h sind, und nicht irgendetwas wie 50 oder 70. Das wird in den meisten Fällen so sein, aber es gibt auch genug andere, darum kann ein expliziter 100er genauso richtig oder falsch sein wie ein impliziter. Wie gewissenhaft jemand gearbeitet hat, weiß leider immer nur er selber. Ich glaube nicht, dass da irgendein Bot am Werk gewesen ist. Ich glaube eher, dass das souce:maxspeed=AT:rural einfach nicht als wichtig erachtet oder vergessen worden ist. Das ist ziemlich offensichtlich. Mit dem Bot meinte ich, dass der das genauso gut könnte. Die Leistung ist es, die Ausnahmen (maxspeed!=100) zu finden, nicht die Normalfälle. Alternative zum Löschen des Tags: momentan gilt noch 100 km/h in Fällen wo Geschwindigkeits-Begrenzung Ende als Schild steht. Was spricht dagegen, JETZT bei einem explizit getaggten 100 (in den meisten Fällen) ein source:maxspeed dazu zu geben, statt das maxspeed-Tag zu löschen? (nicht über einen Bot sondern nach Abschätzung im Einzelfall) Wenn ich gewusst hätte, was das Thema hier für Emotionen auslöst, hätte ich das eh von Anfang an gemacht. Der Aufwand, ein Tag hinzuzufügen, ist nicht viel größer als eines zu löschen. Es wird halt nur unübersichtlich, wenn auf jedem Objekt 20 Tags sind, von denen nur 3 signifikant sind. Das betrifft z.B. auch die häufig von Neuligen mit Potlatch auf jede Straße gesetzten Tags layer=0, access=yes, foot=yes, oneway=no... Sind die alle erhaltenswert? und wenn's einfach noch nicht gesetzt worden ist? Hab mir ein paar Bundesstraßen in OÖ angesehen (z.B. B138 südlich von Sattledt), da fehlt's noch zu großen Teilen. Sicher nicht mehr lange, wenn man sich die Entwicklung der letzten Jahre anschaut. Außerdem haben wir mit den Herstellern von Routingapplikationen keinen Vertrag, dass die Daten bis zum Stichtag X fertig sein müssen. Die kriegen, was da ist, und ich denke, das ist schon gut genug. Bei Sattledt stimmt die ermittelte Zeit noch nicht ganz, man wird es überleben. Wie möchtest du sonst den Unterschied zwischen noch nicht erfasst und default dem Router bekanntgeben? Der Router soll beides wie Default behandeln. Das ist ja der Clou von einem Default. -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am Mo. 07. Jan. 2013 01:11 CET, Friedrich Volkmann b...@volki.at schrieb: On 06.01.2013 22:20, Günther Zin. wrote: Für mich ist es ein Zeichen, dass sich da jemand sicher ist, dass da bestimmt 100 km/h sind, und nicht irgendetwas wie 50 oder 70. Das wird in den meisten Fällen so sein, aber es gibt auch genug andere, darum kann ein expliziter 100er genauso richtig oder falsch sein wie ein impliziter. Wie gewissenhaft jemand gearbeitet hat, weiß leider immer nur er selber. Das ist genau der Punkt: ich gehe prinzipiell davon aus, dass eine Information die vorhanden ist richtig ist oder in absehbarer Zeit richtig gestellt wird. Ich glaube nicht, dass da irgendein Bot am Werk gewesen ist. Ich glaube eher, dass das souce:maxspeed=AT:rural einfach nicht als wichtig erachtet oder vergessen worden ist. Das ist ziemlich offensichtlich. Mit dem Bot meinte ich, dass der das genauso gut könnte. Die Leistung ist es, die Ausnahmen (maxspeed!=100) zu finden, nicht die Normalfälle. Ist ein Bot da lang gefahren und hat die Geschwindigkeiten notiert und dann eingetragen? Für mich ist das genau der Unterschied! Alternative zum Löschen des Tags: momentan gilt noch 100 km/h in Fällen wo Geschwindigkeits-Begrenzung Ende als Schild steht. Was spricht dagegen, JETZT bei einem explizit getaggten 100 (in den meisten Fällen) ein source:maxspeed dazu zu geben, statt das maxspeed-Tag zu löschen? (nicht über einen Bot sondern nach Abschätzung im Einzelfall) Wenn ich gewusst hätte, was das Thema hier für Emotionen auslöst, hätte ich das eh von Anfang an gemacht. Der Aufwand, ein Tag hinzuzufügen, ist nicht viel größer als eines zu löschen. Es wird halt nur unübersichtlich, wenn auf jedem Objekt 20 Tags sind, von denen nur 3 signifikant sind. Geschwindigkeits-Grenzen sind für mich (und viele andere) relevant. Wie sollen wir je wissen ob es vollständig ist, wenn das vorhandene stellenweise wieder gelöscht wird? Sobald Maxspeed's mal zuverlässig flächendeckend erfasst sind, sieht's vielleicht anders aus. Dann können wir ja nochmals drüber reden ;-) . Das betrifft z.B. auch die häufig von Neuligen mit Potlatch auf jede Straße gesetzten Tags layer=0, access=yes, foot=yes, oneway=no... Sind die alle erhaltenswert? Das ist wieder etwas anderes, das fällt auch auf. Außerdem haben wir mit den Herstellern von Routingapplikationen keinen Vertrag, dass die Daten bis zum Stichtag X fertig sein müssen. Die kriegen, was da ist, und ich denke, das ist schon gut genug. Bei Sattledt stimmt die ermittelte Zeit noch nicht ganz, man wird es überleben. Sattledt war nur ein Beispiel. Ich habe das nicht punktuell gemeint, sondern die Strecke zwischen Sattledt und Liezen. Vertrag haben wir keinen, das stimmt. Nur nutzen möchte ich die Daten in Routing-Applikationen (ich persönlich gerne Navit) schon gerne vollständig und richtig. Eine Richtigstellung der Daten und ein Neuimport in die Routing-Applikation macht sich in zuverlässigeren Routenberechnungen schneller bemerkbar (z.B.: soll ich den längeren Weg über die Autobahn nehmen oder bin ich auf der Bundesstraße genau so schnell?) Ich bin halt nicht nur Mapper sondern auch Anwender. Die Daten sollen bei mir nicht nur einen Selbstzweck erfüllen. :-) Wie möchtest du sonst den Unterschied zwischen noch nicht erfasst und default dem Router bekanntgeben? Der Router soll beides wie Default behandeln. Das ist ja der Clou von einem Default. Default heißt momentan für mich: wurde noch nicht erfasst, nehme mal 60-80 km/h als Freilandstraßen-Durchschnitt für die Zeit-Berechnung an. Gruß, Günther ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] burgenländische Landesstraßen
Am 06.01.2013 21:37, schrieb Friedrich Volkmann: D.h. auch wenn einige behaupten, dass es Konsens sei, überall maxspeed=100 zu setzen (warum auch immer), spricht der Datenbestand doch eine andere Sprache. Zumindest im Bgld war und ist auf mindestens 99% der Freilandstraßen eben kein maxspeed=100 gesetzt. Mag beschränkt auf Burgenland stimmen, wenn ich aber auf den mitteleuropäischen Datenbestand schaue (http://www.itoworld.com/map/124#fullscreenlat=50.163253932962lon=12.776602952164607zoom=6) gibt es da verdammt viel hellblau (91 - 109 km/h). LG Jimmy ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-lv] robezhas city/town
terplāni? adrešu reģistrs kā zināms nav par velti On Sun, Jan 6, 2013 at 5:02 PM, Rich ric...@nakts.net wrote: man oklums iebakstiija ar shaadu te listi : http://peirce.gis-lab.info/qa/**LV-FULL#citynoborderhttp://peirce.gis-lab.info/qa/LV-FULL#citynoborder vai mums ir no kurienes shaadas truukstoshaas robezhas skaisti salikt ? -- Rich __**_ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-lvhttp://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
[Talk-ca] Traduire Upper Lorne Place
Comment traduire le nom de rue Upper Lorne Place? Il s'agit d'une rue normal, pas une place comme la place des Vosges. Merci, Tom Taylor ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] Podklad Bing v Praze
Dne 5.1.2013 14:45, Petr Dlouhý napsal(a): Ahoj, nedá se ne(jak ovlivnit chování ortofotomapy Bingu v Praze? Ted( se to chová tak, z(e pr(i niz(s(ím pr(iblíz(ení je vide(t nove(js(í, ale mnohem méne( kvalitní podklad (niz(s(í rozlis(ení, hors(í zame(r(ení, mraky) a pr(i vys(s(ím pr(iblíz(ení ta stars(í, podrobne(js(í a celkove( leps(í. Tohle chování mi docela komplikuje práci, protoz(e na 90% pr(ípadu* vyuz(ívám ten stars(í a musím pak kvu*li velkému pr(iblíz(ení hodne( posouvat s mapou. Rád bych si mapu bud( vybral, nebo alespon( o kus posunul hranici pr(i které se pr(epne. Máte ne(jaké tipy? Jop, pouzij misto toho orthofoto cuzk. Ona je sice na max priblizeni rozmazana (coz nevim proc), ale aspon odpovida katastralce (neni posunuta). S aktualnosti je to ... ruzne na ruznych mistech, nekde je vyrazne novejsi, nekde vyrazne starsi. -- Petr Dlouhý petr.dlo...@email.cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podklad Bing v Praze
Ahoj, j ml za to, e Ortofoto ZK nem vyjasnn licenn podmnky a nesm se pro mapovn pouvat - alespo podle Wiki a tto diskuse - je to jinak? Vojta http://wiki.openstreetmap.org/wiki/WikiProject_Czechia/free_map2osm#WMS_.C4.8C.C3.9AZK_-_ortofotomapa Dne 6.1.2013 13:36, jzvc napsal(a): Jop, pouzij misto toho orthofoto cuzk. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podklad Bing v Praze
Dne 6.1.2013 13:48, Vojta napsal(a): Ahoj, já me(l za to, z(e Ortofoto C(ÚZK nemá vyjasne(né licenc(ní podmínky a nesmí se pro mapování pouz(ívat - alespon( podle Wiki a této diskuse - je to jinak? Vojta http://wiki.openstreetmap.org/wiki/WikiProject_Czechia/free_map2osm#WMS_.C4.8C.C3.9AZK_-_ortofotomapa Mineno samo jako kontrolni vrstva, mapujes podle KM ... jinak ta orthofoto je by default dostupna pro nekomercni ucely(maj to napsany na webu), predpokladam ze komercne ji nevyuzivas = z myho pohledu i pro mapovani OK. Vubec nemluve o tom, ze jde (pokud vim) o uredni dilo (vyrobeno z nasich dani). Dne 6.1.2013 13:36, jzvc napsal(a): Jop, pouzij misto toho orthofoto cuzk. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Podklad Bing v Praze
... jinak ta orthofoto je by default dostupna pro nekomercni ucely(maj to napsany na webu), predpokladam ze komercne ji nevyuzivas = z myho pohledu i pro mapovani OK. Vubec nemluve o tom, ze jde (pokud vim) o uredni dilo (vyrobeno z nasich dani). *** az zase vymyslis nejakou podobnou blbost, udelej primo amnestii, ale nepis nam o tom do konference... hanoj ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
2013/1/5 fo...@letuffe.org: grade1 : piste goudronné Attention, ça, c'est un mauvais raccourci. piste goudronnée veut bien dire grade1 mais grade1 ne veut pas dire piste goudronnée. Le chemin peut aussi être composé de matériaux très compactés (heavily compacted hardcore). Seul l'ajout d'un tag surface=* peut clarifier ce point. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Comment retrouver des tags sur une zone ?
Le message suivant de : ## Bonjour, Je viens de lire la doc concernant les ponts et tunnel et j'ai fait quelques mauvaises utilisations de ce tag. Comment puis je trouver l'utilisation d'un ou plusieurs tag sur une zone en particulier ? Dans mon cas je rechercherai les informations [b]tunnel, bridge et covered[/b] dans la zone http://www.openstreetmap.org/?lat=43.2lon=2.977zoom=11layers=M a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=2 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
Oui j'ai bien fait la différence. Il existe les routes mineure goudronnée et les pistes goudronnée (grade1). J'ai donc appliqué les grade 1 pour les voies étroite (2 mètres de large maxi) ou construite pour joindre une zone comportant d'autres piste. Elles sont généralement goudronnée pour résister à l'érosion les jours de forte pluie. J'ai utilisé des routes mineures quand elles permettent de circuler à plus de 50 km/h et/ou débouchant sur d'autre voie goudronnnée Le 6 janvier 2013 12:30, Pieren pier...@gmail.com a écrit : 2013/1/5 fo...@letuffe.org: grade1 : piste goudronné Attention, ça, c'est un mauvais raccourci. piste goudronnée veut bien dire grade1 mais grade1 ne veut pas dire piste goudronnée. Le chemin peut aussi être composé de matériaux très compactés (heavily compacted hardcore). Seul l'ajout d'un tag surface=* peut clarifier ce point. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-SN - question technique
2013/1/5 Seydou Badiane seydoubadi...@gmail.com: Salut et bienvenue sur talk-fr, J'aimerai savoir comment taguer un espace public dédié aux jeunes comprenant - espace de formation - activités culturelles (soirées dansantes; ateliers artistiques...) - ressources culturelles (bibliothèque de livres; documents de formation...) - ressources numériques Je pense que ce qui s'en rapproche le plus, c'est ce qu'on appelle en France les MJC, les Maisons des Jeunes et de la Culture. On en a discuté sur cette liste en septembre 2012: http://gis.19327.n5.nabble.com/Comment-tagguer-les-MJC-td5723617.html Une piste semble être le tag amenity=youth_centre mais ça n'est pas vraiment documenté dans le wiki: http://taginfo.openstreetmap.org/tags/amenity=youth_centre Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Donc, YouMap, uMap, maCarte, maMap, monOsm, Maposmme aka MapOsmMe...
Salut, C'est vraiment sympa! Je pense que ça serait bien de rajouter un champ de recherche pour pouvoir centrer la carte facilement sur un petit bled sans galérer à zoomer un peu au petit bonheur la chance entre les 2 grandes villes d'a coté qui apparaissent à des petits niveau de zoom :-) Bon boulot! Antoine ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM-SN - question technique
Merci @Pieren. Le 6 janvier 2013 11:44, Pieren pier...@gmail.com a écrit : 2013/1/5 Seydou Badiane seydoubadi...@gmail.com: Salut et bienvenue sur talk-fr, J'aimerai savoir comment taguer un espace public dédié aux jeunes comprenant - espace de formation - activités culturelles (soirées dansantes; ateliers artistiques...) - ressources culturelles (bibliothèque de livres; documents de formation...) - ressources numériques Je pense que ce qui s'en rapproche le plus, c'est ce qu'on appelle en France les MJC, les Maisons des Jeunes et de la Culture. On en a discuté sur cette liste en septembre 2012: http://gis.19327.n5.nabble.com/Comment-tagguer-les-MJC-td5723617.html Une piste semble être le tag amenity=youth_centre mais ça n'est pas vraiment documenté dans le wiki: http://taginfo.openstreetmap.org/tags/amenity=youth_centre Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Seydou Badiane ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Tagguer les dépendances et emprises routières
Bonjour à tous, Dans un topic précédent (Niveau de Landuse), on discutait des limites de landuse entre les voies et les champs, prairies, forêts ... Appliquée à une commune sur laquelle j'ai pas mal contribué (Aubers dans le nord) Sachant que généralement les emprises routières comprennent aussi des espaces engazonnés, paysagers, en friche... spécifiez vous aussi ces espaces ? (Rien, ou tag spécifique ?) Y a-t-il un tag spécifique pour ces dépendances routières ? Tagguer-vous aussi les fossés et les busages d'accès au champs et prairies ? Et pour les espaces de trottoirs entre les voies et les propriétés privées ou le bâti, utilisez vous un tag spécifique, ou uniquement landuse=residential ? Avez vous quelques exemples spécifiques parlant ? Merci d'avance pour vos points de vue sur le sujet ! Sylvain -- View this message in context: http://gis.19327.n5.nabble.com/Tagguer-les-dependances-et-emprises-routieres-tp5743015.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [forum-osm-fr] Le million ? et vous comment avez-vous découvert OSM ?
Le message suivant de : ## Ca y est, le millionième compte a ét ouvert sur OpenStreetMap ! Vous rappelez-vous comment vous avez connu OSM ? Qu'est-ce qui vous a amené à l'ouvrir ce fameux compte ? a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=6 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à sylvainaletuffe.org ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
Personnellement je n'ai jamais trouvé ces grade* très pertinent, tout bonnement par ce que ce n'est pas assez parlant et donne plutôt une note suggestive. Aussi car ils sont très peu renseignés et quand ils le sont c'est de manière très inégale. A mon avis cela vient d'une classification officielle d'un autre pays qui publie l'état de son réseau de voiries (bref cela vient d'un import d'une autre base), mais on n'a pas ça en l'état en France. Il vaut mieux utiliser des tags plus précis pour mentionner la nature de la surface, la largeur, le statut (qui s'occupe de son entretien : c'est la numérotation des routes qui détermine si c'est une collectivité ou une concession à une société d'autoroute au nom de l'Etat; sinon ce sont des chemins forestiers sur un domaine public, sinon ce sont des voies privées avec peu d'obligations d'entretien, sauf s'il y a un droit de passage concédé par exemple pour un circuit de randonnée, avec un entretien par une association en accord avec le propriétaire), une date estimative de la dernière réfection, et quelques tags complémentaires pour des zones dégradées, ou dont les bas-côtés sont dangereux, ou pertiellement efffondrés. On utilisera aussi les tags pour les limitations de tonnage, de largeur, de hauteur, les interdictions à certains types de véhicules, l'accessibilité aux piétons (si la vitesse n'est pas réduite et s'il n'y a ni bas-côté ni trottoir), l'éclairage, l'absence de drainage suffisant en cas de pluie (possibilité d'inondation ou de terrain boueux ou glissant, ou de flaques), la pente, ... Si le but est de classer les voiries en fonction d'un usage (randonnée, cyclisme...), il vaut mieux mettre une classification spécifique à cet usage en s'appuyant sur les données fournies par les assos locales sans réinventer une autre classification ou essayer de se calquer sur une classification d'un autre pays : il y aura moins d'erreurs d'interprétation si on importe ces autres classifications par usage avec leur propre tag, quitte plus tard à définir une règle permettant de calculer/évaluer le grade* à partir du reste pour se rapprocher au mieux des interprétations officielles des autres pays qui ont ces tag grade* bien définis. Le 6 janvier 2013 12:42, Jo. perche...@gmail.com a écrit : Oui j'ai bien fait la différence. Il existe les routes mineure goudronnée et les pistes goudronnée (grade1). J'ai donc appliqué les grade 1 pour les voies étroite (2 mètres de large maxi) ou construite pour joindre une zone comportant d'autres piste. Elles sont généralement goudronnée pour résister à l'érosion les jours de forte pluie. J'ai utilisé des routes mineures quand elles permettent de circuler à plus de 50 km/h et/ou débouchant sur d'autre voie goudronnnée Le 6 janvier 2013 12:30, Pieren pier...@gmail.com a écrit : 2013/1/5 fo...@letuffe.org: grade1 : piste goudronné Attention, ça, c'est un mauvais raccourci. piste goudronnée veut bien dire grade1 mais grade1 ne veut pas dire piste goudronnée. Le chemin peut aussi être composé de matériaux très compactés (heavily compacted hardcore). Seul l'ajout d'un tag surface=* peut clarifier ce point. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Faux revert Mapnik
Salut, Dans Viking, lorsque j'ai rafraîchi les dalles du rendu Mapnik, j'ai eu un peu peur que mes contributions récentes aient été effacées. À certains niveaux de zoom, certaines dalles qui étaient en cache et affichant bien mes dernières contributions se sont vues remplacées par de nouvelles dalles... d'avant mes contributions ! Bref j'ai vérifié et rien n'a été supprimé. Je suppose que c'est dû au problème lié à la coupure de courant affectant le serveur. Je n'y connais rien mais je trouve bizarre que Mapnik soit revenu à des dalles plus anciennes. Ça fait quand même des frayeurs ;-) @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
En zone rurale même si la classification peut être ambiguë sur certaines piste l'utilisation de grade semble être suffisant. C'est vrais qu'on peut rentrer dans le détail mais mon objectif est surtout d'indiquer la présence de piste et leur état de chaussée en générale. Quand j'ai indiqué les usages, c'est simplement à but d'exemple et ne peut être appliqué dans sur une zone à la géographie et géologie similaire. Pour l'instant n'ayant pas eu d'avis indiquant que ce traçage était inutile doit je conclure que c'est acceptable ? L'idée est de représenter ce qui existe réellement avec ces critères : - Est ce que l'élément existe ? - Si oui, comment est il en général ? (utilisation de grade) - Si usage spécifique : précision de l'état réel pour chaque usage connu (définition plus poussée comme tu le propose) Dans mon cas il n'y a pas d'usage spécifique (vélo, chevaux, moto), je n'ai donc pas ajouté de détails. Le 6 janvier 2013 15:36, Philippe Verdy verd...@wanadoo.fr a écrit : Personnellement je n'ai jamais trouvé ces grade* très pertinent, tout bonnement par ce que ce n'est pas assez parlant et donne plutôt une note suggestive. Aussi car ils sont très peu renseignés et quand ils le sont c'est de manière très inégale. A mon avis cela vient d'une classification officielle d'un autre pays qui publie l'état de son réseau de voiries (bref cela vient d'un import d'une autre base), mais on n'a pas ça en l'état en France. Il vaut mieux utiliser des tags plus précis pour mentionner la nature de la surface, la largeur, le statut (qui s'occupe de son entretien : c'est la numérotation des routes qui détermine si c'est une collectivité ou une concession à une société d'autoroute au nom de l'Etat; sinon ce sont des chemins forestiers sur un domaine public, sinon ce sont des voies privées avec peu d'obligations d'entretien, sauf s'il y a un droit de passage concédé par exemple pour un circuit de randonnée, avec un entretien par une association en accord avec le propriétaire), une date estimative de la dernière réfection, et quelques tags complémentaires pour des zones dégradées, ou dont les bas-côtés sont dangereux, ou pertiellement efffondrés. On utilisera aussi les tags pour les limitations de tonnage, de largeur, de hauteur, les interdictions à certains types de véhicules, l'accessibilité aux piétons (si la vitesse n'est pas réduite et s'il n'y a ni bas-côté ni trottoir), l'éclairage, l'absence de drainage suffisant en cas de pluie (possibilité d'inondation ou de terrain boueux ou glissant, ou de flaques), la pente, ... Si le but est de classer les voiries en fonction d'un usage (randonnée, cyclisme...), il vaut mieux mettre une classification spécifique à cet usage en s'appuyant sur les données fournies par les assos locales sans réinventer une autre classification ou essayer de se calquer sur une classification d'un autre pays : il y aura moins d'erreurs d'interprétation si on importe ces autres classifications par usage avec leur propre tag, quitte plus tard à définir une règle permettant de calculer/évaluer le grade* à partir du reste pour se rapprocher au mieux des interprétations officielles des autres pays qui ont ces tag grade* bien définis. Le 6 janvier 2013 12:42, Jo. perche...@gmail.com a écrit : Oui j'ai bien fait la différence. Il existe les routes mineure goudronnée et les pistes goudronnée (grade1). J'ai donc appliqué les grade 1 pour les voies étroite (2 mètres de large maxi) ou construite pour joindre une zone comportant d'autres piste. Elles sont généralement goudronnée pour résister à l'érosion les jours de forte pluie. J'ai utilisé des routes mineures quand elles permettent de circuler à plus de 50 km/h et/ou débouchant sur d'autre voie goudronnnée Le 6 janvier 2013 12:30, Pieren pier...@gmail.com a écrit : 2013/1/5 fo...@letuffe.org: grade1 : piste goudronné Attention, ça, c'est un mauvais raccourci. piste goudronnée veut bien dire grade1 mais grade1 ne veut pas dire piste goudronnée. Le chemin peut aussi être composé de matériaux très compactés (heavily compacted hardcore). Seul l'ajout d'un tag surface=* peut clarifier ce point. Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
Le 6 janvier 2013 16:06, Jo. perche...@gmail.com a écrit : Pour l'instant n'ayant pas eu d'avis indiquant que ce traçage était inutile doit je conclure que c'est acceptable ? D'accord avec toi. Romain ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Faux revert Mapnik
C'était soit des dalles anciennes soit rien... Le 6 janvier 2013 15:40, Stéphane MARTIN st3ph.mar...@laposte.net a écrit : Salut, Dans Viking, lorsque j'ai rafraîchi les dalles du rendu Mapnik, j'ai eu un peu peur que mes contributions récentes aient été effacées. À certains niveaux de zoom, certaines dalles qui étaient en cache et affichant bien mes dernières contributions se sont vues remplacées par de nouvelles dalles... d'avant mes contributions ! Bref j'ai vérifié et rien n'a été supprimé. Je suppose que c'est dû au problème lié à la coupure de courant affectant le serveur. Je n'y connais rien mais je trouve bizarre que Mapnik soit revenu à des dalles plus anciennes. Ça fait quand même des frayeurs ;-) @+ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [forum-osm-fr] Chemin (piste) de vigne...
Le 06/01/2013 16:06, Jo. a écrit : En zone rurale même si la classification peut être ambiguë sur certaines piste l'utilisation de grade semble être suffisant. C'est vrais qu'on peut rentrer dans le détail mais mon objectif est surtout d'indiquer la présence de piste et leur état de chaussée en générale. Quand j'ai indiqué les usages, c'est simplement à but d'exemple et ne peut être appliqué dans sur une zone à la géographie et géologie similaire. Pour l'instant n'ayant pas eu d'avis indiquant que ce traçage était inutile doit je conclure que c'est acceptable ? L'idée est de représenter ce qui existe réellement avec ces critères : - Est ce que l'élément existe ? - Si oui, comment est il en général ? (utilisation de grade) - Si usage spécifique : précision de l'état réel pour chaque usage connu (définition plus poussée comme tu le propose) Dans mon cas il n'y a pas d'usage spécifique (vélo, chevaux, moto), je n'ai donc pas ajouté de détails. Oui, c'est tout bon ! On ne va pas attendre d'avoir appris tout un dictionnaire de jeu de tag avant de se mettre à cartographier un chemin de vigne ! Quand je suis en rando, je n'ai pas de mètre pour calculer la largeur du chemin, et mon GPS ne fait pas ça tout seul ! Et je ne fais pas d'enquête pour savoir si c'est le paysan, la commune, les chasseurs, le concessionnaire autoroutier, les lapins qui entretiennent ou défoncent les chemins. grade va très bien et est une bonne estimation pour le commun des mortels, et le pifomètre, pourvu qu'il soit étalonné, reste un excellent outil d'appréciation. On est nombreux sur cette liste uns à avoir appris à (fortement) relativiser certains messages très/trop doctes, très/trop longs de certains auteurs. Je soupçonne même quelques uns d'avoir mis un bouton TLDR [1] pour ces messages ou même un filtre skip pour ces auteurs. [1] http://fr.wiktionary.org/wiki/TLDR -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] [Fwd: [OSM-talk] Changeset Comments]
Hello, je viens de traduire la page du wiki sur le bon usage du commentaire de changeset. http://wiki.openstreetmap.org/wiki/FR:Good_changeset_comments Je la trouve importante, surtout au début car on ne comprends pas bien à quoi peut servir ce commentaire (j'avoue ne pas toujours avoir correctement rempli ce champ au début... et peut être encore maintenant :-)) Cordialement, Mika_Gueret ---BeginMessage--- Hi, once in a while I encounter mappers who don't understand what changeset comments are good for and why they should use them. I was kind of tired of repeating the same things over and over so I wrote up a wiki page here: http://wiki.openstreetmap.org/wiki/Good_Changeset_Comments Before someone asks, this is not intended to be a policy of any sort; it is just meant as a page that you can recommend for reading if someone doesn't understand what changeset comments are for. You're welcome to improve this, add/remove examples, or translate into other languages. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ talk mailing list t...@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ---End Message--- ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Frontière administrative et rond-point
Hello, Je viens de tomber sur un cas étrange où un rond-point est utilisé dans une frontière administrative. La relation: http://www.openstreetmap.org/browse/relation/1849171 Le lien Osmose: http://osmose.openstreetmap.fr/map/?zoom=18lat=48.7958lon=2.49011layers=BFFFTitem=6010level=1,2,3 Je n'avais jamais vue une zone défini par un rond-point comme cela. La plupart du temps le rond-point est découpé en plusieurs segment ou bien un chemin est ajouté en travers du rond point pour supporter la limite administrative. D'ailleurs, lorsqu'on édite avec JOSM, on voit qu'il y a justement un chemin qui sert de support a une autre relation. Osmose n'aime pas du tout cette représentation, mais JOSM semble d'accords avec cette façon de faire. On voit, en éditant la relation, qu'il marque l'ensemble des ways comme une zone fermé, avec un petit icône sur le rond-point. JOSM a donc du code pour supporter ce cas particulier. Personnellement, je trouve que la représentation actuelle est ambiguë. Le rond-point fait-il partie de la zone ou pas ? Quelques soit la réponse, il me semble que ce n'est pas correcte. Si on considère que le rond-point fait partie de la limite de cette relation, on va avoir des zones qui se chevauche. Et si on considère qu'il n'en fait pas partie, les rond-points en limite n'appartiendrons plus à personne. Je serais donc d'avis de modifier cette relation. Et vous ? Black Myst ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Frontière administrative et rond-point
Le dimanche 06 janvier 2013 19:58:11, Black Myst a écrit : Je serais donc d'avis de modifier cette relation. Et vous ? Pareil, c'est ce way là qui devrait être membre, et pas le rond point en entier : http://www.openstreetmap.org/browse/way/185502907 ps: d'ailleurs, la présence de ce chemin me laisse penser que ça a été juste à un moment et que quelqu'un a fait une mauvaise manip -- sly (sylvain letuffe) ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] [Fwd: [OSM-talk] Changeset Comments]
Merci pour ce petit rappel. Pour ma part, dans mes commentaires, j'ai pris le coup, d'y rajouter mes sources... car j'ai jamais compris comment on pouvait mettre la source directement sur l'objet quand chacune des modifications, ont leur propres sources... Je pense même que dans le futur il faudrait rendre obligatoire de remplir un tag source directement sur le changset, mais la aussi j'ai remarqué que je n'utilise quasiment jamais une seule source... et fait très souvent un mix entre vues aériennes, cadastre, terrain, traces gps... Sur les commentaires, j'y rajoute aussi la zone d'édition (département et villes), je trouve cela pratique quand on regarde le listing des éditions... -- View this message in context: http://gis.19327.n5.nabble.com/Fwd-OSM-talk-Changeset-Comments-tp5743072p5743086.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Vandalisme ?
Oui, il s'agit bien de cette route. Me voilà rassuré ! Si j'ai bien compris, il me suffit de rétablir les tags appropriés pour la voir revenir dans la carte. Je te remercie. Cordialement, Christophe. Le 5 janvier 2013 11:09, Etienne Trimaille etie...@trimaille.eu a écrit : Est-ce que tu parle de cette route ? http://www.openstreetmap.org/?way=33269952 ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Donc, YouMap, uMap, maCarte, maMap, monOsm, Maposmme aka MapOsmMe...
On 01/06/2013 12:45 PM, Tigre-Bleu wrote: Salut, C'est vraiment sympa! Merci :) Je pense que ça serait bien de rajouter un champ de recherche pour pouvoir centrer la carte facilement sur un petit bled sans galérer à zoomer un peu au petit bonheur la chance entre les 2 grandes villes d'a coté qui apparaissent à des petits niveau de zoom :-) Une recherche à proprement parler n'est pas dans les priorités de la 0.1, sur laquelle je suis en train de travailler, mais l'idée me paraît bonne, donc j'ai ajouté une sorte de jump to location, qui interroge Nominatim et zoom sur le premier résultat de recherche, sans plus d'interaction pour le moment. A tester ici par exemple: http://umap.fluv.io/map/JoeLapin/whatsthat/#15/49.1188/6.1771 :) Tests et retours bienvenus! :) Yohan ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
