Re: [talk-ph] is the text Province of necessary in the is_in:state tags?
Tutubi, For place= tags, we add the is_in tags. But for POIs, (amenities, shops) I suggest you add address information (addr:housenumber, addr:street, addr:city). On Fri, Oct 29, 2010 at 3:30 PM, tutubi tut...@backpackingphilippines.com wrote: I was about to ask the same question if I need to add the province and town information on my edits :P -- 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
[talk-ph] UNOSAT map of Divilacan and Maconanon
FYI, UNOSAT recently just published a map of Isabela. Here is the link: http://unosat.web.cern.ch/unosat/asp/prod_free.asp?id=46 Description: This map illustrates satellite-detected stream networks, roads and urban areas around Divilacan in the Isabela Province, Philippines. analysis is based on detection methods using FORMOSAT SPOT acquired over the area on 26 October 2010. ASTER global elevation model (GDEM) was also used in the stream analysis. This base data assessment is a preliminary analysis has not yet been validated in the field. The depiction and use of boundaries, geographic names and related data shown here are not warranted to be error-free nor do they imply official endorsement or acceptance by the United Nations. UNOSAT is a program of the United Nations Institute for Training and Research (UNITAR), providing satellite imagery and related geographic information, research and analysis to UN humanitarian development agencies their implementing partners. --bunny ___ talk-ph mailing list talk-ph@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ph
Re: [OSM-legal-talk] Licenses for data sources
I’m going to just be using the 2008 orthographs, but that is for technical reasons as I don’t feel confident I could handle the shp - osm conversion. The import itself for some of the items would likely be easy – I doubt anyone has gone and tagged the streetlights or some of the other more obscure features. I’ll also be trying to get their 10cm orthophotos. The form they have them up in is rather useless, but that is once again a technical issue. I feel like there is definitely an issue with how acceptable licenses are communicated. The PDDL is a license that is likely to be found multiple places, but I was unable to find anything that said it was okay to use data from those sources. From: legal-talk-boun...@openstreetmap.org [mailto:legal-talk-boun...@openstreetmap.org] On Behalf Of Michael Barabanov Sent: Sunday, October 31, 2010 8:02 PM To: Licensing and other legal discussions. Subject: Re: [OSM-legal-talk] Licenses for data sources Hi Paul, re Vancouver, please see http://weait.com/content/tragedy-edmontorcouver-open-data http://weait.com/content/unintended-restrictions re PDDL: http://www.opendatacommons.org/licenses/pddl/summary/ No restrictions are listed. Since they have vector data available, importing that (as opposed to tracing) should be the way to go. Michael. On Sun, Oct 31, 2010 at 6:10 PM, Paul Norman penor...@mac.com wrote: Is there a consolidated list of licenses that are acceptable on data sources for use for importing or tracing into OSM? I ask this question because wiki information has been contradicted by email discussion on the subject of City of Vancouver open data. Additionally, is it acceptable to trace from PDDL orthography into OSM? The City of Surrey has some orthography of a very high quality and they have released it and all of their GIS data under PDDL. I would expect PDDL to be compatible, but having received contradictory information once, I’m checking. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] auckland city council copyright notice
On 1 November 2010 11:44, Richard Weait rich...@weait.com wrote: Municipalities shouldn't write licenses; it ain't their job. It ain't their core competence. Their citizens ain't paying for the city to do license composition and maintenance. Regardless what we'd like, we should be happy they didn't just slap crown copyright all over everything and are branching out with more liberal licenses, this sort of mindset change doesn't happen over night and it's a shame that this sort of thing isn't celebrated, rather than shunned. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] New diary spammer
User aaron63cortez [0] seems to have created an account only to post diary spam. -- Morten [0] http://www.openstreetmap.org/user/aaron63cortez ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
2010/11/1 SomeoneElse li...@mail.atownsend.org.uk: On 31/10/2010 13:46, Gorm E. Johnsen wrote: I propose to replace highway=ford with ford=yes (or perhaps barrier=ford?) on nodes as well, simply to de-clutter the highway tag and to be more consistent. IMHO for the cases I tagged highway=ford on nodes it fits well. simply to declutter is not a sufficient argument to change 5000 tags that are in use for a long time. Please don't change things unless you've actually been there and surveyed the item in question. +1 As it says on http://wiki.openstreetmap.org/wiki/Automated_Edits/Code_of_Conduct , Always remember that local knowledge beats a couch potato from central command any time!. +1 cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
2010/11/1 Andrew Errington a.erring...@lancaster.ac.uk: On Mon, 01 Nov 2010 18:22:19 M∡rtin Koppenhoefer wrote: 2010/11/1 SomeoneElse li...@mail.atownsend.org.uk: On 31/10/2010 13:46, Gorm E. Johnsen wrote: I propose to replace highway=ford with ford=yes (or perhaps barrier=ford?) on nodes as well, simply to de-clutter the highway tag and to be more consistent. IMHO for the cases I tagged highway=ford on nodes it fits well. simply to declutter is not a sufficient argument to change 5000 tags that are in use for a long time. ford=yes is the right answer, like bridge=yes and tunnel=yes. A ford is a linear feature, usually extending across the width of a river, much like a bridge does, which could be several metres long. I tagged a path crossing a stream with highway=ford. Even if this is on closeup a linear feature, beeing the stream less then 1 meter wide and the path as well, anything else then a node seems exaggerated to me. If the ford is to cross a real river I agree that a way would be better. Replacing 5000 instances of the 'old' tag is a drop in the ocean. no, it is completely replacing an entire feature forcing your own idea of how a feature should be represented. Automated Edits of this kind are not welcome. See the wiki on automated edits. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, 1 Nov 2010 18:56:59 +0900 Andrew Errington a.erring...@lancaster.ac.uk wrote: It should have been highway=path, ford=yes. Well don't redefine any I have mapped as 'path', because most would have been for vehicles. Again, don't retag without having visited the site. How many times does this need to be repeated?? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Anyone read the CC0 legal code?
On 1 November 2010 02:40, Toby Murray toby.mur...@gmail.com wrote: Currently the checkbox has absolutely no bearing on the license that your data is distributed under. It really is just a statement of purpose which is noted in the account settings but doesn't actually DO anything. Most people don't bother to read or understand what it means anyway and just tick it because they're so used to ticking boxes to show they accept/agree to the text above, which they don't usually bother to read either... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, Nov 1, 2010 at 11:28 AM, Elizabeth Dodd ed...@billiau.net wrote: Well don't redefine any I have mapped as 'path', because most would have been for vehicles. Again, don't retag without having visited the site. Sorry, perhaps I missed something but the suggestion was to replace highway=ford by ford=yes on nodes, not ways. I think something similar was done in the past with highway=barrier and I don't understand the arguments against this change. Pieren ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, 01 Nov 2010 19:28:53 Elizabeth Dodd wrote: On Mon, 1 Nov 2010 18:56:59 +0900 Andrew Errington a.erring...@lancaster.ac.uk wrote: It should have been highway=path, ford=yes. Well don't redefine any I have mapped as 'path', because most would have been for vehicles. I wouldn't dream of it. I was talking about the specific ford I mapped.Of course, the highway=* tag would be obvious from the preceding and following way segments. Again, don't retag without having visited the site. How many times does this need to be repeated?? Once more it would seem. Best wishes, Andew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, 01 Nov 2010 20:41:02 Pieren wrote: On Mon, Nov 1, 2010 at 11:28 AM, Elizabeth Dodd ed...@billiau.net wrote: Well don't redefine any I have mapped as 'path', because most would have been for vehicles. Again, don't retag without having visited the site. Sorry, perhaps I missed something but the suggestion was to replace highway=ford by ford=yes on nodes, not ways. I think something similar was done in the past with highway=barrier and I don't understand the arguments against this change. It could apply equally to ways or nodes. ford=yes on a way means (to me) that this segment of the way is often covered with water. ford=yes on a node means (to me) that the ford is very short. Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, 01 Nov 2010 19:08:45 M∡rtin Koppenhoefer wrote: 2010/11/1 Andrew Errington a.erring...@lancaster.ac.uk: On Mon, 01 Nov 2010 18:22:19 M∡rtin Koppenhoefer wrote: 2010/11/1 SomeoneElse li...@mail.atownsend.org.uk: On 31/10/2010 13:46, Gorm E. Johnsen wrote: I propose to replace highway=ford with ford=yes (or perhaps barrier=ford?) on nodes as well, simply to de-clutter the highway tag and to be more consistent. IMHO for the cases I tagged highway=ford on nodes it fits well. simply to declutter is not a sufficient argument to change 5000 tags that are in use for a long time. ford=yes is the right answer, like bridge=yes and tunnel=yes. A ford is a linear feature, usually extending across the width of a river, much like a bridge does, which could be several metres long. I tagged a path crossing a stream with highway=ford. Even if this is on closeup a linear feature, beeing the stream less then 1 meter wide and the path as well, anything else then a node seems exaggerated to me. If the ford is to cross a real river I agree that a way would be better. So ford=yes can apply to a way or a node. Easy. Replacing 5000 instances of the 'old' tag is a drop in the ocean. no, it is completely replacing an entire feature forcing your own idea of how a feature should be represented. Automated Edits of this kind are not welcome. See the wiki on automated edits. Well it would be if I was going to do it, which I never even mentioned. Best wishes, Andrew ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
2010/11/1 Andrew Errington a.erring...@lancaster.ac.uk: It could apply equally to ways or nodes. I agree that ford=yes is better for ways then highway=ford, but on nodes this problem doesn't arise. You could still keep highway=ford. I think that this proposal wants to unify the tagging in this particular case, yet creating inconsistencies on other places: shouldn't railway=level_crossing then become level_crossing=yes ? Or highway=stop stop=yes? I find it easier to agree with this change if it augmented consistency in general (i.e. changing also other keys), and not only changed one value from a to b. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On 24/10/2010 20:02, Gorm E. Johnsen wrote: There are now few, if any, ways with highway=ford left. They have all been changed to highway=whatever the connecting ways are + ford=yes http://wiki.openstreetmap.org/wiki/Key:ford. Any suggestions on what to do with the 4800 nodes also tagged with highway=ford? Change them to ford=yes all in one go as well? It would be helpful to follow the usual tag proposal process to deprecate highway=ford, and replace it with ford=yes. Then you should update any editors or renderers or other applications to support this. Then, after this, you could consider making bulk changes. I do agree that replacing highway=ford with ford=yes is a good idea, though it should be done properly, and not breaking existing applications. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
Craig Wallace wrote: On 24/10/2010 20:02, Gorm E. Johnsen wrote: There are now few, if any, ways with highway=ford left. They have all been changed to highway=whatever the connecting ways are + ford=yes http://wiki.openstreetmap.org/wiki/Key:ford. Any suggestions on what to do with the 4800 nodes also tagged with highway=ford? Change them to ford=yes all in one go as well? It would be helpful to follow the usual tag proposal process to deprecate highway=ford, and replace it with ford=yes. Then you should update any editors or renderers or other applications to support this. Then, after this, you could consider making bulk changes. I do agree that replacing highway=ford with ford=yes is a good idea, though it should be done properly, and not breaking existing applications. As long as the DISTANCE of the water area of the ford can be handled by this change then it may be acceptable, but simply tagging a node is not the right way to provide ALL of the information that would be useful when it comes to micro-mapping the details? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Query using ST_transform fails
On Mon, 2010-11-01 at 09:21 +0100, Torsten Mohr wrote: Hello, i once got a hint on this mailing list to use a query like this to get the lat/lon of the world capitals: A) select st_X(wayLL), st_Y(wayLL), name from (select ST_AsText(ST_Transform(way,4326)) as wayLL, name from planet_osm_point where capital='yes') as foo limit 5; B) Based on that hint i used this query: select st_X(st_transform(way,4326)), st_Y(st_transform(way,4326)), name from planet_osm_point where place='city' and capital='yes'; That query worked fine and i did not change my system since then (that somehow can't be true). I now get errors for both queries: FEHLER: transform: couldn't project point (653103 6.63036e+06 0): failed to load NAD27-83 correction file (-38) TIP: PostGIS was unable to transform the point because either no grid shift files were found, or the point does not lie within the range for which the grid shift is defined. Refer to the ST_Transform() section of the PostGIS manual for details on how to configure PostGIS to alter this behaviour. Could it be that due to an RPM update of PostgreSQL some scripts need to be reinstalled? I can still generate maps using mapnik. What do i need to do to make those queries work again? Try: # yum install proj-nad Then I think you need to restart the postgres server. I think the error started appearing after a proj or postgis update, I don't remember exactly when. It took me some time to realise that these grid shift files were in this package. Jon ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
2010/11/1 Lester Caine les...@lsces.co.uk: I do agree that replacing highway=ford with ford=yes is a good idea, though it should be done properly, and not breaking existing applications. As long as the DISTANCE of the water area of the ford can be handled by this change then it may be acceptable, but simply tagging a node is not the right way to provide ALL of the information that would be useful when it comes to micro-mapping the details? if it's about a ford in a stream which is tagged say width=0.7, which other information would you get from a way for the ford instead of a node? Wouldn't hydrants (or public telephones, etc.) be better mapped as areas when it comes to micro-mapping ;-) ? There is no node in real world, still many objects are better (or almost equally) represented by a node instead of by an area. cheers, Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
M∡rtin Koppenhoefer wrote: I do agree that replacing highway=ford with ford=yes is a good idea, though it should be done properly, and not breaking existing applications. As long as the DISTANCE of the water area of the ford can be handled by this change then it may be acceptable, but simply tagging a node is not the right way to provide ALL of the information that would be useful when it comes to micro-mapping the details? if it's about a ford in a stream which is tagged say width=0.7, which other information would you get from a way for the ford instead of a node? Well a number of the fords around the Cotswolds are not simple passages across a narrow stream like that. They can have some considerable distance in the water and way well come out at a different position on the bank on the other side. SO the way that forms the path through is required! Simplifying things at one level makes including that detail at another more difficult so SIMPLY removing ford from highway then requires some other way to map the 'highway' element through more complex fords ... Wouldn't hydrants (or public telephones, etc.) be better mapped as areas when it comes to micro-mapping;-) ? There is no node in real world, still many objects are better (or almost equally) represented by a node instead of by an area. Some means of including the microlevel deat,l IS required and has yet to be agreed on. At some scale a nde needs to be replaced with an area but at present OSM has no way of including that data :( -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Anyone read the CC0 legal code?
On Mon, Nov 1, 2010 at 6:36 AM, John Smith deltafoxtrot...@gmail.com wrote: On 1 November 2010 02:40, Toby Murray toby.mur...@gmail.com wrote: Currently the checkbox has absolutely no bearing on the license that your data is distributed under. It really is just a statement of purpose which is noted in the account settings but doesn't actually DO anything. Most people don't bother to read or understand what it means anyway and just tick it because they're so used to ticking boxes to show they accept/agree to the text above, which they don't usually bother to read either... Presumably such people (who don't read the things they're agreeing to) don't care about their copyrights, in which case they're actually answering the question correctly. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
Dear everybody Nice to see that some actually read the original post before replying, in an effort to keep on subject. Interesting to see that nobody seems to object strongly to the (manual) edits I have already done with *ways* tagged with highway=ford. Now all those ways show up in all(?) renderers and are routeable. I do hope that is for the better. Now I ask for a simple yes or no or better alternatives for changing the tagging scheme for a few k *nodes*. Please, can we continue the discussion on the wiki? http://wiki.openstreetmap.org/wiki/Talk:Key:ford Thank you. Gorm ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On Mon, 1 Nov 2010 23:51:47 +0100 Gorm E. Johnsen osml...@gorm.cc wrote: Now I ask for a simple yes or no or better alternatives for changing the tagging scheme for a few k *nodes*. Please, can we continue the discussion on the wiki? http://wiki.openstreetmap.org/wiki/Talk:Key:ford Simply No, and No *why* do you have to change the nodes? and *why* do you want us to switch to arguing on the wiki? ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
Elisabeth I don't *_have_ to* change the nodes. I ask if it's a good idea. And I asked (in the original post) for comments on the wiki. I believe the wiki is a better arena for it. You can of course continue here if you like. I have argued that I would like to do it for consistency. Most *_*ways*_* is already changed, so I think it would be nice to do the same with nodes. Apparently you oppose to that idea. Then I suggest you put a no-vote on the wiki. I also hope you put together a sentence or two why you oppose it. All I sense there might be a misunderstanding here: I have _not_ changed the geometry of the way-fords (apart from connecting them to existing riverbanks where available, and a few other minor adjustments). I am _not_ proposing to create ways out of single nodes tagged with highway=ford. I'm simply asking to replace highway=ford with ford=yes on nodes as well. best regards On Tue, Nov 2, 2010 at 12:16 AM, Elizabeth Dodd ed...@billiau.net wrote: On Mon, 1 Nov 2010 23:51:47 +0100 Gorm E. Johnsen osml...@gorm.cc wrote: Now I ask for a simple yes or no or better alternatives for changing the tagging scheme for a few k *nodes*. Please, can we continue the discussion on the wiki? http://wiki.openstreetmap.org/wiki/Talk:Key:ford Simply No, and No *why* do you have to change the nodes? and *why* do you want us to switch to arguing on the wiki? ___ 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] highway=ford vs ford=yes
Gorm E. Johnsen wrote: I sense there might be a misunderstanding here: I have _not_ changed the geometry of the way-fords (apart from connecting them to existing riverbanks where available, and a few other minor adjustments). I am _not_ proposing to create ways out of single nodes tagged with highway=ford. I'm simply asking to replace highway=ford with ford=yes on nodes as well. BUT adding fine detail DOES require changing the nodes to ways ... This seems to be the misunderstanding that you and others may be missing? At SOME scales, then a ford is simply a node - as are many features - but the higher the zoom, there comes a point where a node MUST become a way or even an area. So changing the top level view is simply wrong when the lower levels still expect that element to be expanded to a way at some point ... Just because no one has added the fine detail is no reason to remove the element into some other 'domain'. That applies in a lot of cases where people are arguing that some node tag should be simplified. So just because YOU are not proposing to add missing information is no reason to make that difficult for everybody else? When would you then change them back to highway=ford ... so that the way detail can be added? -- Lester Caine - G8HFL - Contact - http://lsces.co.uk/wiki/?page=contact L.S.Caine Electronic Services - http://lsces.co.uk EnquirySolve - http://enquirysolve.com/ Model Engineers Digital Workshop - http://medw.co.uk// Firebird - http://www.firebirdsql.org/index.php ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
On 01/11/2010 22:51, Gorm E. Johnsen wrote: Interesting to see that nobody seems to object strongly to the (manual) edits I have already done with *ways* tagged with highway=ford. That's not strictly true; I did object (and you replied) via the OSM message system when you started updating fords so that they didn't reflect the sense of what was there on the ground. The highway=ford to highway=blah/ford=yes change did make sense*; it was the other tidying that you did at the same time that I objected to. Please, can we continue the discussion on the wiki? http://wiki.openstreetmap.org/wiki/Talk:Key:ford Please no. There seems to be an infinite number of monkeys over there but they've not come close to the works of Shakespeare. If you want to influence the way stuff is tagged in OSM go out and map stuff; you can then tag it how you like. * some warning would have been helpful though, so that people who render maps (which includes anyone who creates maps for e.g. Garmin GPSs) can keep up to date with how someone in an armchair thinks things should be tagged this week. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] highway=ford vs ford=yes
Perhaps an example of the two schemes is in its place. Examine this area: http://www.openstreetmap.org/?lat=58.999175lon=5.787731zoom=18layers=M (Yes, I'm using a small patch my neck of the woods as sandbox for this example. I promise to clean up afterwards :-) Left: fords tagged as single nodes. Right: fords drawn as short ways. Top: using highway=ford Bottom: using ford=yes Today there is mostly a mix of top-left and bottom-right. Again: Left and right co-exist nicely. I do not propose to convert between them. That is of course up to the individual mapper. Again: What I _do_ propose, is to rename a tag on some elements. From top to bottom in the example. best regards ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk-nl] Wadi
Beste allemaal, Als eerste mijn dank aan iedereen die denkwerk heeft willen doen voor dit fenomeen. Wat mij betreft is Lennard de winnaar van deze lokale tagging contest geworden. Hij vond in de jungle van Wiki een bestaande tagcombnatie die voor mij het dichtst ligt bij de functie zoals hier aanwezig. Wadi is te woestijnerig en Floodplain lijkt mij te grootschalig en toch wat te tropisch. Navraag leert overigens dat daadwerkelijk deze grasvelden de oppervlakte zijn van een irrigerende bodem die speciaal voor dit doel is aangelegd. Voor mij dus: * landuse=basin * basin=infiltration Moeten de renderers er alleen nog wel een betere afbeelding voor vinden. groet Robert Citeren Lennard l...@xs4all.nl: On 30-10-2010 16:33, rob...@elsenaar.info wrote: Wie schiet de eerste zinnige keuze inclusief argument? Er zijn al wat suggesties langsgekomen. Mag ik dan de eerste zijn die wijst op een al bestaande en gedocumenteerde tag? http://wiki.openstreetmap.org/wiki/Key:basin -- Lennard ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wadi
Op 1 november 2010 09:49 heeft rob...@elsenaar.info het volgende geschreven: Voor mij dus: * landuse=basin * basin=infiltration Moeten de renderers er alleen nog wel een betere afbeelding voor vinden. Klopt deze worden momenteel als grote plas gerenderd.. wat toch niet helemaal de werkelijkheid representeert.. Rob ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wadi
In de Wiki staat dat het blauw met druppeltjes zou moeten worden. Ik denk eerder dat grasgroen met druppeltjes een betere redering is, maar ja. Hopelijk vinden de makers van de stylesheet dat ook. Leuke is namelijk datwij hier een basin hebben waar in de droge periode een voetbalveld is. Als dat als een voetballetje wordt gerenderd en die staat in het blauwe water, dan staat dat erg stom. Een voetballetjes op een grasveld met druppels, dat kan m.i. dan nog. groet robert Citeren Rob r...@coolbegin.com: Op 1 november 2010 09:49 heeft rob...@elsenaar.info het volgende geschreven: Voor mij dus: * landuse=basin * basin=infiltration Moeten de renderers er alleen nog wel een betere afbeelding voor vinden. Klopt deze worden momenteel als grote plas gerenderd.. wat toch niet helemaal de werkelijkheid representeert.. Rob ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [OSM-talk-nl] Wadi
Dat heb ik dus nu, een speeltuin in het water. Wie kan die presentatie aanpassen? Op 1 nov 2010 13:42 schreef rob...@elsenaar.info: In de Wiki staat dat het blauw met druppeltjes zou moeten worden. Ik denk eerder dat grasgroen met druppeltjes een betere redering is, maar ja. Hopelijk vinden de makers van de stylesheet dat ook. Leuke is namelijk datwij hier een basin hebben waar in de droge periode een voetbalveld is. Als dat als een voetballetje wordt gerenderd en die staat in het blauwe water, dan staat dat erg stom. Een voetballetjes op een grasveld met druppels, dat kan m.i. dan nog. groet robert Citeren Rob r...@coolbegin.com: Op 1 november 2010 09:49 heeft rob...@elsenaar.info het volgende geschreven: Voor mij d... ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
[OSM-talk-nl] T-Dose 2010
Dag allemaal, Komend weekend 6 en 7 november hebben we op T-Dose een stand om het OSM woord te verkondigen. Quote van de website: http://t-dose.nl/ T-DOSE is a free and yearly event held in The Netherlands to promote use and development of Open Source Software. During this event Open Source projects, developers and visitors can exchange ideas and knowledge. This years event will be held on 6 and 7 November 2010 at the Fontys University of Applied Science in Eindhoven. Als je wilt helpen, mail mij dan even. Ik zoek voor zaterdag en zondag nog 1 of 2 mensen (mag dus ook 1 van die dagen). Groet, Floris ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-nl
Re: [talk-au] [Fwd: [OpenStreetMap] Re: Marree, South Australia]
On Wed, 27 Oct 2010 15:28:08 +1000 Ross Scanlon i...@4x4falcon.com wrote: Please don't touch them, I'll arrange to have the reverts run over this weekend (30th-31st October). My significant other is waiting impatiently to edit Marree. How are you going with this? Really we have plenty else to map for a few days. Then there are other changesets listed by Staehler in May #4341783 #4341031 #4339058 #4338519 #4332119 #4330945 #4330174 and we need to be sure that they are all reverted. Yes, staehler agreed to this in May, and asked another mapper to assist, and we need to ensure that it is completed. Liz ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
[talk-au] For those long winter evenings...
http://www.t-reichling.de/en/mocs_euromap.shtml ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] (neue) Lizenz
Ich halte das, ehrlich gesagt, für herausgeschmissenes Geld und Zeit. Die Anwälte der OSMF wollen (IMHO) mit Sicherheit die Anzahl der Sprachversionen auf das absolute Minimum halten. Jede zusätzliche Übersetzung birgt die Gefahr von subtilen Unterschiede und bringt in der Zukunft nur weitere Kosten und Ärger. Da die englische Version problemlos rechtsgültig angenommen werden kann in Deutschland, halte ich es für sehr unwahrscheinlich, dass sie eine nicht vom OSMF in Auftrag gegebene deutschsprachige Version akzeptieren würden (würde ich auch nicht), d.h. auch bei vorliegen einer beglaubigten Übersetzung wird man trotzdem die englische (oder meinetwegen die französische) Version der CTs annehmen müssen. Ich sehe auch das Problem des OP nicht ganz, er kann sich ja via einer Vertrauensperson versichern, dass die inoffizielle Übersetzung den englischen CTs enstspricht, wirklich besser wird das auch bei vorliegen einer beglaubigten Übersetzung nicht. Simon - Original Message - From: Peter Körner osm-li...@mazdermind.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Sent: Saturday, October 30, 2010 12:29 PM Subject: Re: [Talk-de] (neue) Lizenz Am 30.10.2010 13:01, schrieb Steffen Heinz: sorry, das ich noch mal darauf zurückkomme! Ich kann den Text nicht lesen (bin kaum des englisch mächtig) ein Mensch aus dem Bekanntenkreis sagte das (zumindest in meinem Falle) ein Unterschrift nicht rechtsgültig ist wenn der Text nicht gelesen werden kann - übersetzungen würden nur dann reichen wenn die rechtlich (vereidigter Übersetzer) abgesichert sind. Und genau das ist das Problem, bisher hat sich keiner dafür verantwortlich gefühlt. Ich habe eine Anfrage An Herrn Udo Vetter vom Lawblog [1] gesendet mit der Frage nach einer Ansprechstelle und einer Einschätzung der Kosten für eine Beglaubigung und ggf. Übersetzung. Ich werde hier berichten, sobald ich eine Antwort erhalte. Lg, Peter ___ 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
[Talk-de] Feinkost
hi ! hat einer eine Idee für Feinkostgeschäfte ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feinkost
jan99 wrote: hat einer eine Idee für Feinkostgeschäfte ? wie wär's mit deli ? http://dict.leo.org/ende?lp=endelang=desearchLoc=0cmpType=relaxedsectHdr=onspellToler=search=deli -- View this message in context: http://gis.638310.n2.nabble.com/Feinkost-tp5693009p5693051.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Schade dass der Address-Inspector von der GeoFabrik immer noch keine Konsistenzprüfung KA-Schema vs. PLZ-Polygone machen kann. In Marl zB. sind die Adressen von der Stadtverwaltung gestiftet und importiert worden, da könnte man also schön die PLZ-Polygone danach ausrichten, wenn es nicht so aufwändig wäre. Oder kennt jemand einen Trick wie man in JOSM die Adress-Nodes zB. je nach letzten beiden Stellen der PLZ einfärben kann. (zB ...72 rot, ...76 grün). Christian ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am Sonntag 31 Oktober 2010, 21:57:51 schrieb Élisée Reclus: Also irgendwie strukturieren und sortieren musst du es für Menschen ja in jedem Fall ab einer gewissen Anzahl möglicher Werte, da man ansonsten den Überblick verliert. Du kannst (oder solltest) weder im Wiki noch im JOSM-Menue (z.B.) hundert Werte untereinander haben. Warum nicht also schon eine Struktur im Datenformat abbilden? +1 Ein (neuer) Mapper könnte außerdem, wenn er die Werte nicht nachschlagen kann oder will, schonmal „healthcare=yes“ mit „fixme=*“ mappen. oder er kann, falls er was neues findet, wofuer es noch kein Tag gibt, dieses Objekt als healthcare = xyeinrichtung taggen, und man weiss sofort, dass es hier um eine Gesundheitseinrichtung handelt. waere ja nicht so, dass aehnliches nicht schon mal vorgeschlagen wurde... ;-) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am 31.10.2010 21:57, schrieb Élisée Reclus: Also irgendwie strukturieren und sortieren musst du es für Menschen ja in jedem Fall ab einer gewissen Anzahl möglicher Werte, da man ansonsten den Überblick verliert. Du kannst (oder solltest) weder im Wiki noch im JOSM-Menue (z.B.) hundert Werte untereinander haben. Das gelingt JOSM jetzt schon (siehe Vorlagen-Menü Einrichtungen - Gesundheit), und auch im Wiki ist es kein Problem, z.B. auf Map Features ein Tag wie junction=roundabout unter die thematisch passende Überschrift Highway zu stellen. Warum nicht also schon eine Struktur im Datenformat abbilden? Weil das beim Finden nicht weiter hilft, da ja die Strukturierung nicht auf die Verankerung im Datenformat angewiesen ist, siehe oben. Ein (neuer) Mapper könnte außerdem, wenn er die Werte nicht nachschlagen kann oder will, schonmal „healthcare=yes“ mit „fixme=*“ mappen. Inwiefern hilft das dem erfahrenen Mapper - sei es derselbe Mapper zu einem späteren Zeitpunkt oder ein Kollege - beim Vervollständigen des Eintrags? Er hat ohnehin Zugang zum fixme=add dentist und braucht das healthcare=yes daher nicht. Und die die Daten verarbeitenden Anwendungen können anhand des Schlüssels schon mal ungefähr auswerten um was es sich handelt, auch wenn sie den genauen Wert nicht kennen sollten. Also dass es sich z.B. um einen Laden handelt oder in dem Fall um eine Gesundheitseinrichtung. Dann weiß der Anwender, dass sich dort ein Krankenhaus, eine Hebamme, ein Alternativmediziner oder vielleicht doch eine Lagerstätte für Blutkonserven befindet. Findest du das wirklich nützlich? Mit einem name=Hans-Meier-Krankenhaus weiß man natürlich mehr. Aber dann ist der Name das Nützliche, nicht das healthcare=*, und der Name wäre auch mit einem amenity=* noch ähnlich gut auffindbar. Der bei weitem wichtigste Punkt ist aber meiner Meinung nach der erste. Und den könnten wir ohne Änderung des Datenmodells umsetzen. Tobias Knerr ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Reboot-Nachlesen
Am 31.10.2010 20:52, schrieb Élisée Reclus: Am 31.10.2010 20:24, schrieb Tobias Knerr: Dieselbe Frage stellt sich aber auch z.B. bei amenity=hospital mit sogar 55.000 Verwendungen. Welches Vorgehen ist vorgesehen, um das in den Daten und den zahlreichen Anwendungen zu ändern? Sinnvoll wäre meiner Meinung nach zuallererst ein Robot-Durchlauf, der allen amenity=hospital ein zusätzliches healthcare=hospital zuweißt. Die Anwendungen müssen dann per Hand geändert werden. Nach einer Übergangszeit für die Umstellung der Anwendungen sollte ein zweiter Robot-Durchlauf die doppelten amenity=hospital löschen. Moin ! kann man eigentlich irgendwo solche reboot-aktionen nachlesen damit man seine app anpassen kann ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Healthcare-Proposal
Am 01.11.2010 10:39, schrieb Tobias Knerr: Das gelingt JOSM jetzt schon (siehe Vorlagen-Menü Einrichtungen - Gesundheit), und auch im Wiki ist es kein Problem, z.B. auf Map Features ein Tag wie junction=roundabout unter die thematisch passende Überschrift Highway zu stellen. Natürlich kannst du auch über Umwege und Krücken wieder alles halbwegs sortieren. Aber besser ist es meiner Meinung nach gleich alles sortiert und so einfach wie möglich zu halten. Als Vorbild für Ordnung und Übersichtlichkeit solltest du meiner Meinung nach wirklich nicht das Wiki anführen. Das ist ziemlich chaotisch. Ich habe vor nicht all zu langer Zeit erst bei OSM angefangen und ich kann wirklich nicht sagen, dass ich mich im Wiki zurechtgefunden habe. Es freut mich, wenn !i! und Verbündete da aufräumen wollen. Warum nicht also schon eine Struktur im Datenformat abbilden? Weil das beim Finden nicht weiter hilft, da ja die Strukturierung nicht auf die Verankerung im Datenformat angewiesen ist, siehe oben. Eigentlich schon. Ich denke, dass es v.a. wichtig ist es neuen Mappern leicht zu machen. Die Leute, die schon lange dabei sind, finden sich eh zurecht (und wissen alles besser). Inwiefern hilft das dem erfahrenen Mapper - sei es derselbe Mapper zu einem späteren Zeitpunkt oder ein Kollege - beim Vervollständigen des Eintrags? Er hat ohnehin Zugang zum fixme=add dentist und braucht das healthcare=yes daher nicht. Dem erfahrenen Mapper hilft es vmtl. nicht, aber die Information „healthcare=yes“ hat jedenfalls schonmal eine Bedeutung und ist automatisch auswertbar. Dann weiß der Anwender, dass sich dort ein Krankenhaus, eine Hebamme, ein Alternativmediziner oder vielleicht doch eine Lagerstätte für Blutkonserven befindet. Findest du das wirklich nützlich? Natürlich finde ich das nützlich. Mit einem name=Hans-Meier-Krankenhaus weiß man natürlich mehr. Aber dann ist der Name das Nützliche, nicht das healthcare=*, und der Name wäre auch mit einem amenity=* noch ähnlich gut auffindbar. Es ist ja nicht so, dass das Setzen von „name=foo“ verboten wäre. Natürlich kann das auch nützlich sein. Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Reboot-Nachlesen
Am 01.11.2010 10:40, schrieb Jan Tappenbeck: kann man eigentlich irgendwo solche reboot-aktionen nachlesen damit man seine app anpassen kann ? Ich muss leider sagen, dass ich da keine Ahnung habe. Es gibt natürlich die Announce- und die Dev-Mailingliste. Es wäre schön wenn so etwas darüber bekannt gemacht würde. http://lists.openstreetmap.org/listinfo/announce http://lists.openstreetmap.org/listinfo/dev Entwickler von OSM-Anwendungen sollten diese Liste eigentlich lesen. Grüße Élisée Reclus ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Feinkost
2010/11/1 fx99 f...@vollbio.de: jan99 wrote: hat einer eine Idee für Feinkostgeschäfte ? wie wär's mit deli ? +1, shop=deli wird bereits 279 mal genutzt. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. -- View this message in context: http://gis.638310.n2.nabble.com/neue-Lizenz-tp5689277p5693489.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 1. November 2010 12:07 schrieb Peter Körner osm-li...@mazdermind.de: Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. die meisten hätten auch nicht das juristische Verständnis, die Lizenz und Ihre Implikationen bis ins Letzte zu verstehen, wenn es eine juristisch verbindliche Übersetzung gäbe. Ich sehe es auch so, dass es Geldverschwendung wäre, eine solche über das rechtlich erforderliche Maß (Italien fordert es z.B. gesetzlich, dass es eine italienische Version gibt, damit es in Italien gilt) für alle möglichen Sprachen (und Jurisdiktionen) anzufertigen. Anwälte kosten sehr viel Geld, das ich anders besser ausgegeben sehe. Wer sich da bei der OSMF beschwert sollte sich vielleicht eher bei der dt. Regierung beschweren. Ich glaube ausserdem, dass die allermeisten der genaue Text der Lizenz nicht so wichtig ist, solange diese frei ist und bestimmte Teile wie Attribution und ggf. share-alike fordert. Sooo viel ändert sich ja nicht durch die Anpassung von Werken (die wir aber immer schon eigentlich für Daten wollten) auf Daten. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Am 1. November 2010 12:26 schrieb fx99 f...@vollbio.de: Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. Einen verbindlichen dt. Text zu fordern halte ich für problematisch. Vermutlich müsste der dann wieder verbindlich ins englische übertragen werden? Es ist ja nicht so, dass man sich nicht auf dt. über die Lizenzfrage informieren kann: http://wiki.openstreetmap.org/wiki/DE:ODbL/We_Are_Changing_The_License http://wiki.openstreetmap.org/wiki/DE:ODbL/Why_CC_BY-SA_is_Unsuitable http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Implementation_Plan Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Ich finde ja auch, dass das eigentlich ja auch von der OSMF besser (na ja eigentlich überhaupt) erklärt werden sollte. Aber das ungeschickte, bis nicht vorhandene Marketing um die CTs ist ein anderes Thema. Simon - Original Message - From: Peter Körner osm-li...@mazdermind.de To: Openstreetmap allgemeines in Deutsch talk-de@openstreetmap.org Cc: Simon Poole si...@poole.ch Sent: Monday, November 01, 2010 12:07 PM Subject: Re: [Talk-de] (neue) Lizenz Am 01.11.2010 08:27, schrieb Simon Poole: Ich sehe auch das Problem des OP nicht ganz Es geht einzig und allein um's Bauchgefühl. Das fehlen einer deutschen Übersetzung gibt - zumindest mir - das Gefühl, dass die Entscheider sich keine Gedanken drum gemacht haben, dass nicht jeder des englischen so mächtig ist; und das obwohl ich den Lizenztext bereits gelesen, verstanden und bestätigt habe. Lg, Peter ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] (neue) Lizenz
Wie schon geschrieben: es ist im Interesse aller die Anzahl der Übersetzungen auf das Minimum zu beschränken. Nur schon die Wartung jeder Übersetzung wird sofort zu einem Problem (nur als Beispiel kommen ja irgendwann bald die CTs 1.1). Und wenn auch der deutschsprachige Teil von OSM sehr gross ist, muss man doch sehen, dass andere Sprachregionen genau die gleichen, durchaus berechtigten, Einwände machen könnten. Irgendwo muss man die Grenze ziehen ansonsten wird's einfach endlos. Nochmals: die OSMF wird vermutlich keine deutschsprachige Version der Lizenz akzeptieren, d.h. man würde, auch wenn eine beglaubigte Übersetzung vorliegt, immer noch die englische Version annehmen müssen. In der Situation sehe ich keinen Vorteil darin neben der aktuellen inoffziellen noch eine weitere (auch inoffizielle) Übersetzung zu haben. Simon - Original Message - From: fx99 f...@vollbio.de To: talk-de@openstreetmap.org Sent: Monday, November 01, 2010 12:26 PM Subject: Re: [Talk-de] (neue) Lizenz Es wäre meiner Meinung nach viel effizienter, wenn sich eine Hand voll OSMF-ler einen verbindlichen deutschen Annahme-Text ausdenken (muss ja nicht eine eins-zu-eins Übersetzung sein), als wenn sich tausende deutscher Mapper den Kopf darüber zerbrechen und diskutieren, was denn mit dem Text gemeint ist. -- View this message in context: http://gis.638310.n2.nabble.com/neue-Lizenz-tp5689277p5693489.html Sent from the Germany mailing list archive at Nabble.com. ___ 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] (neue) Lizenz
Am 01.11.10 schrieb Peter Körner: Es geht einzig und allein um's Bauchgefühl. Falls es Deinem Bauchgefühl hilft: zumindest die deutsche Übersetzung der CTs[1] (Teilnahmevereinbarung) war letzten Dienstag Thema der Lizenzarbeitsgruppe[2]. Gruß, Fabian. [1] http://wiki.openstreetmap.org/wiki/DE:Open_Database_License/Contributor_Terms [2] http://www.osmfoundation.org/wiki/Working_Group_Minutes___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] ÖPNVKarte - Neuigkeiten?
Hallo zusammen! Falls das eine FAQ ist, sorry. Aber ich habe weder auf öpnvkarte.de, noch auf der deutschen und englischen OSM-Wiki-Seite etwas darüber finden können. Im Listenarchiv sah ich nur, dass Anfang September etwas von einem Serverumzug geschrieben wurde, aber seitdem konnte ich auch nix mehr finden. Auf der Webseite selbst steht auch Stand September. Zur Zeit keine Updates. Weiß jemand mehr darüber und wann es wieder Updates gibt? Ist Melchior nur einfach im Urlaub oder ist hier längerfristig mit Problemen zu rechnen? Kennt jemand eine schöne Alternative? Wir waren nämlich eigentlich gerade dabei, unser ÖPNV-Netz in Landshut zu erfassen - und da ist eine schön gerenderte Karte natürlich ein guter Ansporn... :-) -- Gernot ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Chris66 wrote: Schade dass der Address-Inspector von der GeoFabrik immer noch keine Konsistenzprüfung KA-Schema vs. PLZ-Polygone machen kann. schöne idee ;) - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5693827.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Chris66 schrieb: In Marl zB. sind die Adressen von der Stadtverwaltung gestiftet und importiert worden, da könnte man also schön die PLZ-Polygone danach ausrichten, wenn es nicht so aufwändig wäre. Oder kennt jemand einen Trick wie man in JOSM die Adress-Nodes zB. je nach letzten beiden Stellen der PLZ einfärben kann. (zB ...72 rot, ...76 grün). Ich würde einfach den entsprechenden Filter für jede PLZ nacheinander nehmen. Dem dicken gelben Buch zufolge git es in Marl nur drei PLZ-Zonen. -- Gruß, André Joost ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Wie ist denn nun die allgemeine Meinung: sollen es jeweils eindeutige (unique) keys sein, oder soll die Bedeutung (ggf. auch) kontextabhängig sein? Je früher man solche Fragen klärt, um so eher kann man konsistent weitermachen. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo, nachdem mein Programm welches ich derzeit entwickle mal wieder aufgrund einer Null-Pointer-Exception abgeschmiert ist, ist mir aufgefallen, dass die Extrakte der Geofabrik teilweise Fehler in der Datenlogik aufweisen. Mir ist klar, dass es nicht ganz trivial ist einen Bereich auszuschneiden (es geht hier, mal wieder, um Berlin, aber mMn darf es nicht passieren, dass dabei Daten entstehen die schlicht falsch sind. Der Way 77487735 [1] hat einen Knoten der genau auf der Berliner Stadtgrenze liegt. Dementsprechend ist er Way auch im Extrakt enthalten, was ja auch richtig ist. Allerdings sind alle Knoten entfernt, die nicht innerhalb der Grenzen Berlins liegen. Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Ein Weg/Kante kann nicht nur aus einem Knoten bestehen. Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Danke Tom [1] http://www.openstreetmap.org/browse/way/77487735 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 01.11.2010 15:54, schrieb M∡rtin Koppenhoefer: Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Und noch ein Beispiel: bicycle=yes an Barrieren heisst: hier können Fahrräder passieren; an Wegweisern (information=guidepost) bedeutet es: Hier gibt's Infos für Radfahrer. Interessant wird es, wenn der Wegweiser an einer Barriere befestigt ist. ;-) Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Ich hab mir perl (offline) Skripte gechrieben, mit dem ich addr:postcode gegen das durch die PLZ Relation umschlossenen Gebiet teste. Das Ergebnis ist z.B. dargestellt in: http://wiki.openstreetmap.org/wiki/Stuttgart/PLZ Zusätzlich kommt noch eine Datei mit den falschen PLZs heraus. Eingaben: 1. bounding box für das gesamt Gebiet 2. Liste mit Relationsnummer und PLZ der PLZ Gebiete. Bei Interesse PN schicken. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5694327.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
On Mon, Nov 01, 2010 at 03:54:56PM +0100, M∡rtin Koppenhoefer wrote: Am 31. Oktober 2010 11:04 schrieb Jochen Topf joc...@remote.org: Do not use generic words for keys Ich habe dazu auch nochmal was gefunden, wo das Kind sozusagen schon im Brunnen scheint: http://wiki.openstreetmap.org/wiki/Key:service das wird sowohl für highway als auch für railway verwendet. Gutes Beispiel. Wenn man auf http://taginfo.openstreetmap.de/keys/service schaut, dann sind die häufigsten Values: parking_aisle, driveway, alley, spur, yard, siding, parking, yahoo aerial images, dealer;repair, parts, ... Offensichtlich ist das eine wilde Mischung aus Zusatztags für highway, railway und shop. M.E. ein klarer Fall, wo das in mehrere Tags aufgelöst gehört. Auch operator ist ein Key, wo ggf. die Bedeutung sich je nach Kontext ändert. Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
On Mon, Nov 01, 2010 at 04:16:42PM +0100, Tom Müller wrote: nachdem mein Programm welches ich derzeit entwickle mal wieder aufgrund einer Null-Pointer-Exception abgeschmiert ist, ist mir aufgefallen, dass die Extrakte der Geofabrik teilweise Fehler in der Datenlogik aufweisen. Mir ist klar, dass es nicht ganz trivial ist einen Bereich auszuschneiden (es geht hier, mal wieder, um Berlin, aber mMn darf es nicht passieren, dass dabei Daten entstehen die schlicht falsch sind. Der Way 77487735 [1] hat einen Knoten der genau auf der Berliner Stadtgrenze liegt. Dementsprechend ist er Way auch im Extrakt enthalten, was ja auch richtig ist. Allerdings sind alle Knoten entfernt, die nicht innerhalb der Grenzen Berlins liegen. Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Ein Weg/Kante kann nicht nur aus einem Knoten bestehen. Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Diese Fragen kommen wieder und wieder. Leider gibt es keine Ausschneidelogik, die für alle Anwendungsfälle richtig ist. Und leider sind manche Logiken auch deutlich aufwändiger in der Durchführung als andere. Daher ist das einfach ein Kompromiss. Das Ausschneiden passiert mit dem Programm Osmosis, das verschiedene Optionen hat, um die Logik einzustellen. Wenn Du selbst die Daten ausschneidest, kannst Du Dir selbst auswählen, welche Logik Dir am besten passt. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am 01.11.2010 17:52, schrieb fx99: Ich hab mir perl (offline) Skripte gechrieben, mit dem ich addr:postcode gegen das durch die PLZ Relation umschlossenen Gebiet teste. Das Ergebnis ist z.B. dargestellt in: http://wiki.openstreetmap.org/wiki/Stuttgart/PLZ Zusätzlich kommt noch eine Datei mit den falschen PLZs heraus. Eingaben: 1. bounding box für das gesamt Gebiet 2. Liste mit Relationsnummer und PLZ der PLZ Gebiete. Bei Interesse PN schicken. Supi. Irgendwie müsste man noch die Großkundensondernummern kennzeichnen, damit die aus der Prüfung ausgenommen werden können. Gibts da schon sowas in der Art addr:postcode:type=company ? Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS un d Galileo für bessere Navigation
Es ist doch sowieso schon seit 2004 bekannt das GPS und GALILEO kompatibel sein werden. Also was will mir die Meldung bei Golem nun diesbezüglich eigentlich sagen? Wieso muss da noch was 'erforscht' werden ? Hallo Zusammen, ja, diese Meldung ist noch etwas speziell und Zukunftsmusik: golem: Napa: Kombination aus GPS und Galileo für bessere Navigation http://www.golem.de/1010/78985.html Es geht darum, dass u.a. Firmen IMST als Projektkoordinator, Navigon, Navteq, das Fraunhofer-Institut für Integrierte Schaltungen, die Navcert GmbH sowie der Lehrstuhl für Integrierte Analogschaltung (IAS) der RWTH Aachen und die Universität Koblenz daran forschen a) ein Empfangsmodul für GPS und Galileo für Fussgänger mit 1 m Genauigkeit entwickeln aber auch b) Dabei sollen zusätzliche Informationen zu Straßen und Fußwegen in die Karten integriert werden, um beispielsweise die Anzeige von Zebrastreifen und Ampeln sowie Unterführungen anzuzeigen. Da hat es für mich dann den Bogen zu OSM geschlagen, da ich es praktisch fände, wenn OSM Aktivisten frühzeitig zumindest mal den IST-Stand kommuniziert bekommen, um dies für aktuelle Entwicklungen direkt zu berücksichtigen und man nicht erst anfängt OSM dahingehend vorzubereiten, wenn diese Gruppe fertig ist. Oder bin ich da zu voreilig? Hat da jemand Kontakte? ___ 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
[Talk-de] Multiliguale Liste mit den Keys
gibt es eigentlich irgendwo eine mehrsprachige Liste der Keys um diese in App einzubauen - die man ggf. per Download irgendwo automatisch ziehen könnte. Bei manchen wäre eine Kombi aus key = value erforderlich bei anderen nur der Key (z.b. maxspeed). Gruß jan :-)Überprüft mit AntiVir MailGuard v10.0.1.27 AVE 8.2.4.86 VDF 7.10.13.76___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am 1. November 2010 18:00 schrieb Jochen Topf joc...@remote.org: operator Da kann man sich auch auf den Standpunkt stellen, dass das eher wie name ein Tag mit beliebigen textuellen Werten ist, der übergreifend benutzt werden kann. Bin ich mir auch nicht sicher. ja, wobei auch width und sowas ja nicht statistisch ausgewertet wird, sondern freie Werte üblich sind. Trotzdem will man da Klarheit haben, was gemeint ist. D.h. Definition und Dokumentation. ist Man darf m.E. nicht nur auf Taginfo und ähnliches in der jetzigen Form schielen, wie es da am einfachsten ist, eine Auswertung zu machen, evtl. müsste man dort auch nochmal eine Unterscheidung treffen, in welchem Kontext ein Tag verwendet wird. Grundsätzlich sind verschiedene Bedeutungen desselben Tags wie bei service (übrigens bisher AFAIK wenigstens mit unique values) eigentlich kein Problem, solange es bei den Kombinationen keine Überschneidungen gibt (also z.B. ein way railway und highway gleichzeitig wäre). Bisher steht eigentlich nur fest, dass unique keys die Auswertung erleichtern und es andererseits dem Mapper geringfügig schwieriger machen, da sich das Vokabular vergrößert. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 18:04 schrieb Jochen Topf joc...@remote.org: Dies resultiert in diesem Fall in einem Way mit nur einem Knoten. Das ist dann schlichtweg eine fehlerhafte Datenstruktur! Das Ausschneiden passiert mit dem Programm Osmosis, das verschiedene Optionen hat, um die Logik einzustellen. Wenn Du selbst die Daten ausschneidest, kannst Du Dir selbst auswählen, welche Logik Dir am besten passt. m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug (sollten unabhängig von der ausgewählten Logik nicht enthalten sein). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] golem: Napa: Kombination aus GPS und Gali leo für bessere Navigation
re, * 007 northc...@gmx.de [2010-11-01 18:47]: Es ist doch sowieso schon seit 2004 bekannt das GPS und GALILEO kompatibel sein werden. Also was will mir die Meldung bei Golem nun diesbezüglich eigentlich sagen? Wieso muss da noch was 'erforscht' werden ? und eigentlich wollte ich gar nicht auf die Technik hinaus :/ b) Dabei sollen zusätzliche Informationen zu Straßen und Fußwegen in die Karten integriert werden, um beispielsweise die Anzeige von Zebrastreifen und Ampeln sowie Unterführungen anzuzeigen. Da hat es für mich dann den Bogen zu OSM geschlagen, da ich es praktisch fände, wenn OSM Aktivisten frühzeitig zumindest mal den IST-Stand kommuniziert bekommen, um dies für aktuelle Entwicklungen direkt zu berücksichtigen und man nicht erst anfängt OSM dahingehend vorzubereiten, wenn diese Gruppe fertig ist. Oder bin ich da zu voreilig? Hat da jemand Kontakte? -- Grüße, Benny gpg 0xFC505AB0 jabber be...@benny.de sip be...@benny.de signature.asc Description: Digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Bei all den Diskussionen sollte auch der Nutzen von OSM berücksichtigt werden. eben Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Das einzige Problem ist und bleibt natürlich die nun ausführlich geführte Ist das jetzt ein Service oder nicht-Diskussion. schön wärs, Probleme gibt's natürlich noch viele. Hier treffen tatsächlich zwei unterschiedliche OSM-Sichtweisen aufeinander. a) Nutzen, b) Straßenbewertung (WYSIWYG). Nutzen ist kein absolutes Kriterium, solange die Daten die benötigte Information enthalten wird man immer einen Nutzen daraus ziehen können. Straßenbewertung ist ebenfalls ziemlich allgemein gehalten und kann alles bedeuten. WYSIWYG ist eher ein Editorfeature als eine Datenbankregel, vermutlich meinst Du damit das zu taggen, was man vor Ort sieht. Das passt auf physische Eigenschaften wie Oberfläche, Breite etc., aber eben nicht auf die highway-Klassifikation. So z.B. scheinen level_crossings den Taggern nicht wirklich wichtig, weil sieht man ja, dass da Straße und Schiene kreuzen... Nur ein Routing-Topologie-Erzeuger sieht das eben nicht!!! doch klar, sieht er an dem gemeinsamen Node. Das level_crossing dient nur dazu, auszudrücken, dass man es wirklich so meint. Eine Schiene, auf der ein Autozug verkehrt, die wiederum eine Straße kreuzt ... ziemlich heftig, dies ohne level_crossing auseinanderzuhalten! ob da ein Autozug verkehrt oder nicht spielt überhaupt keine Rolle, solange man da nicht von der Straße auf den Zug abbiegen kann. Ja natürlich sind hier Schiene und Strasse mit dem selben Knoten verbunden, weil (WYSIWYG) ist ja so. ... (Aber ist eben Mist). wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Ich kann mich da nur wiederholen. Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! Ich selbst hab's auch versucht, einen Algo geschrieben, der in noch einigermaßen vertretbarer Zeit die Daten von OSM routingfähig rechnet und das Ganze mal durchgespielt. Mein Fazit ist dabei relativ eindeutig ausgefallen und spiegelt sich in meinen Kommentaren in diesem Thread wider. Wenn es hier also jemanden gibt, der es geschafft hat, seine OSM-Daten routingfähig zu kriegen und dabei sämtliche OSM-Relationen berücksicht, der möge sich bitte melden. SuperComputer-Benutzer sind von dieser Umfrage allerdings ausgeschlossen ;-) Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
On 01.11.2010 20:09, M∡rtin Koppenhoefer wrote: m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug Das hatten wir schon mal, ist etwas über ein Jahr her. Wege komplett ohne Nodes habe ich damals als Ergebnis der Diskussion gelöscht: http://www.openstreetmap.org/browse/changeset/2250280 Die hatten damals auch schon länger keine Nodes mehr. Wege mit nur einem Node hatten wir IMHO auch angesprochen, dann aber stehen gelassen weil es dafür eventuell Gründe geben könnte. Mir persönlich wäre auch lieber wenn ein way aus 2 oder mehr Nodes bestehen muss. Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: 48238597 23907650 83584123 83584739 82651049 83602048 83602054 83633771 Da könntest du dir fast schon jeden von Hand ansehen und bei Bedarf aufräumen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] PotM - Oktober 2010 - Trinkwasser - Abschluss
Moin ! ich habe die Abschlussstatistik im Wiki hinterlegt: http://wiki.openstreetmap.org/wiki/DE:Project_of_the_month/2010/october#Statistik Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 01.11.2010 21:18, schrieb Carsten Moeller: Am 31.10.2010 10:02, schrieb aighes: Die Beherrschbarkeit sehe ich noch nicht in Gefahr. Leider sehe ich die ganz ernsthaft in Gefahr. Man muss sich als Router/Renderer gedanken machen, was wichtig ist und was nicht. Wenn die Mapper zwischen einem Hundekottütenspender für Schäferhunde und einem für Pudel unterscheiden wollen, können sie dies gerne in der Form amenity=Hundekottütenspender dog=pudel tun. *LOL* Ob ein Renderer das nun auswertet ist eine andere Frage. Das ist doch gerade ein Vorteil von unserem System Haupttags mit Zusatztags. aber was ist, wenn der Pudel plötzlich aufgrund irgend einer Sichtweise wichtiger wird als der Spender? z.B. tag=irgendwas motorcar=yes??? Viele Grüße, aighes Gruß, Carsten. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Kleiner Zusatz noch: Oder auch schon gesehen: railway=rail + highway=residential + motorcar=yes als ein Weg! War eigentlich auch richtig, weil Brücke (was fehlte), aber letztere interessiert einen Router eigentlich nicht. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 01.11.2010 21:08, schrieb Stephan Knauss: On 01.11.2010 20:09, M∡rtin Koppenhoefer wrote: m.E. hier allerdings in Bug von Osmosis, da Wege gem. Definition aus 2 bis 2000 Nodes bestehen müssen (können), d.h. Wege mit einem Node sind in jedem Fall ein Bug Das hatten wir schon mal, ist etwas über ein Jahr her. Wege komplett ohne Nodes habe ich damals als Ergebnis der Diskussion gelöscht: http://www.openstreetmap.org/browse/changeset/2250280 Die hatten damals auch schon länger keine Nodes mehr. Wege mit nur einem Node hatten wir IMHO auch angesprochen, dann aber stehen gelassen weil es dafür eventuell Gründe geben könnte. Mir persönlich wäre auch lieber wenn ein way aus 2 oder mehr Nodes bestehen muss. Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: 48238597 23907650 83584123 83584739 82651049 83602048 83602054 83633771 Da könntest du dir fast schon jeden von Hand ansehen und bei Bedarf aufräumen. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de Tschuldigung kurz zwischengegrätscht zu haben Bei dieser Analyse sollte man evtl auch aufanderfolgend gleiche Knotenreferenzen und ggf. unterschiedliche Referenzen mit gleichen Koordinaten mit einbeziehen und ggf. wenn unsinnig reduzieren. Dann werden's schon ein paar mehr Ein-Knoter. Gruß, Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo! Tom Müller-2 wrote: Vielleicht kann man da die Ausschneidelogik etwas abändern, das solche Fehler nicht mehr auftreten können? Entlang eines Osmosis-Schnittes finden sich meistens solche und andere Artefakte. Es ist empfehlenswert, das nächstgrößere Extrakt herunterzuladen und selbst mit Osmosis und den gewünschten Einstellungen die Daten auszuschneiden - am Besten noch mit ein wenig zusätzlichem Platz um den gewünschten Bereich herum. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Exporte-teilweise-fehlerhaft-in-Datenlogik-tp5694060p5695109.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Chris66 wrote: Supi. Irgendwie müsste man noch die Großkundensondernummern kennzeichnen, damit die aus der Prüfung ausgenommen werden können. Gibts da schon sowas in der Art addr:postcode:type=company ? Meiner Meinung nach hat die PLZ eines Großkunden wenig mit der Adresse zu tun. Warum nicht einfach mit postal_code=... taggen. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5695128.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte - Neuigkeiten?
Hi Am 01.11.2010 14:26, schrieb Gernot Hillier: Auf der Webseite selbst steht auch Stand September. Zur Zeit keine Updates. Weiß jemand mehr darüber und wann es wieder Updates gibt? Ist Melchior nur einfach im Urlaub oder ist hier längerfristig mit Problemen zu rechnen? Ausschnitt aus dem Seitenquelltext: div align=center Copyright (C) 2009 by Melchior Moosbr / Datenstand der Openstreetmap-Daten: Anfang September 2010, momentan keine Updates!br / Warum es keine aktualisierte Karte mehr gibt weiß ich auch nicht. Ein Update ab und zu wäre schon nett. Kennt jemand eine schöne Alternative? Außer selber rendern fällt mir auf Anhieb auch nichts ein. Gruß Carsten ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:47:58 schrieb Jochen Topf: Ganz absurd wird es, wenn es wie im aktuellen healthcare-Vorschlag einen Tag specialty gibt, der die Art des Mediziners angeben soll, um den es hier geht. das kann ich jetzt gar nicht nachvollziehen... Aber wenn ich das wiederverwenden will, z.B. mit specialty=italian an einem Restaurant oder specialty=football bei einem Sportverein. Dann habe ich total verschiedene Dinge miteinander vermischt. Will ich jetzt im Editor eine Auswahlbox einbauen, die mir eine Auswahl der wichtigsten Werte erlaubt, dann muss ich berücksichtigen, ob ein heathcare, restaurant oder sports-Tag zusätzlich hier dran ist. Ja, und? kontextabhaengige Menues sind nichts besonderes. Schau ich eine Statistik der Werte an, finde ich alle möglichen wild durcheinander. Das Wort speciality ist zu generisch, es sagt eigentlich nichts aus, außer dass hier eine hierarchische Unterordnung stattfinden will. das ist doch eine Aussage?! Es wird niemals Sinn machen, die specialty-Fälle von healthcare und restaurant zusammen zu betrachten, so wie man z.B. im Falle von name gerne eine gemeinsame Suche hätte, sodass man nach Straßennamen und dem Namen von Medizinern suchen kann. und deswegen soll man nicht dasselbe Tag verwenden duerfen? Betrachte specialty als generisches Tag, das einfach als genauere Spezifizierung des Haupttags benutzt wird. Das ist besser und v.a. einfacher, als fuer jede einfache Spezifizierung einen neuen Key zu erfinden... Ich muss da Martin vollstaendig recht geben: So speziell wie noetig, aber so generisch wie moeglich. Natürlich gibt es hier keine perfekte Definition, wie man diese Fälle auseinanderhalten kann. Es gibt eher einen fließenden Übergang. Vielleicht will man einer Brücke einen anderen Namen geben als der Straße darauf, dann wäre ein bridge_name nicht schlecht. Sollte so ein Fall noetig sein, dann wuerde ich dafuer name:bridge bzw. name:street nehmen. Denn in erster Linie ist es immer noch ein Name wie jeder andere auch - der halt in diesem speziellen Fall fuer einen bestimmten Teil des Objekts gilt. Hier hilft es auch, sich zu überlegen, was denn der typische, häufige Fall ist und was eher ein Spezialfall. Bei Namen will man sicher auch mal Namen bestimmter Objekte auf verschiedene Arten schreiben. Aber notfalls reicht es eben, alle gleich zu schreiben. Bei einem ref glaube ich da schon weniger dran. Ich will sicher keine Bushaltestellen-Bezeichner haben, die aussehen wie die typischen Straßensymbole (highway shields). Der einfache Fall sollte einfach sein (also vorallem nicht die Kombination mehrerer Tags erfordern), Spezialfälle aber durchaus. Bei ref macht eine Unterscheidung wesentlich mehr Sinn, als bei name, ja. Aber auch hier kann man die Bedeutung des Tags in den meisten Faellen vom Kontext ableiten. Fuer Spezialfaelle kann man immer noch sowas wie ref:highway bzw. ref:bridge verwenden. signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Best Practice fürs Erfinden von Tags
Am Sonntag 31 Oktober 2010, 19:56:54 schrieb Karl Eichwalder: Bernd Wurst be...@bwurst.org writes: Also klar, ein paar Ausnahmen gibt es: name, comment, solche Dinge, die hat beinahe jedes Objekt und ein Name ist ein Name, damit kann jeder Daten- Verwerter etwas anfangen: Er kann ihn einfach anzeigen. Manche dinge haben allerdings zwei doer mehr namen; standardbeispiel: straße auf einer brücke. Das können wir so ohne weiteres nicht abbilden. name:highway = foo name:bridge = bar signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hallo Carsten, On 01.11.2010 21:48, Carsten Moeller wrote: Am 01.11.2010 21:08, schrieb Stephan Knauss: Eine schnelle Suche in der mapnik-db liefert folgende 8 Wege mit nur einem Node: [...] Bei dieser Analyse sollte man evtl auch aufanderfolgend gleiche Knotenreferenzen und ggf. unterschiedliche Referenzen mit gleichen Koordinaten mit einbeziehen und ggf. wenn unsinnig reduzieren. Dann werden's schon ein paar mehr Ein-Knoter. Ja, da hast du recht. Technisch gesehen (aus sicht der API) hat der Weg dann aber schon mehr als einen node. Eben mehrfach einen gleichen. Dass es dann noch nodes mit unterschiedlichen IDs auf gleicher Koordinate geben kann kommt dazu. Ich hätte mir gewünscht, dass die API zumindest die Anzahl 2 oder mehr fordert. Und wenn die Prüfung nicht zu teuer wird auch gerne die verschärfte Variante mindestens 2 verschiedene Node-IDs. So lange das die API nicht einfordert ist es an den Editoren bzw. den Mappern das entsprechend anzuwenden oder hinterher aufzuräumen. Schweift aber langsam etwas von der Ursprungsfrage ab. Ich halte es jedenfalls nicht für einen Bug des Extracts wenn da ein way mit weniger als 2 Nodes enthalten ist. Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Am 1. November 2010 23:11 schrieb Stephan Knauss o...@stephans-server.de: Ich halte es jedenfalls nicht für einen Bug des Extracts wenn da ein way mit weniger als 2 Nodes enthalten ist. ich beziehe mich auf http://wiki.openstreetmap.org/wiki/Way A way is an ordered interconnection of at least 2 and at most 2,000[1] bzw. [1] http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/config/application.yml (scheint nicht zu funktionieren) wenn die Info da falsch im Wiki steht sollte man es m.E. ändern. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Exporte teilweise fehlerhaft in Datenlogik
Hi! M∡rtin Koppenhoefer wrote: ich beziehe mich auf http://wiki.openstreetmap.org/wiki/Way A way is an ordered interconnection of at least 2 and at most 2,000[1] bzw. [1] http://trac.openstreetmap.org/browser/sites/rails_port_branches/api06/config/application.yml (scheint nicht zu funktionieren) wenn die Info da falsch im Wiki steht sollte man es m.E. ändern. Das sind zwei Paar Stiefel. Das Wiki beschreibt die Daten in der OSM Datenbank und ist korrekt. Die lokale Verarbeitung mit anderer Software wie z.B. Osmosis wird davon nicht berührt. bye Nop -- View this message in context: http://gis.638310.n2.nabble.com/Geofabrik-Exporte-teilweise-fehlerhaft-in-Datenlogik-tp5694060p5695365.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 1. November 2010 21:02 schrieb Carsten Moeller cmindivid...@gmx.de: Hat sich eigentlich schon mal jemand hier darüber Gedanken gemacht, warum ein Laden wie Cloudmade es nicht hinkriegt, jemanden per Autozug oder Fähre nach Westerland zu routen? Ich glaube nicht, dass es denen an klugen Köpfen mangelt! die bekommen es auch nicht hin, neue Daten zeitnah in Ihre Renderings zu übernehmen, oder einen schönen Renderstil zu entwickeln, wieso sollte das ein Kriterium sein? Bei ÖPNV ist allerdings neben den Routen auch ein Fahrplan nötig, damit man sinnvoll routen kann damit --- zumindest wenn nicht jede halbe Stunde eine Fähre geht. Für die reine Route des ÖPNV reicht im Prinzip die Liste der Haltepunkte weil es keine Rolle spielt, welchen genauen Weg das Mittel dafür nimmt (Strecke und Zeit wären natürlich nicht schlecht). Fürs Routing interessant ist dann wie oben schon gesagt in erster Linie der Fahrplan. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
wei postal_code für strassen ist. - Der Usus von Xenologismen ist auf ein Minimum zu reduzieren. -- View this message in context: http://gis.638310.n2.nabble.com/PLZ-Import-tp5682563p5695395.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Online-Befragung der OSM-community - community-Daten zu gewinnen!
War es das hier?: http://blog.fefe.de/?ts=b29afd7d genau das wars. Okay, die exakte Adresse war nicht dabei, aber ... -- schönen Gruß Alex ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] AIO - Routing über Fähren
Am 31.10.2010 12:47, schrieb M∡rtin Koppenhoefer: Am 31. Oktober 2010 09:34 schrieb Carsten Moellercmindivid...@gmx.de: Doch wenn ich Diskussionen sehe, wo Leute zwischen einem Sportflugplatz oder einem Modellflugplatz trennen wollen, dann wird's komisch. komisch finde ich das nicht. Wir unterscheiden ja z.B. auch zwischen einem See und einer Badewanne. Kann man so nicht wirklich vergleichen! Einen See ist ein Stück der Erdoberfläche die mit Wasser bedeckt ist (abgesehen von den unterirdischen Seen). Eine Badewanne ist ein nach oben offenere Behälter der mit Wasser gefüllt ist. Beide haben im Prinzip nur gemeinsam dass sie mit Wasser gefüllt sind um ihren Zweck zu erfüllen. Ein Flugplatz bzw. Start/Landeplatz ist dagegen ein Stück Land das ausnahmslos dafür definiert ist dass dort regelmässig Boden-Luftübergänge von Fluggeräten stattfinden und von dort eine entsprechende damit verbundene Gefährdung ausgeht die insbesondere alle Luftfahrzeuge (ob Modellflieger oder A380)betrifft. Als Reisender Interessiert mich natürlich nur der Flughafen an dem mein Flug abgeht. Die wenigsten suchen sich ausserdem erst einen Flugplatz - schon gar nicht per Navi - und versuchen von dort aus einen Flug zu ihrem Ziel zu bekommen. Und das ist nunmal die Frage nach dem Wo-Ist-Was und wie komme ich dahin. ja, und wenn das Was alles sein kann vom Modellflughafen bis zum Großflughafen, weil man das in den Daten nicht erkennen kann, dann hätte OSM versagt. Aus der Angabe Flugplatz bzw. Start/Landeplatz kann man nun mal nicht mehr erkennen als das dort eine Luft-Boden Übergang von Fluggeräten stattfindet. Und mehr hineinzuinterpretieren wäre schlichtweg falsch! Eine Angabe des immer(?) dreistelligen Flughafenkürzels das auf jedem Verkehrs-Flugticket zu finden sein sollte hat man eine eindeutige Zuordnung zu welchem Flughafen man muss. wieso das denn? Mist ist es, wenn man die Schiene mit Straßentags taggt, weil dann wirklich nicht mehr klar ist, was da eigentlich los ist. Wenn man einen Autozug taggen will, dann mit entsprechender Route-relation, aber sicher nicht direkt aufs Gleis. Vielleicht sollte man hier Unterscheiden zwischen Punkt-zu-Punkt-Verbindungen in denen die Eisenbahn eine Strasse ersetzt bzw. wintersichere, kurze Verbindungen ermöglicht (Bsp. Sylt, Lötschbergtunnel, Furkatunnel, Vereinatunnel) und den Autoreisezugverbindungen bei denen man einfach nur die eigene Lenkzeit im Fernverkehr verkürzen möchte (Bsp. Lörrach - Hamburg.). Ersteres sollte so ausgelegt sein dass es schon mit einfachen Routern funktioniert die nicht tausende von unterschiedlichen Details auswerten, - in der Regel fährt man dort einfach hin und kann nach rel. kurzer Wartezeit einfach auf den Zug fahren. Hier macht es Sinn dass in das ganz normale Strassenrouting zu integrieren. Zweiteres erfordert mehr Aufwand und wird in der Regel auch deutlich vorher gebucht. Hier macht es ehr keinen Sinn das ins normale Strassenrouting zu integrieren, man gibt als Ziel den Verladebahnhof ein und routet dann vom Entladebahnhof erneut. Für einen Reiseplaner kann man hier mehr Aufwand investieren und diese Alternative vorschlagen. Entsprechendes gilt natürlich auch für Fähren. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] ÖPNVKarte - Neuigkeiten?
Am 01.11.2010 23:00, schrieb Carsten Schönert: Kennt jemand eine schöne Alternative? Außer selber rendern fällt mir auf Anhieb auch nichts ein. Die Tools der Geofabrik lassen einen zumindest vieles anschauen, wenn auch nicht so schön. http://tools.geofabrik.de/osmi/?view=pubtrans_stopslon=6.36052lat=50.81470zoom=14 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] PLZ Import
Am Montag 01 November 2010, 22:00:14 schrieb fx99: Meiner Meinung nach hat die PLZ eines Großkunden wenig mit der Adresse zu tun. Na doch, wenn man ein Gebäude eines Betriebs mit eigener PLZ nach Karlsruhe- Schema tagged, gehört da die wahre PLZ dran. Und die ist dann halt nicht passend zu der anderer Gebäude drum herum. Gruß, Bernd -- Fachbegriffe der Informatik (#367): Patentverhandlungen Beide Firmen drucken ihre Patente aus und legen die Stapel nebeneinander. Der mit dem höheren Stapel hat gewonnen. (Rainer Zocholl zitiert einen Patentanwalt) signature.asc Description: This is a digitally signed message part. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Multipoligoni spariti, problema di rendering?
...ho dato un'occhiata ai due poligoni che ho inserito...ma a parte uno che ho visto hai modificato nella forma non ho capito che altro ho toccato??? -- View this message in context: http://gis.638310.n2.nabble.com/Multipoligoni-spariti-problema-di-rendering-tp5692012p5692993.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Multipoligoni spariti, problema di rendering?
Il giorno 01 novembre 2010 08:41, scratera piz...@alice.it ha scritto: ...ho dato un'occhiata ai due poligoni che ho inserito...ma a parte uno che ho visto hai modificato nella forma non ho capito che altro ho toccato??? -- Sembrerebbe un bug di Mapnik con i multipolygon di grosse dimensioni. Con osmarender non succede. Vedi qui: http://www.openstreetmap.org/?lat=41.50316lon=15.09761zoom=17layers=M -- Ciao /niubii/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Multipoligoni spariti, problema di rendering?
scratera wrote: ...ho dato un'occhiata ai due poligoni che ho inserito...ma a parte uno che ho visto hai modificato nella forma non ho capito che altro ho toccato??? Quando si aggiunge il multipoligono alla relazione occorre anche specificare che ruolo ha nella stessa: il multipoligono esterno ha il role=outer, quelli interni hanno tutti il role=inner ;o) -- View this message in context: http://gis.638310.n2.nabble.com/Multipoligoni-spariti-problema-di-rendering-tp5692012p5693148.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Multipoligoni spariti, problema di rendering?
2010/11/1 scratera piz...@alice.it: ...non ho capito che altro ho toccato??? se guardi il tuo changeset (user/username/edits) puoi vedere tutte le modifiche che hai fatto... ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Modifiche ai CAP
Vi segnalo che dal 29 ottobre Poste Italiane ha modificato i CAP di 146 comuni[1]. Ci saranno quindi dei tag postal_code e addr:postcode da aggiornare; io ho già controllato le province di Ascoli Piceno e Fermo, le altre modifiche riguardano principalmente le province di Monza e Brianza e Barletta-Andria-Trani e i comuni dell'Alta Valmarecchia passati dalle Marche all'Emilia-Romagna. [1] = http://www.poste.it/postali/banchedati/PT_Cap_A5_treante_05.pdf -- View this message in context: http://gis.638310.n2.nabble.com/Modifiche-ai-CAP-tp5694700p5694700.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Storico di una zona e changeset troppo vasti
Come fate a tenere sotto controllo le modifiche che riguardano le zone di vostro interesse? Il modo più semplice credo sia quello di utilizzare lo storico disponibile sulla mappa principale. Il problema è che questo metodo visualizza tutti i gruppi di modifiche che si estendono sulla zona richiesta, anche se essi non riguardano oggetti che ricadono in essa (infatti basta fare una modifica in Alaska e una in Nuova Zelanda e il changeset coprirà tutto il pianeta o quasi...). Ora direi che negli ultimi tempi, grazie al diffondersi dei vari strumenti per la verifica della correttezza dei tag, questi gruppi di modifiche enormi siano sempre più frequenti, e per controllare le modifiche dell'ultima settimana ci si trova con decine di pagine da spulciare... Vi chiedo quindi: ci sono metodi più efficienti? O è il caso di avviare una campagna di sensibilizzazione per convincere i mappatori a evitare i changeset troppo vasti? -- View this message in context: http://gis.638310.n2.nabble.com/Storico-di-una-zona-e-changeset-troppo-vasti-tp5694785p5694785.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Storico di una zona e changeset troppo vasti
2010/11/1 totera g...@hotmail.it: Vi chiedo quindi: ci sono metodi più efficienti? O è il caso di avviare una campagna di sensibilizzazione per convincere i mappatori a evitare i changeset troppo vasti? C'è itoworld e owl (Openstreetmap Watchlist). http://wiki.openstreetmap.org/wiki/OWL http://wiki.openstreetmap.org/wiki/ITO_World e probabilmente anche altro. AFAIK non c'è un modo per rintracciare i cambiamenti che riguardono solo nodes senza alterare i ways. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Storico di una zona e changeset troppo vasti
M∡rtin Koppenhoefer wrote: C'è itoworld e owl (Openstreetmap Watchlist). http://wiki.openstreetmap.org/wiki/OWL http://wiki.openstreetmap.org/wiki/ITO_World Conoscevo già Itoworld ma non è di grande utilità se si vogliono seguire tutte le modifiche. OWL invece mi sembra molto interessante e adatto allo scopo... grazie! -- View this message in context: http://gis.638310.n2.nabble.com/Storico-di-una-zona-e-changeset-troppo-vasti-tp5694785p5695531.html Sent from the Italy mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-dk] gang/cykelstier
On Thu, Oct 28, 2010 at 09:44:36AM +0200, Jonas Häggqvist wrote: Jeg tror Jesper hentyder til kombinerede stier, for at tage et eksempel, såsom en sti der går gennem et villa-område hvor både cykler og fodgænger er velkomne (det samme gælder så for cykelstier langs landeveje). Akkurat ja. Jeg snakkede kun om kombinerede cykel-/gangstier. Eksemplet med hvad cyklister må på fortovet, og hvad fodgængere må eller ikke må på cykelstien var blot for at sammenligne dansk og norsk færdselslov. Cyklisterne i Norge har noget løsere regler end dem i Danmark :) -- Jesper Henriksen ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-es] Autobuses urbanos Pamplona
upa, El Ostirala, 2010ko Urriaren 29, Celso González escribió: Hola Después de que la Mancomunidad cediese los datos de las líneas de autobuses a Google Transit contacte con ellos para ver si los podíamos usar. Fueron muy receptivos y la idea les gustaba, pero tenían que consultar. Ahora ya tenemos vía libre. Buena noticia, yo estaba empezando a plantearme ir metiendo las paradas y poco a poco alguna ruta. Supongo que este fin de semana haré una prueba a ver que sale. Si quieres que te eche una mano, me dices. PD. Que fue de la página con las estadisticas de Navarra? ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Río y riverbank
Hola: Estoy dibujando los bordes del río en esta zona [1]. Lo estoy dibujando por áreas cerradas, tal y como se ve en esta imagen [2]. Al tratar de subir los datos, me da un error de cruce de vías entre el río y la traza del riverbank que pinto de orilla a orilla, así que lo tengo guardado en local. ¿Cómo se hace correctamente? ¿ o no hay manera y lo subo a machete? Gracias! [1] http://www.openstreetmap.org/?lat=42.38867lon=-7.126485zoom=18layers=M [2] http://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank#Islands ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Frontera municipal incorrecta ¿?
El 30 de octubre de 2010 00:14, Marco Fernández marco.m...@gmail.comescribió: He estado comprobando con las fotos del IGN algún limite municipal en el que la linea la marca un río y en alguna parte se va unos cuantos metros hacia tierra, algo parecido a lo que se ve con el barranco. ¿podría deberse a que los límites municipales se importan con un nivel de precisión menor que el zoom que yo aplico? ¿Se pueden afinar la posición o son algo firme marcado desde arriba? ¿Alguien que sepa de fronteras? Gracias!! ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Río y riverbank
El 1 de noviembre de 2010 14:25, Marco Fernández marco.m...@gmail.comescribió: Hola: Estoy dibujando los bordes del río en esta zona [1]. Lo estoy dibujando por áreas cerradas, tal y como se ve en esta imagen [2]. Al tratar de subir los datos, me da un error de cruce de vías entre el río y la traza del riverbank que pinto de orilla a orilla, así que lo tengo guardado en local. ¿Cómo se hace correctamente? ¿ o no hay manera y lo subo a machete? Yo lo que hago es crear un nodo donde se crucen. Gracias! [1] http://www.openstreetmap.org/?lat=42.38867lon=-7.126485zoom=18layers=M [2] http://wiki.openstreetmap.org/wiki/Tag:waterway=riverbank#Islands ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es -- Blog http://jorgesanzs.blogspot.com/ ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Río y riverbank
El 1 de noviembre de 2010 15:43, sanchi sanc...@gmail.com escribió: Yo lo que hago es crear un nodo donde se crucen. Eso arregló el cruce entre el embalse, el riverbank y el río pero sigue protestando en otro extremo del área, donde se cruzan dos riverbank y el río que baja :( ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-es] Frontera municipal incorrecta ¿?
Buenas, Las líneas de límites municipales se importaron del EGRN [1]. Y, sí, contienen incorrecciones. Sin ir más lejos, en mi pueblo el límite partía por medio el propio edificio del Ayuntamiento. Lo desplacé a un sitio más correcto en base a algunos hitos que hay en el terreno. Aunque sé que no será del todo correcto ni es oficial, se parece más a la realidad... Los documentos oficiales que realmente todavía se usan hoy en caso de litigio son unas minutas que se levantaron a principios del siglo XX a escala 1:25 000 para elaborar el MTN50. En Catalunya se dispone de unas copias hechas a mano tiempo ha, que han sido recientemente digitalizadas [2], y que actualmente se están usando como base documental para actualizar los límites con mayor precisión, a escala 1:5 000. Un trabajo de chinos, que combina técnicas de GPS diferencial con tareas casi de arqueología. --- [1] http://centrodedescargas.cnig.es/CentroDescargas/equipamiento.do?method=mostrarEquipamiento [2] http://cartotecadigital.icc.cat/cdm4/browse.php?CISOROOT=%2Fminutes Slt, Oscar. El día 1 de noviembre de 2010 14:34, Marco Fernández marco.m...@gmail.com escribió: El 30 de octubre de 2010 00:14, Marco Fernández marco.m...@gmail.com escribió: He estado comprobando con las fotos del IGN algún limite municipal en el que la linea la marca un río y en alguna parte se va unos cuantos metros hacia tierra, algo parecido a lo que se ve con el barranco. ¿podría deberse a que los límites municipales se importan con un nivel de precisión menor que el zoom que yo aplico? ¿Se pueden afinar la posición o son algo firme marcado desde arriba? ¿Alguien que sepa de fronteras? Gracias!! ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
