Re: [OSM-legal-talk] [OSM-talk] The OSM licence: where we are, where we're going
rob wrote: Quoting Tom Hughes [EMAIL PROTECTED]: On the face it claims to work in those jurisdictions via contract law, but what is not clear to me is how you require people to enter into that contract. Yes this is my concern about the ODL. The GPL for example is a license not a contract in US law terms. Although the recent Artistic License case has taken a different view: http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source-legal-decision-jacobsen.html But I agree that it's an important (and interesting) question. cheers Richard ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] The OSM licence: where we are, where we're going
Hi, Not to protect OSM from a bad project, but to protect people from a bad instance of the data. Sounds like you're targetting individuals whom you do not trust to make an informed choice. I know that there are whole schools of philosophy reliant on the we know better what is good for the average man so we have to keep the tempations away from him but I don't subscribe to that. You accuse Jochen of having an ideological commitment to market competition, but is your idea that the general population is too stupid to decide for themselves whether they want to use the free data or the non-free competition product any less ideological? Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-legal-talk] [OSM-talk] The OSM licence: where we are, where we're going
Hi again, Rob and Frederik - I don't think it's too much of a leap to say that you're never going to convince each other. ;) A note on consultation and community might be helpful. As the Foundation we are, of course, keeping track of the different strands of opinion within the community (share-alike or not, attribution or not, and so on). List discussion is helpful for this, as was SOTM, and there are many more avenues where OSMers make their feelings known. As the opengeodata posting states, We cant change anything without you. You, not the Foundation, own the rights to your mapping. So our interest is in finding a solution that has a realistic chance of being adopted by the community. Right now, this debate is part of an informal consultation, if you like. Now that we've posted the update, people are of course going to voice their views, and those will feed into the rough view of the OSM community. There will no doubt be more updates posted on opengeodata during which the rough view will evolve further. If the rough view (for example) appeared to coalesce around ODCL looks good, let's do it now, we would be able to start work on a formal relicensing process. (I'd envisage, and this is very definitely only my perception rather than an as-yet adopted Foundation plan, that such relicensing could involve: discussion with the ODC authors until the licenses are in a state we consider usable; independent review by a qualified third party; and, finally, contacting every single registered OSM user to request their assent to the change.) If this rough view, however, does not settle so neatly, then the Foundation will need to decide whether it should embark on a formal consultation before the relicensing (maybe like the poll that some have mentioned); and the outcome of that consultation would affect the proposed relicensing. I should note that there's nothing[1] in this process that only the Foundation can do. It is something the Foundation _wants_ to do just because of its role to look after the best interests of the project. Anyone who wants to open discussions with a lawyer or stage their own poll is welcome to: I would hope that the Foundation is being open enough that no-one would feel the need to start a whole separate process, but the option is always there. cheers Richard [1] except, in the event of a relicensing, a potential mail-out to every registered OSM user. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-legal-talk] The OSM licence: where we are, where we're and are, where we're going
(follow-ups to legal-talk, please) Peter Miller wrote: There are clearly uncertainties and complications with the current licence, however it does allow for the license to be upgraded without going back to original contributors for permission. In OSM's case that's unlikely to be true. Copyright in OSM contributions is owned by the original contributors, not by OSMF. As the CC-BY-SA 2.0 summary says, A new version of this license is available. You should use it for new works, and you may want to relicense existing works under it. No works are automatically put under the new license, however. Since no works are automatically put under the new licence, every contributor would have to choose to move to (say) CC-Data-BY-SA just as they would any other licence. As such I feel confident that CC could come up with a derivative of CC-BY-SA 3.0 that covers our needs and plug the gaps (and those of other gedata/DB type datasets generally); after all, if the ODL can do it then why can't CC do it The following background is absolutely crucial. It's in the OpenGeoData post but I'll take the chance to restate it. I'd encourage you, Longbow4u and others to reflect on it. * The Open Data Commons Database Licence is a share-alike licence with attribution elements. It is, as you say, in the spirit of CC-BY-SA. * Its authors are working with Creative Commons. * Creative Commons has a strong policy that facts are free[1]. They have therefore now introduced a licence for factual information, but this is essentially public domain (CC0/PDDL) with a voluntary request to share info. We are _not_ recommending that OSM adopts that licence. The ODC Database Licence is entirely separate. So to specifically answer your point about if the ODL can do it then why can't CC do it: * CC doesn't believe factual information should be subject to restrictions, so _won't_ do it. * But if CC were to do it (if, for example, they were lobbied to do so), their existing collaboration with ODC makes it very likely that they would actually adopt the Open Data Commons Database Licence. In other words, this option is significantly _more_ copyleft than CC themselves propose. Btw, where should this debate be happening? Personally I suggest the legal nerdy details are discussed on legal-talk but any discussion about principles are discussed on 'talk' It's a good point, but in practice legal-talk will work best because it's very difficult to separate the two, and because discussions will drift from one to the other. We also don't want to overwhelm the rest of the project with it! cheers Richard [1] From their database FAQ: As you know, Creative Commons and Science Commons work to promote freely available content and information. Our preference is that people do not overstate their copyright or other legal rights. Consequently, we adopt the position that 'facts are free' and people should be educated so that they are aware of this. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
Re: [OSM-talk] POIs from wikipedia
Frederik Ramm wrote: Well no matter where they came from, being Wikipedia they're GNU FDL and if we incorporated them we'd have to switch to GNU FDL as well, at least that's how I read virulent licenses. Wikipedia are working with the FSF to make the FDL compatible with CC-BY-SA 3. I expect that this will happen by the FSF adding a clause to the FDL saying If you have no front-cover texts, no back-cover texts etc. etc, you may relicense this work under CC-BY-SA 3. This is something we need to consider if we move away from CC-BY-SA. I can see the arguments for it, but unless we are careful, it does move us further away from the growing area of license compatibility. Gerv ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [OSM-legal-talk] The OSM licence: where we are, where we're going
Frederik Ramm wrote: And I say this again, if I saw that a majority of OSM contributers thinks that the copyleft aspect is important, then I'd not have this discussion. It is just that it seems to me that there are very few people who hold up the CC banner. And most of these, after some thinking, silently retract their banner when I ask them how they'd combine OSM data with a GNU FDL source and what the result should be licensed under... Since that mainly concerns wikipedia, do you still get the same response now wikipedia have announce their intention to be CC compatible? This strikes me as a problem with the FDL, not with our license, and I'm not aware of the FDL having much importance for material we might want to merge with ours apart from that case. I'm also slightly surprised you think the number of supporters of (the intention behind) CC-BY-SA is so small. Like you said, I guess a poll would be good - but when the actual alternatives have firmed up more, as the geodata blog describes. Cheers Graham Bye Frederik ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] The OSM licence: where we are, where we're going
At 12:33 PM 1/9/2008, Frederik Ramm wrote: Hi, Although the recent Artistic License case has taken a different view: http://lawandlifesiliconvalley.blogspot.com/2007/08/new-open-source- legal-decision-jacobsen.html Hm, being neither lawyer nor native speaker of English nor American citizen I my get some things wrong here but the statement The second point is very important because it deals with remedies. Generally, the remedy for contract violations under US law is damages, not injunctive relief (which means that the court order a party to cease their violation). prompts me to ask: Would that mean that if our license was a contract and somebody violated it, he would have to pay us damages, which I (perhaps naively) would interpret as the amount of money we lost due to his infringement, i.e. zero dollars? Yes, if I understand it, your summary is spot on. That is the main motive behind Free Software Foundation and some lawyers have taken the position that open source licenses are not contracts - copyright violation = you stop them continuing the violation versus contract violation = you can get damages = 0. So the obvious inference for us is that data copyright is meaningless and in the US, if this decision is adopted by higher level courts and becomes a precedent, then a contract is meaningless too except to stop people with morals. I can see where you are going with this one ;-) Mike Stockholm ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
[OSM-talk] Roadnav
Hi, For those that don't know, there is now a beta version of Roadnav available. This version has support for openstreetmap data. Displays the maps ok, but routing and searching do not seem to be working. Not as pretty as Gpsdrive using mapnik, but oh, so much easier to install. Cheers, Ian - Sent from Yahoo! #45; a smarter inbox.___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] The OSM licence: where we are, where we're going
In message [EMAIL PROTECTED] Frederik Ramm [EMAIL PROTECTED] wrote: I just said that there weren't many copyleft supporters at SOTM 07. Has the license panel discussion ever reached audio publication? Because I believe the result of the show of hands was spoken so it should be on there. Not that this would mean a lot since it is very well possible that the folks at SOTM were not representative of the general OSM population. I just don't want people to have the impression that I am hallucinating when I say that the copyleft fans were a tiny minority. The audio the debate is here: http://www.archive.org/details/Sotm07PanelDebate-LicensingOsmData Tom -- Tom Hughes ([EMAIL PROTECTED]) http://www.compton.nu/ ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] As on ground country names
On Jan 9, 2008 2:06 PM, Stefan Baebler [EMAIL PROTECTED] wrote: Hi! I'd imagine that OSM's as on ground rule for primary names should also apply for country nodes (tagged with place=country), however this doesn't seem to be the case at the moment. http://osmxapi.hypercube.telascience.org/api/0.5/node%5bplace=country%5d shows that primary names are english names for most of the countries. Any thoughts? Do we bend the rule here in favor of english over local name? How about multilingual countries (eg. Switzerland) I suspect that this has more to do with them not actually being rendered by anything (certainly not osmarender, nor mapnik), and also by them being almost impossible to find during normal map editing (due to their extremely small size compared to what they represent). Italy doesn't even have Italia /anywhere/ in it's description. I don't know what people are actually using them for, but i suspect they'll all get heavily edited now that you've pointed them out. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] As on ground country names
On Jan 9, 2008 4:22 PM, Michael Collinson [EMAIL PROTECTED] wrote: At 03:06 PM 1/9/2008, Stefan Baebler wrote: Hi! I'd imagine that OSM's as on ground rule for primary names should also apply for country nodes (tagged with place=country), however this doesn't seem to be the case at the moment. http://osmxapi.hypercube.telascience.org/api/0.5/node%5bplace=country%5d shows that primary names are english names for most of the countries. Any thoughts? Do we bend the rule here in favor of english over local name? How about multilingual countries (eg. Switzerland) The main use at the moment will be for the international generic map that OSM hosts directly (as 80n writes) but more will come. I suggest therefore for the moment that the default name should English, repeated as name:en and (at least) the name(s) of the country in its own language(s) and script be entered using the ISO 639-1 [1] language namespace tag: I'd suggest keeping the exact same philosophy as used everywhere else. If you want a generalised english map at the top layer, then just rejig the renderer to use the name:en tag. There aren't that many countries so it shouldn't be too hard to ensure they all have an :en tag. And that way we're not special-casing data entry. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] Roadnav
Ian Haylock schrieb: Hi, For those that don't know, there is now a beta version of Roadnav available. This version has support for openstreetmap data. Displays the maps ok, but routing and searching do not seem to be working. Not as pretty as Gpsdrive using mapnik, but oh, so much easier to install. Cheers, Ian Hi, did you ever try navit? http://navit.sourceforge.net/ Jannis smime.p7s Description: S/MIME Cryptographic Signature ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] [RFC] shop = chemist
On Wed, January 9, 2008 7:30 am, Ulf Lamping wrote: Hi! There's an RFC about shop=chemist, please have a look at: http://wiki.openstreetmap.org/index.php/Proposed_features/Chemist On the wikipedia page about superdrug, I've found the term health and beauty retailer which might be a better term than chemist. It's not a term that I've ever heard before. It sounds like something that sector of the industry have made up to describe themselves. I'm still pretty unclear about the meaning of the dispensing tag of the already existing amenity=pharmacy. In the UK context, a dispensing chemist is one that is allowed to sell drugs which can only be issued on a prescription. (I hope I phrase that correctly.) A prescription is issued by a doctor. Mike Collinson has added wording to the Wiki page that may go some way to clarifying the terms. In the UK context, as he says For most people a pharmacy and a chemist meant (past tense) the same thing, though I might argue with the past tense - I'd still expect both a pharmacy and a chemist to be dispensing chemists. As I'm not a native speaker, I could need some help here :-) I am a native speaker. -- David James ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] POIs from wikipedia
On 08/01/2008, Richard Fairhurst [EMAIL PROTECTED] wrote: while i was looking up some info on wikipedia [1], i noticed that a lot of pages have a lat/lon value to describe their location; this strikes me as something we could use to increase the amount of data in OSM These are almost certainly derived from Google Maps et al, therefore unsuitable for OSM. really, that sounds like it would contravene wikipedia's rules and google's terms of use? and is it our responsibility to pre-guess what wp editors are doing? i think taking their data at face value is acceptable ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-legal-talk] [OSM-talk] The OSM licence: where we are, where we're going
Hi, Rob and Frederik - I don't think it's too much of a leap to say that you're never going to convince each other. ;) Yes but I always hope Rob's going to get tired at some point ;) seems I underestimated his stamina though. If this rough view, however, does not settle so neatly, then the Foundation will need to decide whether it should embark on a formal consultation before the relicensing (maybe like the poll that some have mentioned); and the outcome of that consultation would affect the proposed relicensing. I thought you might use the poll as a straw poll just to give you a raw idea, instead of as a kind of vote late in the process. I should note that there's nothing[1] in this process that only the Foundation can do. That may be true but being the outspoken PD advocate that I am, any poll I created would either be biased or at least be *perceived* to be biased, and thus worthless. It's not only that the Foundation alone has access to all the E-mail addresses (btw: does it? and why?), it is also that the Foundation would probably be trusted to create an unbiased poll. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ legal-talk mailing list [EMAIL PROTECTED] http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/legal-talk
[OSM-talk] source=yahoo
Greetings Everyone. If there is source=landsat for features derived from landsat photos should I tag source=yahoo those ones I have spotted on Yahoo imagery? -- Best regards. Czwarta pospolita klęska, [...] Łukasz Już nie katolicka lecz złodziejska. (c)PP -- Nadchodzi wojna miedzygalaktyczna! Sprawdz! http://link.interia.pl/f1cc2 begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] administrative boundaries and is_in
can someone explain a few things about the way boundaries work, and their relation to the is_in key? as far as i can tell, when a location (say the suburb of balham, in london) is added to the map, the is_in tag needs to be set, multiple times. in this case, it would be set as follows: is_in:Westminster (...i think) is_in:greater london is_in:england is_in:united_kingdom is_in:British_Isles is_in:Great_Britain is_in:Europe ...etc. which seems counter-intuitive, not to mention requiring huge amounts of work. do we set this for every item - roads, churches, supermarkets,thousands of other items? is there anything underway to enable OSM to calculate where an object is, based upon knowledge of administrative boundaries - after all, they are only a polygon-shaped bounding box? if i set is_in of balham to london, and the is_in of london to england, does osm know that balham is therefore in england, by cascading the is_in values? and so on, for as many levels as we define? my second, related, point concerns boundaries that coincide with coastlines: do we need to trace over the coastline of a country/city/suburb to define an unbroken loop for each administrative areas, or can OSM work out for itself that the coastline forms the rest of the boundary? what about if the entire boundary is defined by coastline? are these questions only relevant if and when items are automagically aware of their location? thanks for any help ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] administrative boundaries and is_in
Robin Paulson wrote: can someone explain a few things about the way boundaries work, and their relation to the is_in key? as far as i can tell, when a location (say the suburb of balham, in london) is added to the map, the is_in tag needs to be set, multiple times. in this case, it would be set as follows: is_in:Westminster (...i think) is_in:greater london is_in:england is_in:united_kingdom is_in:British_Isles is_in:Great_Britain is_in:Europe ...etc. which seems counter-intuitive, not to mention requiring huge amounts of work. do we set this for every item - roads, churches, supermarkets,thousands of other items? For central Europe there's another project, named opengeodb, which is structured hierarchically. Here it's enough to take the lowest matching level (by loc_id), while all other levels above can be heritated. The names which are used for is_in have no need to be unique. Thus you can not derive info. - Martin ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] source=yahoo
I have seen these two source=Yahoo Imagery source=yahoo_imagery I'd be interested in knowing which is the more generally accepted one. cheers On Jan 10, 2008 7:12 AM, Lukasz Stelmach [EMAIL PROTECTED] wrote: Greetings Everyone. If there is source=landsat for features derived from landsat photos should I tag source=yahoo those ones I have spotted on Yahoo imagery? -- Best regards. Czwarta pospolita klęska, [...] Łukasz Już nie katolicka lecz złodziejska. (c)PP -- Nadchodzi wojna miedzygalaktyczna! Sprawdz! http://link.interia.pl/f1cc2 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk -- Franc ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] administrative boundaries and is_in
On Jan 9, 2008 12:44 PM, Robin Paulson [EMAIL PROTECTED] wrote: can someone explain a few things about the way boundaries work, and their relation to the is_in key? as far as i can tell, when a location (say the suburb of balham, in london) is added to the map, the is_in tag needs to be set, multiple times. in this case, it would be set as follows: is_in:Westminster (...i think) is_in:greater london is_in:england is_in:united_kingdom is_in:British_Isles is_in:Great_Britain is_in:Europe ...etc. which seems counter-intuitive, not to mention requiring huge amounts of work. do we set this for every item - roads, churches, supermarkets,thousands of other items? is there anything underway to enable OSM to calculate where an object is, based upon knowledge of administrative boundaries - after all, they are only a polygon-shaped bounding box? if i set is_in of balham to london, and the is_in of london to england, does osm know that balham is therefore in england, by cascading the is_in values? and so on, for as many levels as we define? I think the is_in tag is mostly useless, for the reasons you've demonstrated. I've been thinking about this problem, too. In order to make properly indexed streets (for find by address) and POIs for GPS devices (I'm thinking Garmin here specifically), each point or street needs to be associated with a region (i.e., state or province or maybe country), city, zip code, etc. But this doesn't need to be tagged on each point--it should be able to be derived from boundaries. I'm thinking of a program which uses the administrative boundaries already in the planet file to do an optimized lookup for points. You could query it for admin_level=4 to get the state or province name, to take an example from the boundary key page on the Wiki. (Does anyone know why there are only even numbers for the admin_level values???) This is basically reverse geocoding, and I know some work has been done on it in other projects in the past. Maybe PostGIS would be good for this (I don't know much about PostGIS, but it seems to be the sort of thing for which it was created). Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] POIs from wikipedia
Robin Paulson wrote: [co-ordinates on Wikipedia] On 08/01/2008, Richard Fairhurst [EMAIL PROTECTED] wrote: These are almost certainly derived from Google Maps et al, therefore unsuitable for OSM. really, that sounds like it would contravene wikipedia's rules and google's terms of use? and is it our responsibility to pre-guess what wp editors are doing? i think taking their data at face value is acceptable Please read http://en.wikipedia.org/wiki/Wikipedia:Obtaining_geographic_coordinates It actively recommends getting co-ordinates from Google Maps, Multimap, Microsoft etc. etc. etc. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] source=yahoo
Franc Carter wrote: I have seen these two source=Yahoo Imagery source=yahoo_imagery the latter seems quite nice. i'll use it. -- Było mi bardzo miło. Czwarta pospolita klęska, [...] Łukasz Już nie katolicka lecz złodziejska. (c)PP -- Kupujesz laptopa? Sprawdz nasze testy! Kliknij http://link.interia.pl/f1cd1 begin:vcard fn;quoted-printable:=C5=81ukasz Stelmach n;quoted-printable:Stelmach;=C5=81ukasz email;internet:[EMAIL PROTECTED] x-mozilla-html:FALSE version:2.1 end:vcard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] POIs from wikipedia
On 10/01/2008, Richard Fairhurst [EMAIL PROTECTED] wrote: [co-ordinates on Wikipedia] really, that sounds like it would contravene wikipedia's rules and google's terms of use? and is it our responsibility to pre-guess what wp editors are doing? i think taking their data at face value is acceptable Please read http://en.wikipedia.org/wiki/Wikipedia:Obtaining_geographic_coordinates It actively recommends getting co-ordinates from Google Maps, Multimap, Microsoft etc. etc. etc. it does, cheers i'm slightly lost now, wondering how osm fits in to this. if wp users can do it (i assume their legat team has looked through it?), why not osm i guess it's ok, because they're using it for illustrative purposes (fair use?), rather than as a basis for their content ok, i'll keep looking and keep thinking. thanks ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] administrative boundaries and is_in
On Jan 9, 2008 3:34 PM, Thomas Wood [EMAIL PROTECTED] wrote: On Jan 9, 2008 10:58 PM, Karl Newman [EMAIL PROTECTED] wrote: You could query it for admin_level=4 to get the state or province name, to take an example from the boundary key page on the Wiki. (Does anyone know why there are only even numbers for the admin_level values???) I believe its so it would fit all possible international region schemes. It also fixes the issue for different levels of regions being called the same thing, eg counties in the UK and US. I understand why numbers are used instead of names. My question is why are there no odd numbers listed? It just looked strange. Karl ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
Re: [OSM-talk] As on ground country names
Dave Stubbs wrote: On Jan 9, 2008 4:22 PM, Michael Collinson [EMAIL PROTECTED] wrote: At 03:06 PM 1/9/2008, Stefan Baebler wrote: Hi! I'd imagine that OSM's as on ground rule for primary names should also apply for country nodes (tagged with place=country), however this doesn't seem to be the case at the moment. http://osmxapi.hypercube.telascience.org/api/0.5/node%5bplace=country%5d shows that primary names are english names for most of the countries. Any thoughts? Do we bend the rule here in favor of english over local name? How about multilingual countries (eg. Switzerland) The main use at the moment will be for the international generic map that OSM hosts directly (as 80n writes) but more will come. I suggest therefore for the moment that the default name should English, repeated as name:en and (at least) the name(s) of the country in its own language(s) and script be entered using the ISO 639-1 [1] language namespace tag: I'd suggest keeping the exact same philosophy as used everywhere else. If you want a generalised english map at the top layer, then just rejig the renderer to use the name:en tag. There aren't that many countries so it shouldn't be too hard to ensure they all have an :en tag. And that way we're not special-casing data entry. Even if there is no name:en, the international renderer can fallback to the int_name and then finally to local name attribute. Sticking to the as on ground rule can probably elegantly avoid some of the known naming disputes: http://en.wikipedia.org/wiki/Category:Geographical_naming_disputes Stefan ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] Marrakech Mapping Party -CANCELLED-
Hi, For personal reasons I am not going to be able to complete the preparations of the Marrakech mapping party. And becaue there is no other OSM member from Morocco at the time, there is no one to whom I can hand on the responsability. At the same time I think the timing for a Morrocan mapping party is not good, we should have at least 3 or 4 members to start a party. At the same time I have not received confirmation from anyone that he is coming from abroad and booked a flight, which means no harm done (I hope). Ali. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk] A0 or A1 OSM map poster and other conference stuff
Hi guys, I will be manning an OSM stand at the next OpenExpo(.ch) in Bern, Switzerland in March. I need a poster for that. Unfortunately, I have forgotten how people have been creating these so far. There was a postscript renderer somewhere in CVS right? Or have people been using Mapnik directly? I have no mapnik installed so that would pose some more hassle. I will be needing both a low-zoom variant (Switzerland + Surroundings) as well as some high-zoom, show-off thingie (downtown Zurich or so). I will also be looking into SVN whether I can reuse some of the OSM lecture slides. Any recommendations? What else should I showcase there? OpenLayer with OSM. JOSM. N800 with Maemo-mapper. Some routing software perhaps? What can run on a Mac easily? I never got OJW's pyroute to run on my Mac yet, but that would certainly be cool. spaetz ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk
[OSM-talk-nl] tileserver update (Peter Peterse)
Ik vind het toch gek, mijn ervaring is dat de Mapnik-map vaak sneller geupdate is dan de nl-tileserver. De [EMAIL PROTECTED] map is meestal het eerst met de wijzigingen, maar ook weer niet altijd... Wanneer zijn de veranderingen gemaakt. Het kan een dag of twee duren voordat de data in de DB helemaal door tot de tiles werkt... Ik zie wijzigingen van 2 weken geleden nog steeds niet op de nl-server verschijnen ... :-( -- Gerco-Kees ___ Talk-nl mailing list Talk-nl@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-nl
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Am Mittwoch, 9. Januar 2008 08:32:06 schrieb Martin Trautmann: Ich werde eine solche Liste vielleicht wieder auf die entsprechende talk-Seite stellen, wie bei http://wiki.openstreetmap.org/index.php/Talk:Baden-Württemberg#Korrekturvor schläge Bonn-Brühler Straße Bonn-Brühler-Straße ... da finde ich die alte Schreibweise selbst aber richtiger Die ist meines Wissens auch vollkommen korrekt. Holzgasse, Tonnepütz, Lohheckenweg Holzgasse ... sollte man hier besser dreimal das tag Name vergeben, statt alles mit ,, ; oder / in einen Eintrag zu packen? Das wurde anscheinend schon von dem betreffenden Mapper korrigiert. Chateoneufstraße Chateauneufstraße Henry-Spaak-StraßeHenri-Spaak-Straße Oh Gott! Das sind 27 Objekte, die zum ersten gehören, was ich in OSM vor einem 3/4 Jahr gemacht habe... und der Fehler hat sich bis heute gehalten! Heppertzweg Heppertsweg Heppertsweg ist richtig und taucht auch so in meinen Aufzeichnungen auf... Meiergasse Meiersgasse Die Meiersgasse in Alfter gibt es, sie wurde von einem anderen Mapper gemacht. Eine Meiergasse gibt es wohl im benachbarten Bornheim. Quiriniusstraße Quirinusstraße Da hat OpenGeoDB Recht! Willi-Haas-Straße Willy-Haas-Straße ...genau wie hier! Bei den noch offenen Einträgen fehlt mir z.B. die Ortskenntnis für Am Lindchen und Im Lindchen. Am Lindchen ist richtig. :-) Danke für die Hinweise! Bei einigen Straßennamen wäre Ich im Leben nicht darauf gekommen, daß sie falsch geschrieben sind - gerade weil Ich sie schon mein ganzes Leben lang kenne. ;-) Ich verstehe diese OpenGeoDB-Sache irgendwie noch nicht so ganz. ;-) Die ist ja auch erst am Anfang: Ich bin in der ersten Runde, wo nur der nächste Nachbar zur Gemeinde-Koordinate verglichen wird. Der opengeodb fehlt bisher die Detailkenntnis von Wegenetzen und Straßen. Die wächst gerade erst mal bis zur Ortsteil-Ebene. Als nächstes kann ich damit prüfen und verbessern, welche Ortsteil-Koordinaten ich habe. In der zweiten Runde erfolgt also später ein Abgleich zum passenden Ortsteil. In der Runde sollten dann auch Einträge auffallen, die fälschlich einer Nachbargemeinde zugeordnet wurden, weil dieser Ortsteil näher an der Gemeindegrenze als an der Gemeindekoordinate lag und die Nachbargemeinde Straßen mit gleichem Namen aufweist. OK, aber woher stammen nun die Straßendaten? Auf der Seite von OpenGeoDB erweckt alles den Anschein, daß es in OpenGeoDB keine Straßen gäbe, sondern der Fokus auf Städten und Gemeinden liegt. OK, mit Hilfe der Erste Test-Daten-Diskussion reime Ich mir jetzt zusammen, daß du Straßenlisten der Gemeinden genommen und im Umkreis der OpenGeoDB-Gemeindeeinträge einen Vergleich dieser mit denen in OSM gemacht hast. Richtig? An der Stelle kann ich aber Hilfe brauchen, ob jemand ein Script schreiben mag, das alle zusammenhängenden Weg-Stücke mit gleichem Namen in einem einzigen Tabelleneintrag zusammenfassen kann. Damit kann ich mich bei z.B. zehn Weg-Einträgen mit gleichem Namen auf die drei beschränken kann, die getrennte Strassen darstellen, während die anderen über gemeinsame Knoten oder Knotenduplikate mit minimalem Abstand damit zusammenhängen. Mit soetwas kenne Ich mich leider auch nicht genügend aus. Schönen Gruß Martin Auch schöne Grüße und nochmal Danke für deine Mühen! -Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse =farm fXr ganze Felder/Wiesen, Unsinn?
ich bin - wieder mal - fuer eine trennung: landuse zeigt an, was da ist, wird also fuer eine flaeche, die voll mit baeumen steht, als forest oder sowas getaggt. ob und wie die flaeche wirtschaftlich genutzt wird, muss in ein separates tag, genauso wie eventuelle andere attribute. Genau, es ist nur irgendwie genau umgekehrt ;) landuse scheint anzeigen zu sollen, wie etwas genutzt wird (z.b. forest) und nature sagt, was dort rumsteht (z.b. wood). Und da zumindest in D der wald bis auf wenige ausnahmen genutzt wird, setzt man einfach immer beide attribute. Ausnahmen sind z.b. baumbereiche in landuse=recreation_ground oder landuse=cemetery oder eben diese leisure-sachen wie leisure=park. Sorry wenn ich den Thread nochmals aufwärme, aber ich frag mich grad wozu beide Attribute notwendig sind. Gibt es ein landuse=forest (also eine Forstwirtschaftliche Landnutzung) auf der KEINE Bäume stehen (also natural=wood)? Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] On 2008-01-08 23:20, Martin Trautmann wrote: Hallo, wie gewünscht habe ich auch mal Nordrhein-Westfalen abgeglichen, wie viele der gelisteten Gemeindestraßen schon in OSM erfasst sind. Bemerkung am Rande: Die extrahierten Daten nach Bundesland, die ich hier benutzte, enthalten einige Strassen, die hollaendisch klingen und eine groessere Anzahl (etliche Dutzend), die ich eher Niedersachsen zuordnen wuerde. http://download.geofabrik.de/osm/europe/germany/nordrhein-westfalen.osm.bz2 groessere Menge an Strassen, die ich bei der Domainfactory enthalten Die Bundeslandgrenzen, die die geofactory laut http://biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Schoenen Gruss Martin -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger?did=10 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Besenwirtschaft/Straußwirtschaft/Heck enwirtschaft/...
On Tuesday, 8 January 2008 23:52:40 +0100, Michael Kugelmann [EMAIL PROTECTED] writes: Christoph Eckert schrieb: das generelle Problem ist IMO aber schon gegeben. Es gibt Straßen, die nur zu bestimmten Uhrzeiten befahrbar sind, wie auch Fähren. Eine Routingsoftware sollte IMO davon wissen. [...] Das finde ich auch OK. Aber so weit sind wir im Moment noch gar nicht. Und: das was Christoph geschildert hatte, ist ja ein regelmäßiges bzw. wiederkehrendes Verhalten = das kriegt man in den Griff. Manches kann man sicher mit den bereits existierenden Restrictions (date_on, date_off, day_on, day_off, hour_on, hour_off) erreichen. Bei den Besenwirtschaften ist es ja eigentlich viel schlimmer. Das ist ja nicht regelmäßig = jedes Jahr anders [...] Ein aehnliches Problem hat man aber auch bei mancher Ausflugsgaststaette. Da gibt es einige, die z.B. nur an Wochenenden offen sind oder nur waehrend der Neben- und Hauptsaison. Never the less suche ich immer noch so etwas wie ein TAG für einen Besen. Hat niemand eine Idee, wie man so etwas taggen kann? Notfalls müsste man (ich) über proposed features so etwas einführen. ... und als Icon-Vorschlag dann einen Besen? :-) Momentan habe ich vor, die Besenwirtschaften in meinem Umfeld (Kernen im Remstal, da gibt es einige) als Restaurant zu taggen und die Besen-Eigenschaft im Namen aufzufuehren. Da koennte ein Fremder, der mit dem Begriff im Namen nichts anfangen kann, dann zwar oefter vor verschlossener Tuere stehen, alle anderen wissen um die unregelmaessigen Oeffnungszeiten und man kann spaeter immer noch nach diesen suchen und entsprechend (um)taggen. -bernd ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] groessere Menge an Strassen, die ich bei der Domainfactory enthalten der satz keinen sinn ergibt, streichen bitte... (wurde versehentlich nicht gelöscht) -- GMX FreeMail: 1 GB Postfach, 5 E-Mail-Adressen, 10 Free SMS. Alle Infos und kostenlose Anmeldung: http://www.gmx.net/de/go/freemail ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Hallo, Die Bundeslandgrenzen, die die geofactory laut http:// biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In-Reply-To: [EMAIL PROTECTED] On 2008-01-09 13:27, Frederik Ramm wrote: Hallo, Die Bundeslandgrenzen, die die geofactory laut http:// biogeo.berkeley.edu/gadm/ einsetzt, sollten daher vielleicht mal verbessert werden? Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Ich habe keine Ahnung, in welchem Format sie derzeit genutzt werden und wie das korrigierbar wäre. Bei Bedarf kann ich aber zumindest raussuchen, bei welchen Koordinaten besonderer Korrekturbedarf besteht. In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Schoenen Gruss Martin Trautmann -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] §5 UrhG, Städti
Es gibt ja im deutschen Urhebergesetz diesen netten Paragraphen 5, der amtliche Werke als gemeinfrei (public domain) einstuft. (1) Gesetze, Verordnungen, amtliche Erlasse und Bekanntmachungen sowie Entscheidungen und amtlich verfaßte Leitsätze zu Entscheidungen genießen keinen urheberrechtlichen Schutz. Also habe ich mal auf den Webseiten der Stadt gestöbert und bin in den Satzungen zum Thema Stadtrecht häufiger über Formulierungen wie Aufgliederung und örtliche Abgrenzung des Fassungsbereiches und der engeren Schutzzone sind in dem Lageplan des Städtischen Vermessungsamtes Baden-Baden Maßstab 1:2.000, der Bestandteil dieser Rechtsverordnung ist, dargestellt. Dieser Lageplan ist bei der Stadtverwaltung Baden-Baden – Amt für öffentliche Ordnung – in Baden- Baden, Gutenbergstr. 13, niedergelegt. Er kann dort während der Dienststunden eingesehen werden. gestolpert. Da der Lageplan ja explizit als Teil der Rechtsverordnung aufgeführt ist, müsste er ja auch gemeinfrei sein. D.h. ich könnte beim Amt für öffentliche Ordnung aufkreuzen, Fotos der Karte machen und munter für OSM digitalisieren, oder? Hat jemand bei diesem Vorgehen irgendwelche Bedenken? Gruß, Wabba ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Was haltet ihr davon? MfG Andi ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Raphael Studer schrieb: ... Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. interessanter Unterscheidungsansatz -- mario ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Zuordung von Straßen zu Orten via Rel ations
Hi, Da sich Martin Trautmann ja momentan die Arbeit macht, Straßen Orten zuzuordnen könnte man das Script doch gleich hernehmen um damit die entsprechenden Relations in OSM Anzulegen, dann könnte man das in Zukunft direkt aus den Daten rauslesen und muss nicht über den Abstand raten. Außerdem könnte man bei der Gelegenheit alle zusammenhängenden Wege mir selben Namen auch über eine Relation verbinden. MfG Andreas Hubel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
Am Mittwoch, 9. Januar 2008 14:15 schrieb Frederik Ramm: Hallo, Würd ich ja gern... aber wie? Von einer Karte abmalen darf ich sie ja nicht... Ich habe keine Ahnung, in welchem Format sie derzeit genutzt werden und wie das korrigierbar wäre. Das sind einfache Polygon-Dateien, die pro Zeile einen Punkt mit geographischer Laenge und Breite enthalten. Das ist alles, was ich brauche - eine Info der Form die Landesgrenze von NRW verlaeuft ueber die folgenden Punkte Bei Bedarf kann ich aber zumindest raussuchen, bei welchen Koordinaten besonderer Korrekturbedarf besteht. Ich will halt in diesem Punkt sehr korrekt vorgehen. Jede Datenquelle, mit der ich das abgleiche, muss lizenzmaessig astrein sein. Ja, wobei das raussuchen von einzelnen Punkten in einer Landkarte erstmal erlaubt ist In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Faende ich auch gut, aber mir ist unklar, wo man die Daten in einer freien Form herbekommen kann. Eigentlich muessten Laendergrenzen doch in irgendeiner Form amtlich veroeffentlicht sein... Ja, da bin ich zumindest für Hamburg drann. Siehe: http://wiki.openstreetmap.org/index.php/Hamburg/Grenzbeschreibungen Anscheinend gibt es sowas im Netz aber nicht für übergeordnete Ebenen (Bundesländer/Landesgrenzen) zumindest hab ich da noch nichts gefunden. Ich hab in Hamburg schon ziemlich lange hin und her telefoniert bis ich einen Ansprechpartner hatte. Das ist eigentlich etwas für einen Geschichtsstudend der eine Freundin hat die in einem Bundesarchiv arbeitet :-). Gruß Sven Anders ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Javascript-Editor für OSM
Nett. Noch ein bischen mehr JavaScript und das Ding wäre noch um einiges besser. Gibts irgendwo nen SVN oder Teilprojekt in dem es darum geht das Ding auszubauen und auf die Hauptseite mit einzubetten? MfG Andreas Hubel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
In-Reply-To: [EMAIL PROTECTED] On 2008-01-09 16:14, Andreas Hubel wrote: Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. Das waere vor allem dann verkehrt, wenn man diese Daten direkt aus der opengeodb holen wollte, statt sie gleich der OSM mitzugeben - das fuehrt nur zu einer Verdoppelung der Daten und verhindert gleichzeitig, dass Änderung zurückfliessen würden. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. Im Gegenteil steckt genau im originalen part_of die Relation drin, weil hier die loc_id des naechsten opengeodb-Eintrags steckt. Svens Beispiel scheint das flachzuklopfen (part_of / Teil von / is_in_loc_id gegenueber is_in) openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier 50011 name Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche http://kent.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400* kamen mit 0.2.5 und 0.2.6 erst hinzu) In der Name (50010:NAME) steckt die vollstaendige Namensbezeichnung drin, wie z.B. Freiburg im Breisgau. Die 50011 wird derzeit nicht wirklich genutzt. Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf den Basisteil wie freiburg (lower case, no Umlauts, no extensions) openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Die wiki-Seite sollte vielleicht mit einem Beispiel gefuettert werden type: Stadt, Landkreis, Gemeinde, Stadtviertel, Stadtbezirk, Ortsteil, ... layer: das gibt die Hierarchie-Ebene an. Beispielsweise gibt es Hamburg als Bundesland (AGS 02, layer 3), als Landkreis (AGS 02000, layer 5) und als Gemeinde (AGS 0200, layer 6) Auf layer 4 liegen die Regierungsbezirke, auf layer 7 die Orte, auf layer 8 die Ortsteile, auf 9 die Strassen, auf 10 Einzeladressen Durch Teil von (part of, is_of) und Ebene (level, layer) wird ausreichend genau beschrieben, wo im Baum das ganze hierarchisch haengt. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden wikipedia-Name: name=freiburg opengeodb:name=Freiburg im Breisgau wikipedia:de=Freiburg_im_Breisgau openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich sind, teils direkt durch Benutzerwunsch. Von daher waere 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem Feld einfach nur eine Abkuerzung. generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Was haltet ihr davon? IMHO fuer OSM wichtig ist vor allem die loc_id als Referenz zur opengeodb selbst. Hilfreich erscheint mir die part_of / is_in_locid / Teil von / 40010 wie auch die AGS / community_identification_number / Gemeindeschlüssel / 50060 level / layer / Ebene / 40020 ist für die Hierarchien in der openbeodb wichtig und steckt in Deutschland bis zur Gemeindeebene auch implizit im AGS (zweistellig: Bundesland bis achtstellig: Gemeinde). Es gibt die Überlegungen, den AGS auch als nicht-amtlichen oder halb-amtlichen Gemeindeschlüssel bis ganz nach unten durchzuziehen. Beispielsweise gibt es amtliche fünfstellige Strassenschlüssel, also 13stellige Schlüssel für jede einzelne (Gemeinde-)Strasse in Deutschland. Postleitzahlen sind einerseits sehr attraktiv, andererseits aber sehr problematisch: für eine korrekte Zuordnung müsste man in der OSM eine durchgehende Strasse tatsächlich an der PLZ-Grenze trennen. Es kann sogar sein, dass eine Strasse zu einer PLZ gehört, die Anschriften an dieser Strasse aber durch die postalische Zuordnung ganz anderen PLZ-Einträgen zugeordnet sind - in Österreich scheint das gängige Praxis zu sein. Von den Namesvarianten würde ich nur name / 50010 verwenden, je nach Bedarf auch NAME_7BITLC / sort_name / ASCII / 50012 Die anderen Namensvarianten sind wenig interessant. Hier muss aber
Re: [Talk-de] landuse = forest oder natural=wood
Ich finde, die Unterscheidung ist überflüssig. Am besten wäre es, wir würden einen der beiden Keys abschaffen. Da die beiden Dinge in Mapnik auch noch auf unterschiedlichen Zoomstufen gerendert werden, entstehen so schief aussehende Karten. Zugegeben, dies könnte (müsste) bei den Renderern geändert werden. Die gegenwärtige Praxis ist mMn weitgehend wilkürlich. Ich verwende jetzt nur noch landuse=forest, nachdem ich zuvor einige zeitlang natural=wood genommen habe. Ich glaube aber, die Mehrheit verwendet mittlerweile landuse=forest. Eine Auszeichnung der Flächen mit beiden Attributen, wie von keichwa vorgeschlagen, finde ich auch nicht so gut. Longbow4u ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forest oder natural=wood
Ich finde, die Unterscheidung ist überflüssig. Am besten wäre es, wir würden einen der beiden Keys abschaffen. Ich finde, nur weil es in D/CH nicht sehr oft vor kommt, ist das kein Grund es abschaffen zu wollen. Es gibt einen Unterschied, mag er auch in unserer Region kleiner sein als anderswo. Trotzdem sollten wir ihn berücksichtigen. Da die beiden Dinge in Mapnik auch noch auf unterschiedlichen Zoomstufen gerendert werden, entstehen so schief aussehende Karten. Zugegeben, dies könnte (müsste) bei den Renderern geändert werden. Die gegenwärtige Praxis ist mMn weitgehend wilkürlich. IMO entstanden die aktuellen Zuordnungen nicht aus willkür (CH ist fast alles natural=wood), sondern aus unklar- oder unwissenheit. Grüsse Raphael ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Tagwatch vom 9.01.2008
Moin. Ich habe heute mal wieder den neusten planet.osm ausschnitt von Deutschland [1] genommen und eine neue Tagwatch Seite erstellt. Dabei hab ich auch gleich ein wenig an dem script dazu rumgefummelt. Der eigentlich unterschied zu vorher besteht lediglich darin, das die Beschreibungen zu den einzelnen Tags aus dem Template auf den jeweilgen [[Tag:Key=Value]] seiten kommen oder wenn diese nicht existiert von den unterseiten der Tagwatch Seite geholt werden. Ist beides nicht vorhanden, werden die Tags am unteren Rand der Seite ohne weitere Informationen aufgelistet. Zudem wird angezeigt ob es sich bei dem jeweiligen Tag um einen Node, Way oder Area handelt. Desweiteren wird die feature palette von osmarender6 genommen um die beispiele zu rendern. Viel spaß beim durchwühlen. http://etricceline.de/osm/index.htm Gruß Jörg --- [1] http://download.geofabrik.de/osm/europe/germany.osm.bz2 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Raphael Studer schrieb: ... Für mich gilt als Entscheidungskriterium ob landuse oder natural, ob dort absichtlich Wald gepflantzt wurde um ihn zu nutzen (z.B. Christbaumplantagen oder Baumschulen) oder ob der Wald schon immer da war und sich ein Förster etwas darum kümmert. interessanter Unterscheidungsansatz Jau. Christbaumplantagen oder Baumschulen wären besser als landuse=farm zu taggen (plus natural=wood). der Wald schon immer da das ist schon eine nette vorstellung :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Am Mittwoch, 9. Januar 2008 16:14 schrieb Andreas Hubel: Also wenn ich mir das so anschaue, würde ich nicht alle Daten der OpenGeoDB direkt übernehmen. Ja, da gibt es mehrere Ansätze. Ich will gerne begründen, warum ich alle Daten aus der OpenGeoDB auch in OSM haben möchte. OpenGeoDB ist im deutschsprachigen Raum sehr gut, aber leider nur dort. Wenn jetzt jemand von außerhalb Daten wie z.B. Postleitzahlen benutzen möchte muss er entweder openGeoDB kennen oder die Daten müssen in OSM stehen. In Wikipedia gibt es den Grundsatz: das Wikipedia kein Platzproblem hat, und genau das sehe ich für OSM auch, die Daten werden ja benutzt, sonst würde ja auch niemand OpenGeoDB nutzen, warum soll man sie nicht auch ohne Medienbruch gleich in OSM nutzen können. ich denke die ganzen is_in Felder sollte man raus lassen. is_in kommt aus der Zeit in der es noch keine Relations gab. Ich denke das Tag sollte man irgendwie als veraltet oder so kennzeichnen. Wenn es nicht mehr genutzt wird, ist es ganz einfach es überall zu entfernen. Im Moment wird es z.B. bei www.openstreetmap.org in der Suche benutzt. Und ich erzeuge ja auch noch zusätzlich Relationen, damit man auf das Tag nicht angewiesen ist. openGeoDB:type, openGeoDB:layer, openGeoDB:location sind Teilweise einfach redundant und sagen das selbe aus. Eigendlich sollte man das via place=xyz ausdrücken. Wenn sie wirklich redundant sind, kann sie ja jemand aus der OpenGeoDB löschen. Dann tauchen sie beim nächsten Update nicht mehr auf. Wenn sie doch irgend einen Sinn haben ist es doch schön sie direkt in OSM suchen zu können. Ist openGeoDB:name und name wirklich nötig? Nur name würde doch reichen. Ja, solange der Name und der OpenGeoDB Name identisch sind. Aber ein Benutzer kann (uns soll ja auch jederzeit dürfen!!) den Namen ändern. Werte die mit OpenGeoDB: anfangen, sollte er möglischst nicht ändern, denn die kommen ja (in jedem Fall) aus der OpenGeoDB Datenbank, und werden beim nächsten Import überschrieben. openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Warum? Der String wird automatisch erzeugt und für den Benutzer ist es angenehmer die URL zu kennen. Wer mal versucht hat mittels google auf die URL http://fa-technik.adfc.de/code/opengeodb/dump/ zu kommen wird mir bestimmt recht geben, dass die Daten im Moment alles andere als einfach zu finden sind. openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, generell find ich die Übersetung irgendwie seltsam. Zumal das sowieso nur für Deutschland eindeutig ist. Ich wäre da fast für einen Deutschen Namensraum, z.B. de:KFZ. Analog dazu bei den Gemeindeschlüsseln de:AGS. Nun ist OpenGeoDB ja nicht nur für Deutschland sondern auch für ein paar Nachbarländer aktiv und ich möchte nur eine Übersetzung einfügen. Ich hatte auch mal Überlegt ob ich mir die Sache einfach mache und stattdessen einfach: openGeoDB:50060 statt openGeoDB:community_identification_number nehmen sollte, finde es aber besser sprechende Namen zu verwenden. Bin gerade etwas frustiert, weil ich das Gefühl hatte, nach der letzten Rückmeldung (die ich im übrigen sehr konstruktiv fand!!), jetzt wirklich los zu legen und nicht wieder über so grundlegende Designfragen diskutieren zu müssen, aber laßt Euch davon nicht abhalten, denn es wird ja eher besser, wenn ein paar mehr Leute Ihren Sempf dazu geben! Gruß Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Alpha: OpenGeoDB - OSM
Am Mittwoch, 9. Januar 2008 17:17 schrieb Martin Trautmann: openGeoDB:sort_name würde ich rauslassen und falls openGeoDB:ISO-3166-2 sowas die de für Deutschland ist würde ich das als iso_contry_code oder nur iso_code kennzeichnen. http://wiki.openstreetmap.org/index.php/User:OpenGeoDB nennt hier 50011 name Ja, das war ein Übertragungsfehler. Ich meinte: 50010. Kann das im Moment nicht im Wiki ändern (gibt ne Fehlermeldung beim bearbeiten der Seite). Tatsaechlich steckt der eigentliche Name in 50010 (vergleiche http://kent.dl.sourceforge.net/sourceforge/opengeodb/Constants.txt wo noch die Konstanten der Version 0.2.4 beschrieben werden - die 400* kamen mit 0.2.5 und 0.2.6 erst hinzu) In der Name (50010:NAME) steckt die vollstaendige Namensbezeichnung drin, wie z.B. Freiburg im Breisgau. Das ist IMHO für OSM der Name, weil auf einer Landkarte ja üblicherweise auch die Bezeichnung ausgeschrieben wird. Die 50011 wird derzeit nicht wirklich genutzt. Interessant ist eher die 50012, die 7Bit-Schreibweise, beschraenkt auf den Basisteil wie freiburg (lower case, no Umlauts, no extensions) solange beides identisch ist, reicht name. Den openGeoDB-Name wuerde ich nur bei Abweichungen nenne, so wie z.B. auch einen abweichenden wikipedia-Name: name=freiburg opengeodb:name=Freiburg im Breisgau wikipedia:de=Freiburg_im_Breisgau Warum nicht trotzdem alles nennen, es ist ja ne Zusatzinformation, dass diese Daten in anderen Quelle auch so verzeichnet sind, also z.B. name=München openGeoDB:name=München wikipedia:de=München Das hat auch den Vorteil, das man auch als Benutzer schnell mal einen Tippfehler finden könnte. Wenn z.B. sowas auftaucht: name=Muenchen openGeoDB:name=München openGeoDB:version ist meiner Meinung nach mit 0.2.6.11 / 2007-12-04 / http://fa-technik.adfc.de/code/opengeodb/dump/; zu lang. Nur die Version 0.2.6.11 sollte reichen. Ja, genau - wobei auf fa-technik.adfc.de beliebige zwischendumps moeglich sind, teils direkt durch Benutzerwunsch. Von daher waere 0.2.6.11_2007-12-04 oder 02611_20071204 sinnvoll. Warum darf der String nicht länger sein? Gibt es irgend ein Problem wenn der String zu lang wird? openGeoDB:license_plate_code = BW für BaWü ist irgendwie seltsam, Offiziell heisst das car_licence_code. Solche gibt es eigentlich nur auf Kreisebene (z.B. FR: Stadt Freiburg und Landkreis Breisgau im Schwarzwald) bzw. die Ebenen darunter. Auf Bundesland-Ebene steckt in dem Feld einfach nur eine Abkuerzung. Das finde ich nicht so gut (das ein Feld auch noch für einen anderen Zweck benutzt wird, denn es gibt ja kein Autokennzeichen: BW) Ich hatte in einer früheren Version Die anderen Namensvarianten sind wenig interessant. Hier muss aber darauf hingewiesen werden, dass es auch landesspezifische Varianten gibt, z.B. opengeodb:name=Deutschland opengeodb:name:en=Germany opengeodb:name:fi=Saksa opengeodb:name:he=גרמניה usw. Ist genau so implementiert. Bei Daten wie population / 60070 muss beachtet werden, dass solche Daten in der opengeodb in der Regel mit einer Datumsangabe kombiniert sind - z.B. gültig am Stichtag 2006-12-31 (genauer: von 2006-12-31 bis 2006-12-31). Guter Hinweis: den Stichtag sollte ich hier noch hinzufügen. Ich hab eben mal nachgesehen, warum ich das nicht gemacht habe: mysql select * from geodb_intdata where valid_until3000-01-01; Empty set (0.00 sec) Ist wohl erst in neueren Versionen drin. Ich hatte gehofft, das in OpenGeoDB nicht mehr so viel Bewegung im Datenschema ist. Gruß Sven Anders ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Parkplatz
Am 08.01.2008 17:49 schrieb Christian Maurer: André Reichelt schrieb: Dimitri Junker schrieb: Hm, mein Medion setzt alle halbe Meter einen Punkt. Da kann man sogar erkennen, wenn man einen Schritt nach links geht. Also entweder Ihr verwendet schlechte GPS-Systeme oder ich mache irendetwas falsch/besser. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de das kann schon sein das dein medion das macht, und ich glaub dir auch noch das man den schritt nach links sieht, ABER mach das ganze sagen wir 4x im abstand von je 2 std, wenn die 4 tracks dann immer noch übereinanderliegen dann will ich auch so einen medion haben... Eben. Auflösung und Genaugkeit sind zwei paar Schuhe. Mit hoher Auflösung falsche Daten anzeigen ist durchaus möglich.-) Harald. --+- Harald Kirsch | pifpafpuf bei gmx punkt de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Radfahrer absteigen, Hunde
Am Montag, den 07.01.2008, 17:34 +0100 schrieb Guenther Meyer: Am Montag 07 Januar 2008 schrieb Daniel Schmidt: * Radfahrer absteigen: Hier führt ein Radweg über eine Brücke. Auf der Brücke selbst dürfen die Räder jedoch nur geschoben werden. bicycle=no waere richtig! ich wuerds nur als fussweg taggen - ohne angabe fuer fahrraeder. Nach der Beschreibung ist es ein Radweg über eine Brücke bei dem die Räder aber nur geschoben werden dürfen. Also: highway=cycleway bicycle=no ;-) Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] opengeodb: Nordrhein-Westfalen
In OSM selbst sind die Grenzlinien überhaupt noch nicht drin? IMHO sollten sie dort vordringlich mit aufgenommen werden. Ich halte verwaltungsgrenzen nicht für vorrangig wichtig. Zumindest nicht in D und auch nicht in der EU. Für mich haben wald- und sonstige grünflächen sowie flüsse und schienenstrecken eine hohe priorität :) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Duplicated Nodes und wie man sie los wird
Raphael Studer schrieb: AFAIK kann die JOSM auch automatisch beheben, indem man die Karte Validiert und ahschliessend FIX drückt. Ja, mit dem Validator-Plugin von JOSM gibt es die Möglichkeit das automatisch fixen zu lassen. Allerdings kann es bei Punkten ausserhalb des Download-Rechtecks sein, dass den doppelten Punkten ein nicht heruntergeladener Weg zugeordnet ist. Bei Hochladen kommt dann die etwas verwirrende Meldung Precondition failed. Gruss, Andy signature.asc Description: Dies ist ein digital signierter Nachrichtenteil ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Nicht mehr durchflossene Flussbetten
Hat jemand eine wie man diese nicht mehr durchflossenen Flussbetten taggt ? Um hier kurz auszuführen was ich meine: Im Lauf seines Lebens windet sich ein Fluss kurvig durch die Natur, immer auf der Suche nach dem schnellsten Weg. Wenn also ein Fluss einen kürzeren Weg findet, kann es sein, dass eine Schlinge nicht mehr durchflossen wird und mit der Zeit vom Fluss abgetrennt wird um zu einem stehenden Gewässer wird, da es ja noch Wasser führt, aber keine Verbindung mehr zum Fluss hat. Wie würdet ihr sowas taggen ? Ein waterway=river ist es ja nicht mehr. Aber es als See via natural=water zu taggen widerstrebt mir auch ein bisschen. -- Sebastian Gebhard PGP: 6CD7EBCE www.sege-mag-dich.net ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Wie weit sind wir in der Schweiz ?
Andreas Stricker [EMAIL PROTECTED] wrote: Das zeigt, dass OSM gerade für Fussgänger sehr attraktiv werden kann. Das zeigt, dass OSM auch für Wanderer Potenzial hat! Die Mehrzahl der Fußwege dürften Wanderwege sein, die von Touristen gezeichnet wurden. Nur mal so als Beispiel. Den Wanderweg über den Lötschenpass, auf dem ich letzen Sommer unterwegs war z.B. (ganz im Gegensatz zur Straße ins Gasterntal) bei OSM existent. BTW, der GPS Empfang in solchen vergleichsweise schmalen Bergtälern ist alles andere als optimal. Mein SIRF II hatte damit jedenfalls echte Probleme. Das ist auch der Grund weshalb ich die genannte Straße bisher nicht gezeichnet habe. Wie sieht das eigentlich rechtlich aus, wenn man solche Straßen in Google Earth aus dem Luftbild abmalt und das Polygon dann mit josm in Straßen umwandelt. Ist sowas legal? Ich finde ja sowieso, dass wir eigentlich dringend halbwegs brauchbare Richtlinien für Wanderwege brauchen. Gruss Sven -- I'm a bastard, and proud of it (Linus Torvalds, Wednesday Sep 6, 2000) /me is [EMAIL PROTECTED], http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Erste Test-Daten von OpenGeoDB
Hallo Holger, Holger Issle schrieb: In Weil und Umgebung gibt es ein paar Spinner, die auch die Namen der Feld- und Waldwege erfasst haben, so es welche gibt. Nur die markanten Punkte im Schönbuch (Waldgebiet) fehlen noch ;-) Eh ? Was soll das denn heissen ? Na klar erfasse ich Wegenamen im Schönbuch. Der Wanderverein (oder wer auch immer) hat sich die Mühe gemacht, Holzschilder mit Namen wie Hoppelesklingensträßchen zu schnitzen und an die Bäume zu nageln. Warum nicht ins OSM damit ? Übrigens hat unsere Gemeinde kürzlich die Standorte der Hundetoiletten veröffentlicht. Das könnte man genausogut aufnehmen, schliesslich mag es ja gewissenhafte Hundebesitzer geben, die sich im Notfall zum nächtgelegenen Beutelspender Fussgänger-navigieren lassen wollen. Vorschläge für amenity-tags sind willkommen. Grüsse, Andreas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Nicht mehr durchflossene Flussbetten
Sebastian Gebhard schrieb: Ein waterway=river ist es ja nicht mehr. Aber es als See via natural=water zu taggen widerstrebt mir auch ein bisschen. Also die Engländer nennen sowas oxbow-lake, also See. Und da deren Interpretation der Tags bei OSM das Maß der Dinge ist, weil die Tags in/nach deren Sprache eingeführt werden würde ich mich daran halten das Ding als See zu taggen. Aber davon abgesehen spielt bei meiner Auffassung von See die Entstehung keine Rolle, sondern was es jetzt ist. Vollgelaufene Kiesgruben würde ich auch als See taggen. Und das dieser See mal ein Fluss war erschließt sich ja aus der Form und dem angrenzenden Fluss. Aber wenn du gesonderten Wert darauf legst, kannst du ja zusätzlich ein oxbow=yes taggen. Ist ja alles möglich. http://en.wikipedia.org/wiki/Oxbow_lake Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] dead-end-Gleise z.B. in Kopfbahnhof
Mario Salvini schrieb: gibts da schon ne Methode die gesondert zu markieren? Wäre ja schon sinnvoll, bei ausgefallenen GLiskontrukten, ob ein Gleis nur noch nciht zuende erfasst wurde, oder einfach ein Ende hat. Für Straßen gibt's da noexit=yes: http://wiki.openstreetmap.org/index.php/Key:access#noexit Wieso sollte man das nicht analog auch für Schienenwege verwenden? Grüße, Sven ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[Talk-de] Linuxtag 2008 Berlin
Hallo, am Freitag laeuft die Abgabefrist fuer Papers zum Linuxtag 2008 in Berlin ab. Wenn niemand anders dazu Lust hat, werde ich einen OpenStreetMap-Vortrag einreichen, aber ich will mich nicht vordraengeln ;-) Unabhaengig davon wird es hoffentlich auch wieder einen kleinen OSM-Stand geben, aber das muss man zum Glueck noch nicht jetzt planen. Bye Frederik -- Frederik Ramm ## eMail [EMAIL PROTECTED] ## N49°00.09' E008°23.33' ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] landuse = forrest oder natural=wood
Jau. Christbaumplantagen oder Baumschulen wären besser als landuse=farm zu taggen (plus natural=wood). der Wald schon immer da – das ist schon eine nette vorstellung :) Wenns nicht so ist, dass der Wald schon da war bevor wir da waren, dann korrigier mich bitte. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
Re: [Talk-de] Duplicated Nodes und wie man sie los wird
Ja, mit dem Validator-Plugin von JOSM gibt es die Möglichkeit das automatisch fixen zu lassen. Allerdings kann es bei Punkten ausserhalb des Download-Rechtecks sein, dass den doppelten Punkten ein nicht heruntergeladener Weg zugeordnet ist. Bei Hochladen kommt dann die etwas verwirrende Meldung Precondition failed. Weshalb wird ein Punkt ausserhalb des Download Rechtecks herunter geladen? Das geschieht doch nur wenn er zu einem Weg gehört und somit wär dieser Weg auch dabei oder? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-de
[OSM-talk-fr] Hyerarchisation (Was: Voies sur berges Parisiennes)
Je pense (abusivement?) que si la carte est claire à lire pour un humain, un logiciel s'y retrouvera encore plus aisément. D'une manière générale, abuser des tags primary et secondary dans une ville nuit à la lisibilité pour l'humain, et risque de conduire un logiciel à calculer un itineraire au plus court, avec force changements de direction à cause de la surabondance d'axes définis comme principaux, alors qu'on lui a demandé le plus rapide. J'ai remarqué aussi que j'avais du mal à utiliser le tag tertiary, je sais pas si c'est le cas de tout le monde. Une fois les 2-3 grands axes de la ville taggés en primary, les voies transversales partant de ces axes taggés en secondary, il me faut parfois me casser un peu la tête pour débusquer les routes principales parmis les voies les plus petites, celles qui présentent un intéret (et en général un trafic) plus fort que les autres et permettent une désserte de leurs voisines. Fort de ce constat, j'ai tendance à penser qu'il y a vraiment moyen de limiter l'utilisation du primary aux axes qui ont un bon débit et traversent l'agglomération, et secondary à ceux qui ont un intérêt particulier pour la désserte des quartiers. C'est à la fois plus joli sur la carte et je pense davantage susceptible de donner des itinéraires calculés rapides vraiment rapides. - Message d'origine De : Pieren Pieren [EMAIL PROTECTED] À : Discussions sur OSM en francais talk-fr@openstreetmap.org Envoyé le : Mercredi, 9 Janvier 2008, 13h45mn 56s Objet : Re: [OSM-talk-fr] Voies sur berges Parisiennes La hiérarchisation des voies est un sujet difficile. Je le vois aussi dans ma région. Mais il ne faut pas uniquement voir le côté ça fait joli sur la carte. Il faut essayer de séparer la signification des tags et le résultat sur mapnik ou osmarender même si on a tous une tendance naturelle à choisir ce qui donnera le mieux. Il faut songer au fait que les logiciels de rendus évoluent dans le temps, ou peuvent s'adapter aux pays concernés ou même de nouveaux logiciels peuvent apparaître comme ceux qui font de la navigation. Dans ce cas précis, un logiciel de navigation devra chercher une route qui n'est pas forcément la plus directe mais éventuellement la plus rapide. La hiérarchisation peut entrer en ligne de compte ici. Je n'ai pas de réponse pour les voies sur berge, mais trunk est par défaut en France une voie express de 2 voies en sens unique, limitée à 110 et interdite aux 2 roues et véhicules lents. Si tu tagues en primary, il faudrait tracer 1 way avec lanes=2 et oneway=true + les tags de restriction d'accès. En choisissant trunk, tu ajoutes juste un maxspeed=50. On Jan 9, 2008 9:54 AM, [EMAIL PROTECTED] wrote: C'était 70 km/h sur la plupart des portions jusqu'au 27/11 dernier. C'est 50km/h depuis. On pourrait penser que ce n'est pas très élevé pour une voie rapide mais étant donné que la moyenne sur les rues normales est de 15km/h environ... Au niveau du nombre de file, je vais vérifier mais il me semble que c'est au moins 2 partout. Au niveau de la hierarchisation des voies de Paris, j'en ai fait une partie significative mais je ne suis pas encore satisfait notamment sur la rive gauche. Je ne suis pas certain que le boulevard Pasteur et le boulevard de Grenelle peuvent être considérés comme des voies primaire depuis qu'il n'y a quasiment plus qu'une file de circulation. Par contre, le boulevard des invalides que j'ai laissé en secondary est beaucoup plus roulant. J'hésite aussi à passer les boulevard de l'Hopital, St Marcel et Port Royal en primary Autre chose, j'ai complété il y a quelques semaines les échangeurs sud-est du Boulevard Périphérique le rendu n'est pas terrible mais je ne voie pas bien comment je peux gérer les différents tags bridge/tunnel en combinaison avec les layers. Si vous avez des idées, je suis preneur. http://www.openstreetmap.org/?lat=48.82788lon=2.3887zoom=16layers=B0FT Simon Le 08/01/08, Yann SLADEK [EMAIL PROTECTED] a écrit : 50 maintenant normalement (je les ai pas repris depuis) Personnellement, je suis pour le trunk car ca suit la définition du wiki : Voie rapide ou voie express. Ce qui est le cas. a+ Yann quelle est la limitation de vitesse de ces voies ? Axel Les voies sur berges Parisiennes (Voie Georges Pompidou et Voies sur Berges Rive gauche) sont des voiesspéciales dans le sens où elles sont interdites aux piétons et aux deux roues non motorisés, qu'il n'y a pas de feux de signalisation et qu'elles disposent de voies d'accès et de sortie. Ces caractéristiques sont plus proche du tag highway=trunk que de highway=primary. Les voies d'accès pourraient être taggées en highway=trunk_link. Ceci pourrait peut être rendre le centre de Paris plus lisible en évitant de faire figurer deux voies parallèles dans le même sens de circulation(le quai et la voie sur berge) avec le tag highway=primary. Votre avis sur la question ?? Simon
[OSM-talk-fr] Deuxième article sur Openstreetmap sur vnunet cette fois-ci
Bonjour, Voici un article paru aujourd'hui sur vnunet.fr : http://www.vnunet.fr/fr/news/2008/01/09/openstreetmap_veut_liberer_les_cartes_du_monde Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-fr
[Talk-GB] Oxford hi-res on Yahoo
Socks on IRC has just spotted Oxford has gone hi-res. Any other additions? cheers Richard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
Re: [Talk-GB] Oxford hi-res on Yahoo
Part of Nottingham also appears to have been added to the coverage. :-) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Richard Fairhurst Sent: 9 January 2008 15:22 To: talk-gb@openstreetmap.org Subject: [Talk-GB] Oxford hi-res on Yahoo Socks on IRC has just spotted Oxford has gone hi-res. Any other additions? cheers Richard ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/cgi-bin/mailman/listinfo/talk-gb
