[OSM-legal-talk] Is the license change easily reversible?
Hi, the following occurred to me today, and I would be interested to hear other people's thoughts about it. What I'm writing here is not at all news; I just hadn't thought about it until now. In the Contributor terms, the license that OSM data is distributed under is mentioned in this way: OSMF agrees that it may only use or sub-license Your Contents ... under the terms of one or more of the following licences: ODbL 1.0 for the database and DbCL 1.0 for the individual contents of the database; CC-BY-SA 2.0; or such other free and open licence (for example, http://www.opendefinition.org/okd/) as may from time to time be chosen by a vote of the OSMF membership and approved by at least a 2/3 majority vote of active contributors. It is clear that the license can be changed to a different one at any time through the 2/3 provision. But, even after the switch to ODbL, OSMF could go back to CC-BY-SA 2.0 at any time - and would, as far as I can see, only need a simple majority board decision for that. This puts OSMF in a position of quite some power. Let us assume for a moment that there are a few big players waiting in the wings with products ready to be launched once the license change has come through; products that have been designed for over a year and at considerable cost. Assume someone launches a few months after the license change, and further assume that there is something we (as a project) are unhappy about. Say they mix their proprietary data with OSM data in a way where *we* think they have to release something back but *they* point to the legal analysis they have been doing for the last two years and say no way, Jose, come sue us if you dare, mwhahahaha. Could we - could OSMF - in such a situation simply say: Know what, Mr big guy? Either you play nice and release that data, or we'll simply go back to CC-BY-SA 2.0 next month. I don't assume that we would really *want* to go back but it wouldn't exactly kill us, and depending on what is at stake (I assume it could easily be a multi million dollar thing) we (the project) would lose much less than those we'd be up against. We wouldn't really want to but we *could*, and the fact that the big guy would only have to piss off the wrong four people at OSMF to ruin his product could balance one thing or the other in our favour. Questions arising from this - 1. Is my reasoning correct? 2. Are we happy with OSMF board wielding this power - should we (the OSMF membership) perhaps curtail OSMF board's powers by creating a rule that says that any decision regarding the license under which the data is published must be taken by the whole membership and not just the board? 3. If the CTs were changed post-license-change to omit CC-BY-SA 2.0 from the list of available licenses, then the above scenario would become impractical - we could then not simply go back to CC-BY-SA 2.0 without losing data from new contributors (unless going through the 2/3 rule). Such a change in the CTs would create more security for anyone investing in a product based on our data by taking away the bargaining chip I have written about. Does the power to change the CTs currently sit with the board alone, and are we happy with that? The power to modify the CTs carries with it the power to entrench the current license practically forever; someone with liberty to change the CT as they see fit could, for example, simply strike out the future license change possible with 2/3 of active contributors clause and therefore create a situation in which no future OSMF can change the license without going through what we go through now. Of course the CTs cannot be changed retroactively but doing so for new signups is effective enough. Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
Re: [OSM-legal-talk] Is the license change easily reversible?
On 19/02/12 11:17, Frederik Ramm wrote: But, even after the switch to ODbL, OSMF could go back to CC-BY-SA 2.0 at any time - and would, as far as I can see, only need a simple majority board decision for that. Yep. And 2.0 could then be upgraded to a higher version with the next planet dump. This might be desirable if, for example, 4.0 has irresistibly wonderful database right handling. Everyone is following the CC 4.0 drafting process and providing input, right? :-) This puts OSMF in a position of quite some power. [inserts quote about power and responsibility.] Could we - could OSMF - in such a situation simply say: Know what, Mr big guy? Either you play nice and release that data, or we'll simply go back to CC-BY-SA 2.0 next month. Yep. Although they could continue to use the existing data. Which might make delicensing feel less of a(n immediate) threat. I don't assume that we would really *want* to go back but it wouldn't exactly kill us, and depending on what is at stake (I assume it could easily be a multi million dollar thing) we (the project) would lose much less than those we'd be up against. We wouldn't really want to but we *could*, and the fact that the big guy would only have to piss off the wrong four people at OSMF to ruin his product could balance one thing or the other in our favour. Protecting the freedom of individuals to use the data that OSM gathers and distributes isn't about pissing people off, etc., but yes there is apparently a nuclear option there. The collateral damage would be eye-watering though, in terms of burnt karma, lost trust, and punishment of innocent actors. 1. Is my reasoning correct? I believe so. 2. Are we happy with OSMF board wielding this power - should we (the OSMF membership) perhaps curtail OSMF board's powers by creating a rule that says that any decision regarding the license under which the data is published must be taken by the whole membership and not just the board? Do you mean the foundation membership or active contributors to OSM? 3. If the CTs were changed post-license-change to omit CC-BY-SA 2.0 from the list of available licenses, then the above scenario would become impractical - we could then not simply go back to CC-BY-SA 2.0 without losing data from new contributors (unless going through the 2/3 rule). The CTs could then be changed back, and data contributed prior to the initial change could be licenced back down. Such a change in the CTs would create more security for anyone investing in a product based on our data by taking away the bargaining chip I have written about. Does the power to change the CTs currently sit with the board alone, and are we happy with that? Pass. The power to modify the CTs carries with it the power to entrench the current license practically forever; someone with liberty to change the CT as they see fit could, for example, simply strike out the future license change possible with 2/3 of active contributors clause and therefore create a situation in which no future OSMF can change the license without going through what we go through now. Of course the CTs cannot be changed retroactively but doing so for new signups is effective enough. And this is part of the problem with listing specific licences. The CTs should explain the idea, not fossilize the expression. Yes, this will impose large social and time costs on future decisions by requiring interminable debate about whether any change fits the spirit and the letter of what is intended. But that is better than not being able to do so, or having to change the CTs in order to allow it by fiat. Changing the CTs doesn't exactly seem to make people feel loved. - Rob. ___ legal-talk mailing list legal-talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/legal-talk
[OSM-talk] Printed map books
In my car I still use a printed map book, which I'd like to replace with one using OSM data and was wondering if anyone had any suggestions. The features I consider requirements are - Tiled pages with an index map at the front of the book - Arrows on each page indicating the number of the adjacent pages I'd also like - A street index at the back, indicating the street, city, map page and map grid I've looked at the wiki, but all of the programs I saw used osmarender ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Printed map books
I had vaguely considered this as something that could be done with
OpenStreetPad. It ought to be pretty easy with its rendering architecture to
get OS X to output a PDF document instead of some pretty images on the screen.
If you're able to hack on an obj-c project then it could be a good route.
Bob
if (*ra4 != 0xffc78948) { return false; }
On 19 Feb 2012, at 08:10, Paul Norman wrote:
In my car I still use a printed map book, which I'd like to replace with one
using OSM data and was wondering if anyone had any suggestions.
The features I consider requirements are
- Tiled pages with an index map at the front of the book
- Arrows on each page indicating the number of the adjacent pages
I'd also like
- A street index at the back, indicating the street, city, map page and map
grid
I've looked at the wiki, but all of the programs I saw used osmarender
___
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] Printed map books
Hi Paul, I asked about this a while ago on the thread Generating a street directory from OSM? and got some good answers. Some relevant links that came up: http://code.google.com/p/townguide http://www.townguide.webhop.net/ http://www.maposmatic.org Steve On Sun, Feb 19, 2012 at 7:10 PM, Paul Norman penor...@mac.com wrote: In my car I still use a printed map book, which I'd like to replace with one using OSM data and was wondering if anyone had any suggestions. The features I consider requirements are - Tiled pages with an index map at the front of the book - Arrows on each page indicating the number of the adjacent pages I'd also like - A street index at the back, indicating the street, city, map page and map grid I've looked at the wiki, but all of the programs I saw used osmarender ___ 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] Printed map books
Hi, The two 'townguide' ones are mine, but the demonstration web service at townguide.webhop.net is not working, sorry (had a little disk crash a year ago, and never quite got around to putting it back together...) Getting a nice printable booklet working has been on my todo list for ages - there is a rough implementation of it in the townguide code, but that is really a proof of concept rather than a finished work.I must admit to not developing townguide recently, but if there is demand for this, I will have a go at getting a booklet implementation workingyou will have to give me a few weeks though, but the code is all open source, so if you would like to work on it, I can explain how it works. I think there is another option called pdfatlas - This is aiming to do something similar, but I failed to get it working when I tried - can't remember why though - worth searching on the OSM wiki for it. Regards Graham. On 19 February 2012 08:55, Steve Bennett stevag...@gmail.com wrote: Hi Paul, I asked about this a while ago on the thread Generating a street directory from OSM? and got some good answers. Some relevant links that came up: http://code.google.com/p/townguide http://www.townguide.webhop.net/ http://www.maposmatic.org Steve On Sun, Feb 19, 2012 at 7:10 PM, Paul Norman penor...@mac.com wrote: In my car I still use a printed map book, which I'd like to replace with one using OSM data and was wondering if anyone had any suggestions. The features I consider requirements are - Tiled pages with an index map at the front of the book - Arrows on each page indicating the number of the adjacent pages I'd also like - A street index at the back, indicating the street, city, map page and map grid I've looked at the wiki, but all of the programs I saw used osmarender ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Printed map books
Hi, I tried to use Hikingbook.pl[0] by Gary68, but I wasn't successful (I wanted to use it together with his next project, Mapweaver) I saw also Osmbook[1] but was limited in rendering. Regards, Stefano [0] http://wiki.openstreetmap.org/wiki/Hikingbook.pl [1]http://wiki.openstreetmap.org/wiki/Osmbook ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Printed map books
Pdfatlas appears to use a custom rendering language, and I'd rather avoid that. It also hasn't been updated in 5 years. What I'm considering writing is a set of python scripts that build the map with mapnik and then piece the pages together. Do you think inkscape is the easiest way to build the PDFs from the command line? From: Graham Jones [mailto:grahamjones...@gmail.com] Sent: Sunday, February 19, 2012 1:08 AM To: Steve Bennett Cc: Paul Norman; talk@openstreetmap.org Subject: Re: [OSM-talk] Printed map books Hi, The two 'townguide' ones are mine, but the demonstration web service at townguide.webhop.net is not working, sorry (had a little disk crash a year ago, and never quite got around to putting it back together...) Getting a nice printable booklet working has been on my todo list for ages - there is a rough implementation of it in the townguide code, but that is really a proof of concept rather than a finished work.I must admit to not developing townguide recently, but if there is demand for this, I will have a go at getting a booklet implementation workingyou will have to give me a few weeks though, but the code is all open source, so if you would like to work on it, I can explain how it works. I think there is another option called pdfatlas - This is aiming to do something similar, but I failed to get it working when I tried - can't remember why though - worth searching on the OSM wiki for it. Regards Graham. On 19 February 2012 08:55, Steve Bennett stevag...@gmail.com wrote: Hi Paul, I asked about this a while ago on the thread Generating a street directory from OSM? and got some good answers. Some relevant links that came up: http://code.google.com/p/townguide http://www.townguide.webhop.net/ http://www.maposmatic.org Steve On Sun, Feb 19, 2012 at 7:10 PM, Paul Norman penor...@mac.com wrote: In my car I still use a printed map book, which I'd like to replace with one using OSM data and was wondering if anyone had any suggestions. The features I consider requirements are - Tiled pages with an index map at the front of the book - Arrows on each page indicating the number of the adjacent pages I'd also like - A street index at the back, indicating the street, city, map page and map grid I've looked at the wiki, but all of the programs I saw used osmarender ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk -- Graham Jones Hartlepool, UK. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Printed map books
My townguide python script does that - it uses a library to put the mapnik generated images onto pdf pages along with other text. from my phone On 19 Feb 2012 09:37, Paul Norman penor...@mac.com wrote: Pdfatlas appears to use a custom rendering language, and I’d rather avoid that. It also hasn’t been updated in 5 years. ** ** What I’m considering writing is a set of python scripts that build the map with mapnik and then piece the pages together. Do you think inkscape is the easiest way to build the PDFs from the command line? ** ** ** ** *From:* Graham Jones [mailto:grahamjones...@gmail.com] *Sent:* Sunday, February 19, 2012 1:08 AM *To:* Steve Bennett *Cc:* Paul Norman; talk@openstreetmap.org *Subject:* Re: [OSM-talk] Printed map books Hi, The two 'townguide' ones are mine, but the demonstration web service at townguide.webhop.n... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-de] building:type - Ergänzung
Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. Die Höhe des Grunds würde man dann indirekt bestimmen können, indem man die Turmhöhe abzieht. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Gruß, Tobias ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Am 19. Februar 2012 09:42 schrieb Tobias Knerr o...@tobias-knerr.de: Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. das Wiki schreibt, ele wäre die Höhe an einem bestimmten Punkt. Meine Überlegungen waren nun diese: 1. Angenommen, man flöge mit einem Flugzeug, so wäre man sicher an der absoluten Höhe des höchsten Punktes interessiert. 2. Wenn man nur eine simple Karte rendern will (2D), dann will man meist die Höhe der Turmspitze haben (und dazuschreiben). Für diesen (bisher häufigsten) Fall ist es am einfachsten, wenn man das direkt den Daten entnehmen kann. Für 3D-Geschichten muss man sowieso mehr machen, da muss man erst mal rausfinden, ob das 3D-Geländemodell das man hat, die Höhen von Wäldern und Gebäuden bereits rausgerechnet hat (wird wohl oft gemacht), oder ob man sozusagen Rohdaten hat. In diesem Anwendungsfall wird man sowieso mehr recherchieren und rechnen müssen, da kommts auf ne Berechnung mehr auch nicht mehr an. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. ja, habe ich zuerst auch gedacht, aber solange klar ist, was wie erfasst wird, ist es im Prinzip ja egal ob man nun addiert oder subtrahiert. height würde ich in jedem Fall für die Höhe des Objekts vom Grund bis zur höchsten Stelle sehen (also der netto-Turm). Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Wieso, was spricht dagegen, dass die Höhe immer height ist? Ich nutze das z.B. auch bei Obelisken: height ist die Gesamthöhe des Obelisken plus Sockel und ggf. Aufbauten, während obelisk:height die Höhe des reinen Obelisken ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Date: Sat, 18 Feb 2012 21:29:30 +0100 From: Ronnie Soak chaoschaos0...@googlemail.com Die Messungen (zumindest die, die kostenfrei zu empfangen sind) werden einmal in der Sekunde gemacht. Ich bin mir aber sehr sicher, das sich das Ionosphärenwetter nicht sekündlich derart stark ändert, dass es zu merklichen Schwankungen der GPS Position kommt. Sind die Korrekturdaten einmal empfangen, dürfte das eine ganze weil zur Positionsverbesserung ausreichen. Eine Baulücke reicht also, die Korrekturdaten einmal zu empfangen, und man hat etliche Minuten danach eine spürbare Positionsverbesserung. Gruss, Chaos99 Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Gruß Mibo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Nein. Nur durch praktische Erfahrung. Wenn man der Anzeige sowohl der Genauigkeit als auch des Egnos-Status glauben schenken darf, stören einige Minuten Abschattung der Egnos Satelliten nicht. Ohne Einsicht im den Quellcode kann man das natürlich nicht “nachweisen“. Bei Geräten, die auch Rohdaten herausschreiben können, möglicherweise sogar mit und ohne Korrektur, ließe sich so etwas vielleicht nachrechnen. Gruß, Chaos99 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
On 19.02.2012 12:47, Michael Bojert wrote: From: Ronnie Soakchaoschaos0...@googlemail.com Die Messungen (zumindest die, die kostenfrei zu empfangen sind) werden einmal in der Sekunde gemacht. Ich bin mir aber sehr sicher, das sich das Ionosphärenwetter nicht sekündlich derart stark ändert, dass es zu merklichen Schwankungen der GPS Position kommt. Sind die Korrekturdaten einmal empfangen, dürfte das eine ganze weil zur Positionsverbesserung ausreichen. Eine Baulücke reicht also, die Korrekturdaten einmal zu empfangen, und man hat etliche Minuten danach eine spürbare Positionsverbesserung. Dazu müsste die Software in einem Gerät das auch so auswerten. Lässt sich diese Theorie durch ein Protokoll bestätigen ? Das sollte ja eigentlich im Datenblatt stehen. Jetzt habe ich das Datenblatt mal durchgelesen und bekomme etwas Angst vor SBAS. Ich hatte mich nie zu sehr damit Beschäftigt, da hier Stand, dass die Empfänger selbst entscheiden können ob die Korrekturdaten für die aktuelle Region gültig sind: http://www.kowoma.de/gps/waas_egnos.htm Befindet man sich jedoch auch bei den SBAS deutlich außerhalb des Einzugsgebietes der Korrekturstationen und empfängt beispielsweise in Europa die Korrekturdaten für Nordamerika, so wird der GPS-Empfänger im glücklichsten Fall die Standardionosphärenkorrekturen anwenden, die er gespeichert hat. In diesem Fall wird man keinen Unterschied zwischen aktiviertem und nicht aktiviertem WAAS/EGNOS bemerken. Im unglücklichsten Fall jedoch wird überhaupt keine oder eine falsche Ionosphärenkorrektur angewandt und die Position ist sogar schlechter als mit deaktiviertem WAAS/EGNOS. Wenn die Software des GPS-Empfängers korrekt programmiert ist, sollte dieser Fall jedoch nicht eintreten, da die SBAS-Systeme die Informationen über den Gültigkeitsbereich ihrer Daten in den ausgesendeten Signalen mitliefern. Jetzt lese ich hier: http://www.u-blox.com/images/downloads/Product_Docs/u-blox6_ReceiverDescriptionProtocolSpec_%28GPS.G6-SW-10018%29.pdf Since some WAAS satellites can be received in the western parts of Europe but don't carry correction data for the European continent, the GEOs from all but the EGNOS system should be disallowed, using the PRN Mask. Damit ist der Chip wohl nicht fähig das alleine zu erkennen. Sehr schlecht. Kennt jemand Details dazu wie sich der MT3329 verhält? Der ist ja auch in den neueren Garmins drin. Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Ich kann etwa an der markierten Position Ein- und Aussteigen. Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. Viele Grüße Stephan ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Gerätetest - EGNOS
Am 19.02.2012 13:44, schrieb Stephan Knauss: Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Wie bereits gesagt, wurden WAAS und EGNOS für den Einsatz in der Flugzeugnavigation entwickelt. Wird schon seinen Grund haben, wieso das in den Garmins standardmäßig abgeschaltet ist. Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19.02.2012 14:05, schrieb Stephan Wolff: Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Ich kann etwa an der markierten Position Ein- und Aussteigen. +1 Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. +1 Gruss -- Michael Neumann michael.neum...@uni-dortmund.de ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dakota 20 oder Oregon 450?
Am 16.02.2012 08:01, schrieb Manuel Reimer: Hallo, ich möchte mir ein neues GPS zulegen. Anwendungsfälle: - Loggen für OSM. Spuren möchte ich direkt auf der Karte sehen. - Mitnehmen des aktuellen Kartenstands für den Bereich, in dem ich loggen will - POIs erfassen und schon vor Ort mit kurzem Text benennen - Routing für's Fahrrad und zum Wandern (natürlich mit OSM-Karten) Ich schwanke zwischen dem Dakota 20 und dem Oregon 450. Gibt es irgend einen Punkt der für das teurere Oregon 450 spricht, oder genügt das günstigere Dakota 20 für meine Zwecke? Gruß Manuel Hallo Manuel, Nutzen tue ich für's MTB ein Dakota 20 mit Garmin Fahrradhalterung seit gut einem Jahr. Ohne Silikonhülle hätte ich schon ein neues Oregon - kann leicht raus rutschen und auf die Straße fallen (Halterung aus Kunststoff, Oregon - Metall). Von der Genauigkeit her +- 2 - 20m im Wald. Kurven rechnet das Garmin selbst nach, dauert leider Zeit. Das Oregon hat auch noch ein helleres und größeres Display. Daher verwende ich zum Loggen nur noch meine ublox6 USB-Maus mit Laptop. = 1m 2D, 2m 3D mit EGNOS aktiv (12 Satteliten + 3 EGNOS möglich). Laufen hab ich sie mit 2 Punkte/s, damit auch fürs Auto geeignet. Diese hat noch eine deutlich verbesserte Positionserkennung wie das Vorgängermodell. Verglichen mit der aktuell verfügbaren Aerowestkarte kann ich sogar sehen, auf welcher Spur ich fahre. Gruß Christian signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
Simon Poole si...@poole.ch wrote: Es wurden an beiden Sitzungen einige wichtige Punkte behandelt: - Festlegung auf den WTFE Algorithmus für den Übergang auf die ODbL Datenbank ( - Klarstellung, dass Splits und Mergers nicht berücksichtigt werden. Falls tatsächlich ein an OSM Beteiligter, seine Rechte verletzt sieht, so würde man das am konkreten Fall untersuchen und allfällige nicht konforme Daten löschen. Und hinter der fachchinesischen Abkürzung WTFE verbirgt die Aussage, dass die Lizenzbereinigung so duchgeführt wird, wie im OSM Inspektor, Frederiks JOSM Plugin und der Clear/Badmap dargestellt, oder? Noch in eigener Sache: ich hab vor ein paar Wochen angekündigt, dass in irgendeiner Form ich Zugriff auf die Profildaten der Grössten noch unentschiedenen Mapper haben werde. Ich habe die Daten jetzt und habe auch bereits eine Liste für Deutschland produziert (ca. 220 Einträge). Die Liste wird wohl in den nächsten Tagen abgearbeitet. Nachdem ich in meiner Homeregion Ostfriesland das erste Mal Frederiks Auswertung gesehen hatte, drängte sich mir ernsthaft die Frage auf, ob OSM noch mein Projekt sei. Auf rundweg 5000 Quadratkilometer blieb kaum ein Stein mehr anderen. Rot fast überall, wohin das Auge sah. Ich habe darauf hin alle per Hand ermittelten Unentschiedenen im Gebiet über den OSM Account angeschrieben, obwohl dies laut LWG schon einmal auf Englisch und auf Deutsch geschehen sein soll. Dabei bin ich ohne Vorgeplänkel gleich mit der Tür ins Haus gefallen: __ Überschrift: Deine OpenStreetMap Daten werden am 01. April gelöscht. (Ich habe bewusst nicht die Abkürzung OSM benutzt.) Text: Deine OpenStreetMap Daten werden am 01. April gelöscht. Das ist kein Aprilscherz. Wie sehr die von Dir gemappte Heimat zerstört wird, kannst du hier sehen. Alles was rot ist, wird verschwinden. (Dazu gab es dann einen persönlich zugeschnitten Link auf den OSM Inspektor.) Du kannst das verhindern, indem Du der neuen Lizenz zustimmst. Logge Dich dazu hier ein. Prüfe aber zuvor, ob Dir diese neue Lizenz zusagt. (Es folgten Links ins Wiki und auf Frederiks FOSSGIS Vortrag zur Lizenz.) Sorry für meine Aufdringlichkeit. Wenn Du weitere Fragen hast, stehe ich gern zur Verfügung. Normalerweise sind solche Mails an Unbekannte nicht meine Art. Aber hier heiligte der Zweck die Mittel. Und es hat gewirkt. Obwohl die LWG (mit welchem Text auch immer) nichts bewegen konnte, haben diesmal fast alle reagiert. Ich habe viele Dankesmails und nicht eine einziges Mecker erhalten. Heute ist Ostfriesland nahezu sauber. :-) Ich kann also nur dringendst empfehlen, alle deutschsprachigen unentschlossenen Mapper ähnlich drastisch mit ihrer zerstörten Heimat zu konfrontieren. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
Am 19.02.2012 16:27, schrieb Tirkon: Und hinter der fachchinesischen Abkürzung WTFE verbirgt die Aussage, dass die Lizenzbereinigung so duchgeführt wird, wie im OSM Inspektor, Frederiks JOSM Plugin und der Clear/Badmap dargestellt, oder? Steht ja so im Protokoll. Noch in eigener Sache: ich hab vor ein paar Wochen angekündigt, dass in irgendeiner Form ich Zugriff auf die Profildaten der Grössten noch unentschiedenen Mapper haben werde. Ich habe die Daten jetzt und habe auch bereits eine Liste für Deutschland produziert (ca. 220 Einträge). Die Liste wird wohl in den nächsten Tagen abgearbeitet. Nachdem ich in meiner Homeregion Ostfriesland das erste Mal Frederiks Auswertung gesehen hatte, drängte sich mir ernsthaft die Frage auf, ob OSM noch mein Projekt sei. Auf rundweg 5000 Quadratkilometer blieb kaum ein Stein mehr anderen. Rot fast überall, wohin das Auge sah. Ich habe darauf hin alle per Hand ermittelten Unentschiedenen im Gebiet über den OSM Account angeschrieben, obwohl dies laut LWG schon einmal auf Englisch und auf Deutsch geschehen sein soll. Dabei bin ich ohne Vorgeplänkel gleich mit der Tür ins Haus gefallen: Also 2 Mails sind an jeden geschickt worden, der noch nicht zugestimmt hat. Es hat aber sicher einen gewissen Prozentsatz, der weil im Profile keine Browser-Sprachpräferenz, oder en gesetzt war, die zweite Mail auf Englisch erhalten haben. Daneben sind die Mails vermutlich Spamfilter etc. zum Opfer gefallen. Bezüglich den grössten deutschen Mappern kann ich noch folgendes sagen, es hat einen sehr hohen (ca. 50%) Rate von Bounces (also Mail aus irgendwelchen Gründen nicht zustellbar). EIne Grössenordnung mehr als in anderen Ländern. Das ganze ist also schon recht abgearbeitet, es hat aber wohl noch -viele- kleinere Mapper (mit weniger als 100 erstellten highways nach meinen Listen), die man vermutlich erreichen kann. Simon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Dakota 20 oder Oregon 450?
Christian Kolesa chriskol...@web.de wrote: Daher verwende ich zum Loggen nur noch meine ublox6 USB-Maus diese hier?: http://www.alternate.de/html/product/Navilock/NL-602U_ublox6_USB_Empfaenger/966752/? mit Laptop. Ist die Software zum Loggen bei der Maus dabei oder was bräuchte man da? Gibt es da auch passende offline funktionierende OSM Navi-Programme? = 1m 2D, 2m 3D mit EGNOS aktiv (12 Satteliten + 3 EGNOS möglich). Laufen hab ich sie mit 2 Punkte/s, damit auch fürs Auto geeignet. Auch? Nimmst Du den Laptop auch auf dem Fahrrad mit? In der Beschreibung steht: Durch das Herunterladen der Korrekturdaten aus dem Internet und dem Speichern im GPS-Empfänger, kann dieser weltweit sofort nach dem Empfang des ersten Satellitensignals starten. Sind damit dieselben Korrekturdaten gemeint, die auch über Egnos verbreitet werden? Das Gerät soll auch Galileo-Satelliten sehen können. Hast Du schon mal einen der beiden im Visier gehabt? Verglichen mit der aktuell verfügbaren Aerowestkarte kann ich sogar sehen, auf welcher Spur ich fahre. Das hört sich so an, als wenn man nichts Genaueres mehr bräuchte. :-) Gruß Tirkon ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Talk-de Nachrichtensammlung, Band 67, Eintrag 85
Date: Sun, 19 Feb 2012 13:44:38 +0100 From: Stephan Knauss o...@stephans-server.de Damit ist der Chip wohl nicht fähig das alleine zu erkennen. Sehr schlecht. Kennt jemand Details dazu wie sich der MT3329 verhält? Der ist ja auch in den neueren Garmins drin. Ich wüsste bei mir nicht wie ich einzelne PRN ausschließen kann. Damit bleibt ja dann nur noch das SBAS komplett abzuschalten. Irgendwie auch nicht im Sinne des Erfinders, oder? Stephan Ich lasse WAAS/EGNOS ausgeschaltet da ich den Eindruck habe das es verschlimmbessert. Ohne Protokoll kann ich es aber nicht nachweisen. Ging es in diesem Dialog auch um die Frage: Was ist die Referenz? Als Voraussetzung zum Abzeichnen von Luftbildern hatte ich mal getestet. a) messen von in Luftbildern erkennbaren Punkten mit einer Genauigkeit* im Dezimeter-Bereich [1] Zum Einsatz kam ein Testgerät mit 220 Kanal Empfänger unter Nutzung von 2 Frequenz GPS + Glonass-Signal sowie Egnos und Referenzdaten via GSM-Modem. Als in einem Luftbild mit guter Bodenauflösung erkennbaren Punkt können Laternen oder Masten dienen deren Fuß man durch den Schattenwurf ausmachen kann. b) Vergleich von Luftbildern aus unterschiedlichen Quellen und Trackspuren. Aufgrund der Bodenauflösung sind Bing- Bilder nur bedingt geeignet. Alternativ kann eine Gebäudeecke im Nahbereich zu mehreren solcher Referenzpunkte gemessen werden. c) Festlegen des Versatzes für ein Bing-Luftbild. *Da es verschiedene Definitionen von Genauigkeit gibt, müsste an jeden Referenzpunkt ein Protokoll mit Beschreibung der Lagegenauigkeit gehängt werden. Beispiel: x% von n Messungen pro Punkt liegen in einem Radius von y Metern. Flächendeckend ein gesichertes Referenznetz aufzubauen um eine definierte Lagegenauigkeit von Objekten in OSM zu erreichen halte ich für schwierig . Mir ist auch noch unklar, welche absolute Lagegenauigkeit mit Blick auf die Nutzer einer OSM-Karte erstrebenswert ist. Nach meiner Einschätzung führt die zusätzliche Nutzung von Egnos-Signalen in einem Navi allein, zu keiner relevanten Qualitätsverbesserung der OSM-Daten. Zumindest keine Verbesserung der *Genauigkeit von 10-15m auf 1-2m. Die Nutzung von Referenznetzen wie [2] oder Postprocessing [3] hingegen bringt eine wesentliche Verbesserung wobei auch da bei Abschattungen die bekannten Probleme auftreten. Das ist allerdings i.d.R. kostenpflichtig und fällt eher unter Landes- Vermessung als unter mappen. Wenn z. B. örtliche Vermessungsämter in einem Raster von ein paar hundert Metern WGS 84-Koordinaten von Gebäudeecken bereitstellen würden, könnte ein Schuh draus werden. [1] http://global.trimble.com/de/ oder http://www.leica-geosystems.com/en/index.htm oder [2] http://www.sapos.de/ [3] http://de.wikipedia.org/wiki/Postprocessing Gruß Mibo ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Als Wert für den Schlüssel ele nehme ich stets die Höhe der festen Bodenfläche über NN in Meter, so wie Tobias. So sind z. B. auch die Listen der Sendeanlagen der BNetzA aufgebaut (Standorthöhe). Die Bauwerks- oder Antennenhöhe o. ä. wird addiert. Mit height bezeichne ich dann die Gesamthöhe des Bauwerks oberhalb ele. Soweit ich weiß, sind z. B. die offiziellen Berghöhen ohne die Höhe des Gipfelkreuzes oder -steins angegeben. Bernhard -Original Message- From: Martin Koppenhoefer [mailto:dieterdre...@gmail.com] Sent: Sunday, February 19, 2012 11:54 AM To: Openstreetmap allgemeines in Deutsch Subject: Re: [Talk-de] building:type - Ergänzung Am 19. Februar 2012 09:42 schrieb Tobias Knerr o...@tobias-knerr.de: Am 19.02.2012 00:01, schrieb Martin Koppenhoefer: tut mir leid, ich habe da irgendwie Quatsch geschrieben. ele macht eigentlich mehr Sinn für die höchste Höhe an einem Punkt, oder? Ob es mehr Sinn macht, weiß ich nicht, aber zumindest widerspricht es den Annahmen, von denen ich bisher ausgegangen wäre. das Wiki schreibt, ele wäre die Höhe an einem bestimmten Punkt. Meine Überlegungen waren nun diese: 1. Angenommen, man flöge mit einem Flugzeug, so wäre man sicher an der absoluten Höhe des höchsten Punktes interessiert. 2. Wenn man nur eine simple Karte rendern will (2D), dann will man meist die Höhe der Turmspitze haben (und dazuschreiben). Für diesen (bisher häufigsten) Fall ist es am einfachsten, wenn man das direkt den Daten entnehmen kann. Für 3D-Geschichten muss man sowieso mehr machen, da muss man erst mal rausfinden, ob das 3D-Geländemodell das man hat, die Höhen von Wäldern und Gebäuden bereits rausgerechnet hat (wird wohl oft gemacht), oder ob man sozusagen Rohdaten hat. In diesem Anwendungsfall wird man sowieso mehr recherchieren und rechnen müssen, da kommts auf ne Berechnung mehr auch nicht mehr an. Ich kann das jetzt nur aus der Perspektive von 3D-Rendering beurteilen. Dort wird man naheliegenderweise zunächst mal den Boden berechnen und dann Gebäude und andere Objekte in der passenden Höhe draufsetzen. Da wäre es naheliegend, das auch in den Daten entsprechend zu erfassen. ja, habe ich zuerst auch gedacht, aber solange klar ist, was wie erfasst wird, ist es im Prinzip ja egal ob man nun addiert oder subtrahiert. height würde ich in jedem Fall für die Höhe des Objekts vom Grund bis zur höchsten Stelle sehen (also der netto-Turm). Die Höhe des höchsten Punktes an einer Stelle ist in diesem Anwendungsfall uninteressant. Man würde also nie die in deinem Sinne getaggte ele direkt verwenden, sondern müsste immer die abgeleitete Information Höhe des Grunds errechnen. Das hat auch den Nachteil, dass man zur Berechnung von Grundhöhen das Tagging aller möglichen Objektarten kennen muss, auch wenn sie einen an sich wirklich interessieren - sonst kann man ja nicht ihre jeweils richtige Höhe berechnen und abziehen. Wieso, was spricht dagegen, dass die Höhe immer height ist? Ich nutze das z.B. auch bei Obelisken: height ist die Gesamthöhe des Obelisken plus Sockel und ggf. Aufbauten, während obelisk:height die Höhe des reinen Obelisken ist. Gruß Martin ___ 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] LWG Sitzung vom 14.2.2012
Simon Poole si...@poole.ch wrote: Bezüglich den grössten deutschen Mappern kann ich noch folgendes sagen, es hat einen sehr hohen (ca. 50%) Rate von Bounces (also Mail aus irgendwelchen Gründen nicht zustellbar). EIne Grössenordnung mehr als in anderen Ländern. Ich habe keinen blassen Schimmer, ob Folgendes technisch machbar wäre: Vielleicht sollte man darüber nachdenken, die aktuelle Slippy Map schon jetzt durch die ODBL-Cleanmap zu ersetzen, während die alte noch gültige CC-Version dahinter nur verblasst erscheint. Damit würde sie auf der Hauptseite als auch in den Editoren und Anwendungen, die sie nutzen, dergestalt erscheinen und erregt dort Aufmerksamkeit. Zudem gibt man der alten CC-Map eine neue URL, über die sie erreichbar bleibt. Möglicherweise kann man hierzu den neuen Server aus der Spendenaktion nutzen. Er rendert die aktuelle ODBL-Cleanmap und legt die vom alten Server gerenderte aktuelle CC-Map verblasst dahinter. Mit dem Datum der Umstellung lässt man die verblasste Version weg. Zudem lässt man in den vier Ecken große rote Hinweise - sagen wir in zwei Sprachen pro Ecke, insgesamt also acht - erscheinen, die auf eine Erklärung verlinken. Auf deutsch könnte dieser Hinweis etwa so lauten: Achtung! Verblasste Objekte werden am 2. April gelöscht - der 2. April deshalb, damit es nicht als Aprilscherz interpretiert werden könnte. In den Ecken würden die Hinweise beim Arbeiten nicht so arg stören, so dass man einen Monat damit leben kann. Alternativ lässt man die Hinweise nur für einige Sekunden auftauchen und dann verschwinden und wiederholt das alle fünf Minuten. Der nicht ereichbare Mapper vermisst also seine Edits. Dies lässt ihn aufschrecken und nach den Ursachen forschen. Möglicherweise bekehrt das auch noch den ein oder anderen Ablehner. Alternativ könnte man die Slippy Map - alt vs neu - durch diesen Stil ersetzen: http://sautter.com/map/ Dabei stellt man den Schieberegler in der Start-/Grundeinstellung so ein, dass die Cleanmap betont bleibt. Oder aber man macht das Ganze zum 1. April und lässt noch einen Monat Karenzzeit bis zur endgültigen Umstellung. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] LWG Sitzung vom 14.2.2012
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 IMHO bringt ein Verschiebung des Termins nichts, die Leute die was auf den letzten Drücker tun wollen lässt das kalt und alle anderen kann man locker vorher noch erreichen. Es ist gut möglich (Rebuild-Sitzung in 30 Minuten!), dass wir ab ca. Anfang März anfangen die Datenbank zu bereinigen. Vermutlich wird es aber mindestens bis zum 1. April noch die Möglichkeit geben zuzustimmen und seine Daten wieder sichtbar zu machen. Es ist aber genau so möglich das man anders vorgeht. Simon -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJPQUCwAAoJEEchcRCS4oLqGq0IAI63OJ3qoTvtovpuLkABtJ6b GJAROTqYA2IF5MoYRqvDGW4oBCpcLHhaxduUs6kKaYEQfNGdKMhUSTQD8iKCNSqQ ZQgspqI9dNM4uYOP3ehjmMR6fK0+qhR4Czb9CibepjAO7jcGNk2+hiyE8zWI+Mhg PVspc0bGDNdxdcUcyEqhfXD3nFDEpSqma4980VBI74nfw/6VQ/PYmrEbki8gjbdw e5/+LT+c/lt/SBKUl131IYRFPgcqA0vckb15p2/Pbc815zDkDdt8cvdKoa+sdqre 4ldVOlP+AYOrkH3CCNH0qRR5in3vpt9FScijGENDrlNWzd9Qs/IlQswMNPpHed0= =TAhm -END PGP SIGNATURE- ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Denkmal-Tag
hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Jan Tappenbeck schrieb: ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Darunter könnte man beispielsweise auch einen Wachschutz verstehen. Etwas Eindeutigeres wäre besser. etwas in der Art: Denkmal=ja offiziell_anerkanntes_Denkmal=ja Beim Wikimedia-Commons-Wettbewerb gab es Listen mit offiziell anerkannten Denkmälern. Vielleicht könnte man sie für diesen Zweck heranziehen? Gruß Thomas ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Wochennotiz Nr. 83
Hallo, die neue Wochennotiz Nr. 83 mit allen Neuigkeiten aus der OpenStreetMap-Welt ist da: http://blog.openstreetmap.de/2012/02/wochennotiz-nr-83/ Viel Spaß beim Lesen! ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Deutscher Kartenstil: Probleme mit Sperrgebieten (Übungsplätze, Kasernen, etc.)
Karsten Gohr findich...@gmx.de wrote: Kann man die militärischen Grenzen und Schraffuren in den deutschen Stil übernehmen? Danke, dass Du Dich soeben bereiterklärt hast zukünftig bei der Pflege des deutschen Stils mitzuhelfen *duck* Gruss Sven P.S.: Falls Du ernsthaft Interesse hast mitzuarbeiten. Unter http://lists.openstreetmap.de/mailman/listinfo/mapnik-de gibt es eine Mailingliste. -- Das Internet ist kein rechtsfreier Raum, das Internet ist aber auch kein bürgerrechtsfreier Raum. (Wolfgang Wieland Bündnis 90/Die Grünen) /me is giggls@ircnet, http://sven.gegg.us/ on the Web ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19.02.2012 14:05, schrieb Stephan Wolff: Am 19.02.2012 00:51, schrieb Garry: Am 18.02.2012 08:44, schrieb Michael Neumann: Ich wuerde public_transport=stop_position auf dem Gleis an der Mitte des Bahnsteigs setzen. Welche Information möchtest Du den mit stop_position geben? stop_position vorhanden und Teil einer Relation route=train: Der Zug hält in diesem Bahnhof. Der Zug? Du möchtest einen Fahrplan in OSM abbilden? Ich kann etwa an der markierten Position Ein- und Aussteigen. Dafür genügt die Information wo der Bahnsteig beginnt/endet. Sonst bekomme ich eine Informationsgenauigkeit vorgegaukelt die ich nicht habe. Ich denke es gibt zu viele Ausnahmen, Sonderfälle etc. als dass man das in OSM sinnvoll eintragen könnte. Manche Gleise werden doppelt genutzt (hinterer und vorderer Teil), Züge getrennt und zusammgefügt,... Vernüftig wäre da nur das taggen der entsprechende Haltetafeln (Langzug,Vollzug,Kurzzug, achsabhängig,..) Für welche Anwender bietet diese Detailinformation einen Zusatznutzen? Mir fallen dafür nur Zugsimulatoren ein. Für Fahrgäste ist die Mitte des Zuges die relevante Position. Für den Anwender ist der Bahnsteig relevant und soweit vorhanden die Wagenstandsanzeiger. Mitte des Zuges funktioniert nicht, das hängt von viel zu vielen Parametern ab die sich in OSM nicht abbilden lassen. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 17.02.2012 17:40, schrieb Alexander Matheisen: - oneway: ist oneway=yes sinnvoll, wenn jedes Gleis einer zweigleisigen Strecke nur Signale für eine Fahrtrichtung hat? Ist nicht selbst in diesem Fall z.B: bei Bauarbeiten auf dem anderen Gleis das Befahren des Gegengleises möglich? In der Regel schon. Sinnvoller wäre es den regulären Gleiswechselbetrieb zu taggen, also wenn beide Gleise in beide Richtungen gleichwertige Signaltechnik haben. Garry ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 19.02.2012 20:07, schrieb malenki: Jan Tappenbeck schrieb: ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? protected = yes zum Beispiel ? Darunter könnte man beispielsweise auch einen Wachschutz verstehen. Etwas Eindeutigeres wäre besser. etwas in der Art: Denkmal=ja offiziell_anerkanntes_Denkmal=ja Beim Wikimedia-Commons-Wettbewerb gab es Listen mit offiziell anerkannten Denkmälern. Vielleicht könnte man sie für diesen Zweck heranziehen? Gruß Thomas hi ! sollten tags nicht in englisch gehalten sein ? denkmalschutz gibt es doch in anderen ländern! gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: punkte im Wikiformat ausgeben
HI ! wenn ich mich nicht irre hatte ich vor kurzem eine Funktion gesehen bei welcher Nodekoordinaten in speziellen Formaten ermittelt und in den Zwischenspeicher übernommen werden konnten ?!?! Ich finde diese nicht wieder - kann mir einer weiterhelfen? Gruß Jan :-) ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 19. Februar 2012 19:56 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? es gibt da verschiedene Proposals, z.B.: * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area mit protect_class=22 * http://wiki.openstreetmap.org/wiki/Proposed_features/heritage Wenn Du sicher gehen willst nimmst Du beides... Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Welche Tags für Bahngleise
Am 19. Februar 2012 02:05 schrieb Henning Scholland o...@aighes.de: Der Unterschied liegt in dem Gültigkeitsraum der Default-Werte. Bei globalen Defaults kann man sich die Erfassung des Normalzustandes sparen. Bei lokalen Defaults halte ich es für sinnvoll, diese zu erfassen. Ansonsten kann man immer sagen gauges=... ist für die Straßenbahn in Kleinkleckersdorf default, muss ich also nicht erfassen. Als Auswerter steht man dann aber da und muss irgendwie an den Default für diese Situation herankommen und man muss wissen, in welcher Region die Schiene gerade liegt. Oder anders ausgedrückt, wenn man diese Eigenschaft auswerten möchte, muss man lokales Wissen haben oder aber eine separate, freie DB, die man anzapfen kann. +1, die Spurbreite zu taggen ist sinnvoll, auch wenn innerhalb eines Landes vorwiegend eine bestimmte Spurbreite in Benutzung ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] building:type - Ergänzung
Am 19. Februar 2012 18:44 schrieb Bernhard Weiskopf bweisk...@gmx.de: Als Wert für den Schlüssel ele nehme ich stets die Höhe der festen Bodenfläche über NN in Meter, so wie Tobias. bei einem im Meer schwimmenden Turm hättest Du dann einen negativen Wert in ele? ;-) So sind z. B. auch die Listen der Sendeanlagen der BNetzA aufgebaut (Standorthöhe). Standorthöhe muss ja nicht unbedingt dass sein, was in ele rein kommt, dann müsste man diese Listen halt vor dem Taggen noch umrechnen (ele=height+standorthöhe). ele ist halt die Höhe des Punktes, und wie da dann noch was zusätzlich oben drauf sein kann (wie ein Turm) erschließt sich finde ich nicht. Bei Türmen wird normalerweise angegeben: Höhe über NN und das ist dann die Höhe der Turmspitze, z.B. http://www.schwaebischer-albverein.de/wanderheime/rossberghaus/rossberghaus.html Soweit ich weiß, sind z. B. die offiziellen Berghöhen ohne die Höhe des Gipfelkreuzes oder -steins angegeben. Das ist klar (zumindest für das Gipfelkreuz, den Gipfelstein würde ich der Einfachheit halber lieber erstmal draussen lassen) , aber ein Turm unterscheidet sich da m.E. von einem Berg. Wenn man das Gipfelkreuz taggen würde, dann würde man sicherlich auch für die Höhe die der Spitze verwenden, oder? Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] JOSM: Punkt-Koordianten extrahieren
HI ! ich meine kürzlich einen Dialog gesehen zu haben um von einem Node die Koordinaten in verschiedenen Formaten (z.b. Wikipedia) extrahieren zu können und entsprechend formatiert in den Zwischenspeicher zu bekommen. Den finde ich nicht wieder - kann mir einer auf die Sprünge helfen ? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Denkmal-Tag
Am 20.02.2012 00:37, schrieb Martin Koppenhoefer: Am 19. Februar 2012 19:56 schrieb Jan Tappenbeck o...@tappenbeck.net: hi ! ich habe einiges an historischen Dingen die letzte Zeit erfaßt und weiß das diese teilweise unter Denkmalschutz stehen. Im Wiki habe ich aber nichts passendes gefunden - was würdet Ihr nehmen ?? es gibt da verschiedene Proposals, z.B.: * http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area mit protect_class=22 * http://wiki.openstreetmap.org/wiki/Proposed_features/heritage Wenn Du sicher gehen willst nimmst Du beides... Gruß Martin Um mal ein praktisches Beispiel für heritage zu zeigen: http://www.openstreetmap.org/browse/way/101010765 , mit dem ich nach und nach alle Kölner Denkmäler https://de.wikipedia.org/wiki/Liste_der_Denkm%C3%A4ler_in_K%C3%B6ln markiere Raimond. signature.asc Description: OpenPGP digital signature ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] strade con corsie con diversa superficie
Mi intrufolo nella discussione per chiedervi un info: cobblestone secondo il Wiki sono i blocchetti di pietra tondi e dice anche che dal 1900 in poi sono stati sostituiti da un altro tipo: sett, che credo siano i sampietrini. Sicché nel caso in questione non si dovrebbe usare sett, se sono sanpietrini o cobblestone:flattened se sono pietre appiattite? Ho visto che sett non è molto usato per indicare i bolognini, ma se è la calura corretta, non vedo perché non usarla. Spero possiate chiarire i miei dubbi, perché proprio nei giorni scorsi ho usato surface=sett e non vorrei aver sbagliato. Lo ho usato per un tratto di ciclabile con i sampietrini. Buona domenica a tutti. Matteo Quatrida Inviato dal mio HTC Wildfire tramite Gmail Il giorno 18/feb/2012 16:57, Luca Delucchi lucadel...@gmail.com ha scritto: Il 18 febbraio 2012 16:56, Luca Delucchi lucadel...@gmail.com ha scritto: un idea potrebbe essere usare una cosa del genere surface=cobblestone:paved scusa mi sono accorto che mancava un pezzo surface=cobblestone:paved:cobblestone -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] license change - i casi duri
Se non ricordo male RedFox è Roberto Navoni... Edoardo Il giorno 19 febbraio 2012 02:41, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: Ho scritto la mail e ho ricevuto risposte di errore permanenti (tranne uno che ha la cartella piena) per i seguenti utenti: Giorgio Vaccari 793 (0.06%) bh3u4m 597 (0.05%) delugian11 172 (0.01%) MauPan 144 (0.01%) redfox74 137 (0.01%) drwtsn32 133 (0.01%) chicco 123 (0.01%) qualcuno li connosce di persona? I numeri sono la quantità di highway che si perderebbe. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Edoardo Marascalchi skype: asca_edom ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] license change - i casi duri
On 19.02.12, 01:41, Martin Koppenhoefer wrote: Ho scritto la mail e ho ricevuto risposte di errore permanenti (tranne uno che ha la cartella piena) per i seguenti utenti: Giorgio Vaccari 793 (0.06%) bh3u4m 597 (0.05%) delugian11 172 (0.01%) MauPan 144 (0.01%) redfox74 137 (0.01%) drwtsn32 133 (0.01%) chicco 123 (0.01%) qualcuno li connosce di persona? I numeri sono la quantità di highway che si perderebbe. Delugian11 è mio concittadino e vicino di casa, non credevo non avesse accettato la licenza, lo chiamo subito. Consideratelo sistemato. Real-time bug squashing :) -- Francesco de Virgilio *Ubuntu-it team member* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://www.fradeve.org Love - Peace - Freedom - Free Software signature.asc Description: Digital signature ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade con corsie con diversa superficie
On 19 Feb 2012, at 10:24, Matteo Quatrida matteo.quatr...@gmail.com wrote: Mi intrufolo nella discussione per chiedervi un info: cobblestone secondo il Wiki sono i blocchetti di pietra tondi e dice anche che dal 1900 in poi sono stati sostituiti da un altro tipo: sett, che credo siano i sampietrini. Sicché nel caso in questione non si dovrebbe usare sett, se sono sanpietrini o cobblestone:flattened se sono pietre appiattite? Credo quei ultimi sono paving_stones Riguardo superfici diversi su corsie diverse penso che non c'è modo adeguato per mappare finchè non abbiamo un modello generale per le corsie (c'è una proposta recente, attualmente in discussione). Per il momento metterei il valore della superficie della corsia migliore al way. Ciao, Martin___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Osservatorio astronomico
Ciao a tutti. Ho inserito su Osm un osservatorio astronomico. Ho inserito molte proprietà inerenti all'indirizzo ed alla costruzione. Ho solo questi due piccoli dubbi: building = observatory (devo inserirlo come amenity? ) addr:street = xx qui ho inserito il nome della località (tema già affrontato), in quanto l'indirizzo corrisponde alla località. Va bene comunque questo tag? Grazie. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade con corsie con diversa superficie
Quindi per i sampietrini si usa sett? Matteo Quatrida Inviato dal mio HTC Wildfire tramite Gmail Il giorno 19/feb/2012 13:19, Martin Koppenhoefer dieterdre...@gmail.com ha scritto: On 19 Feb 2012, at 10:24, Matteo Quatrida matteo.quatr...@gmail.com wrote: Mi intrufolo nella discussione per chiedervi un info: cobblestone secondo il Wiki sono i blocchetti di pietra tondi e dice anche che dal 1900 in poi sono stati sostituiti da un altro tipo: sett, che credo siano i sampietrini. Sicché nel caso in questione non si dovrebbe usare sett, se sono sanpietrini o cobblestone:flattened se sono pietre appiattite? Credo quei ultimi sono paving_stones Riguardo superfici diversi su corsie diverse penso che non c'è modo adeguato per mappare finchè non abbiamo un modello generale per le corsie (c'è una proposta recente, attualmente in discussione). Per il momento metterei il valore della superficie della corsia migliore al way. Ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
addr:street=Località X addr:city=Comune Io metterei così. Però non so quanto sia corretto. Matteo Quatrida Inviato dal mio HTC Wildfire tramite Gmail Il giorno 19/feb/2012 15:56, Gianluca Boero gianlucabo...@alice.it ha scritto: Ciao a tutti. Ho inserito su Osm un osservatorio astronomico. Ho inserito molte proprietà inerenti all'indirizzo ed alla costruzione. Ho solo questi due piccoli dubbi: building = observatory (devo inserirlo come amenity? ) addr:street = xx qui ho inserito il nome della località (tema già affrontato), in quanto l'indirizzo corrisponde alla località. Va bene comunque questo tag? Grazie. -- Gianluca Boero __**_ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-ithttp://lists.openstreetmap.org/listinfo/talk-it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
-Original Message- From: Gianluca Boero [mailto:gianlucabo...@alice.it] Sent: domenica 19 febbraio 2012 15:56 To: Talk-it OpenStreetMap Subject: [Talk-it] Osservatorio astronomico Ho inserito su Osm un osservatorio astronomico. Prova a guardare questa proposta [1] addr:street = xx qui ho inserito il nome della località (tema già affrontato), in quanto l'indirizzo corrisponde alla località. Va bene comunque questo tag? Non so cosa si fosse detto quando si è affrontato il problema. Il wiki dice che se usi addr:street, dovrebbe esserci un highway con lo stesso valore nelle vicinanze. Se dai il nome di una località questa condizione non è soddisfatta. Un router che cerca tra le highway non funzionerebbe. Esiste anche addr:hamlet, che forse sarebbe più adatto in questi casi? [1] http://wiki.openstreetmap.org/wiki/Telescope Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
Il 19 febbraio 2012 19:42, Alberto Nogaro bartosom...@yahoo.it ha scritto: Non so cosa si fosse detto quando si è affrontato il problema. Il wiki dice che se usi addr:street, dovrebbe esserci un highway con lo stesso valore nelle vicinanze. Se dai il nome di una località questa condizione non è soddisfatta. Un router che cerca tra le highway non funzionerebbe. di solito anche la strada prende il nome della località (almeno nelle zone che conosco io) Esiste anche addr:hamlet, che forse sarebbe più adatto in questi casi? magari da usare entrambi con i rispettivi nomi Ciao, Alberto -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
Il 19/02/2012 19:42, Alberto Nogaro ha scritto: -Original Message- From: Gianluca Boero [mailto:gianlucabo...@alice.it] Sent: domenica 19 febbraio 2012 15:56 To: Talk-it OpenStreetMap Subject: [Talk-it] Osservatorio astronomico Ho inserito su Osm un osservatorio astronomico. Prova a guardare questa proposta [1] addr:street = xx qui ho inserito il nome della località (tema già affrontato), in quanto l'indirizzo corrisponde alla località. Va bene comunque questo tag? Non so cosa si fosse detto quando si è affrontato il problema. Il wiki dice che se usi addr:street, dovrebbe esserci un highway con lo stesso valore nelle vicinanze. Se dai il nome di una località questa condizione non è soddisfatta. Un router che cerca tra le highway non funzionerebbe. Esiste anche addr:hamlet, che forse sarebbe più adatto in questi casi? [1] http://wiki.openstreetmap.org/wiki/Telescope Ciao, Alberto Appunto...nelle vicinanze non c'è un highway con tale nome in quanto non esiste. L'indirizzo fisico è quello della località. addr:street andrà bene con il nome della località? (località che poi rispecchia solo questo osservatorio e basta). -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
Il 19/02/2012 19:47, Luca Delucchi ha scritto: Il 19 febbraio 2012 19:42, Alberto Nogarobartosom...@yahoo.it ha scritto: Non so cosa si fosse detto quando si è affrontato il problema. Il wiki dice che se usi addr:street, dovrebbe esserci un highway con lo stesso valore nelle vicinanze. Se dai il nome di una località questa condizione non è soddisfatta. Un router che cerca tra le highway non funzionerebbe. di solito anche la strada prende il nome della località (almeno nelle zone che conosco io) Esiste anche addr:hamlet, che forse sarebbe più adatto in questi casi? magari da usare entrambi con i rispettivi nomi Ciao, Alberto io proponderei allora per addr:hamlet e basta. Devo però inserire nelle vicinanze anche un punto con tale località? Credo di si. -- Gianluca Boero ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] license change - i casi duri
Roberto (RedFox74) Accetta la nuova CT, gli devo mandare il link... Edo Il giorno 19 febbraio 2012 11:48, Francesco de Virgilio fradev...@gmail.com ha scritto: On 19.02.12, 01:41, Martin Koppenhoefer wrote: Ho scritto la mail e ho ricevuto risposte di errore permanenti (tranne uno che ha la cartella piena) per i seguenti utenti: Giorgio Vaccari 793 (0.06%) bh3u4m 597 (0.05%) delugian11 172 (0.01%) MauPan 144 (0.01%) redfox74 137 (0.01%) drwtsn32 133 (0.01%) chicco 123 (0.01%) qualcuno li connosce di persona? I numeri sono la quantità di highway che si perderebbe. Delugian11 è mio concittadino e vicino di casa, non credevo non avesse accettato la licenza, lo chiamo subito. Consideratelo sistemato. Real-time bug squashing :) -- Francesco de Virgilio *Ubuntu-it team member* mailto:frad...@ubuntu-it.org http://wiki.ubuntu-it.org/FrancescoDeVirgilio *Wikimedia projects contributor* http://en.wikipedia.org/wiki/User:Fradeve11 *OpenStreetMap Mapper* http://www.openstreetmap.org/user/Fradeve11 *Blog* http://www.fradeve.org Love - Peace - Freedom - Free Software ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it -- Edoardo Marascalchi skype: asca_edom ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnavia: delucidazioni
Riprendo questa mail Il 12 agosto 2011 19:51, ale_z...@libero.it ale_z...@libero.it ha scritto: Ciao Recentemente mi sto trovando a mappare parecchi segnavia [1] ma son dubbioso sul corretto tagging da applicare nel caso lo stesso segnavia contenga più indicazioni (quindi name=* e magari ref=* diversi tra di loro) , esattamente come mostrato nelle immagini sul wiki. Come vi comportate in questi casi? Ciao e grazie Alessio [1] http://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost ___ Io per il momento aggiungo il tag description con tutte le indicazioni dei cartelli (nei limiti dei 255 caratteri). puoi mandare un esempio? che separatore usi? io pensavo ad una cosa del genere localita:tempo;localita;localita:tempo che ne dite? Alessandro Ale_Zena_IT -- ciao Luca http://gis.cri.fmach.it/delucchi/ www.lucadelu.org ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] license change - i casi duri
Am 19. Februar 2012 20:24 schrieb Edoardo Marascalchi edoa...@edoardomarascalchi.it: Roberto (RedFox74) Accetta la nuova CT, gli devo mandare il link... Ottimo. Cito la lettera: Se lo desideri, puoi quindi accettare la nuova licenza entrando nel tuo profilo OSM oppure qui: http://openstreetmap.org/user/terms ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] license change - i casi positivi
donatella, il numero uno della mia lista dei mappatori Italiani indecisi, ha accettata 3 ore fa! ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] license change - i casi positivi
Anche rcim, mekkor e siorarina hanno accetati. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnavia: delucidazioni
Am 19. Februar 2012 20:45 schrieb Luca Delucchi lucadel...@gmail.com: Riprendo questa mail Il 12 agosto 2011 19:51, ale_z...@libero.it ale_z...@libero.it ha scritto: Ciao Recentemente mi sto trovando a mappare parecchi segnavia [1] ma son dubbioso sul corretto tagging da applicare nel caso lo stesso segnavia contenga più indicazioni (quindi name=* e magari ref=* diversi tra di loro) , esattamente come mostrato nelle immagini sul wiki. Come vi comportate in questi casi? Ciao e grazie Alessio [1] http://wiki.openstreetmap.org/wiki/Tag:information%3Dguidepost ___ Io per il momento aggiungo il tag description con tutte le indicazioni dei cartelli (nei limiti dei 255 caratteri). puoi mandare un esempio? che separatore usi? io pensavo ad una cosa del genere localita:tempo;localita;localita:tempo che ne dite? Dico che non è una bella descrizione ;-), è una descrizione formale, nel tag description mi aspetto qualcosa che posso leggere e capire (tipo: Segnavia in legno con scritta incisa bianca, indica...). Userei un' altra chiave invece di description. Anche il colon non mi piace nel valore, di solito lo usiamo per creare una gerarchia. La proposta per le corsie usa questo: | e credo che si potrebbe adattare anche qui. ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Osservatorio astronomico
Am 19. Februar 2012 15:56 schrieb Gianluca Boero gianlucabo...@alice.it: Ho inserito su Osm un osservatorio astronomico. Ho inserito molte proprietà inerenti all'indirizzo ed alla costruzione. Ho solo questi due piccoli dubbi: building = observatory (devo inserirlo come amenity? ) va bene building e in più mettrei man_made (o amenity, ma credo starebbe meglio in man_made) addr:street = xx qui ho inserito il nome della località (tema già affrontato), in quanto l'indirizzo corrisponde alla località. Va bene comunque questo tag? se non si tratta di una strada è meglio usare un altro tag (per esempio addr:full). ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade con corsie con diversa superficie
Am 19. Februar 2012 19:36 schrieb Matteo Quatrida matteo.quatr...@gmail.com: Quindi per i sampietrini si usa sett? sarebbe strano, perchè ce ne sono solo 177 in tutto il mondo, mentre con cobblestone ci sono 86213: http://taginfo.openstreetmap.org/search?q=surface%3Dcobblestone ciao, Martin ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Segnavia: delucidazioni
In data lunedì 20 febbraio 2012 01:24:29, Martin Koppenhoefer ha scritto: Am 19. Februar 2012 20:45 schrieb Luca Delucchi lucadel...@gmail.com: Riprendo questa mail Il 12 agosto 2011 19:51, ale_z...@libero.it ale_z...@libero.it ha scritto: Io per il momento aggiungo il tag description con tutte le indicazioni dei cartelli (nei limiti dei 255 caratteri). puoi mandare un esempio? che separatore usi? io pensavo ad una cosa del genere localita:tempo;localita;localita:tempo che ne dite? Dico che non è una bella descrizione ;-), è una descrizione formale, nel tag description mi aspetto qualcosa che posso leggere e capire (tipo: Segnavia in legno con scritta incisa bianca, indica...). Userei un' altra chiave invece di description. Anche il colon non mi piace nel valore, di solito lo usiamo per creare una gerarchia. La proposta per le corsie usa questo: | e credo che si potrebbe adattare anche qui. a me piace molto la soluzione di questa relation: http://wiki.openstreetmap.org/wiki/Relation:destination_sign type, destination, distance, time, colours e usare i membri come si fa con gli obblighi di svolta mi pare ottimo per indicare a quale way è riferito. Alessio Zanol ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] strade con corsie con diversa superficie
Il 02/20/2012 01:30 AM, Martin Koppenhoefer scrisse: Am 19. Februar 2012 19:36 schrieb Matteo Quatrida matteo.quatr...@gmail.com: Quindi per i sampietrini si usa sett? sarebbe strano, perchè ce ne sono solo 177 in tutto il mondo, mentre con cobblestone ci sono 86213: http://taginfo.openstreetmap.org/search?q=surface%3Dcobblestone Sara' anche strano, ma se qualcuno decide di chiamare mela un tavolo e' ancora piu' strano. ;-) ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-co] globo helio fotografia
Hola 2012/2/19 hyan...@gmail.com hyan...@gmail.com: A mayor altura menor presión atmosférica, por lo tanto el experimento puede irse con tres globos inflados a 1/2 - 3/4 capacidad. Realmente en los experiemntos que se han realizado y apesar de los calculos teóricos, hemos necesitado un minimo de 6 globos para realizar el ejercicio satisfactoriamente, pues no es solo el calculo de empuje (para vencer la gravedad) sino también se necesita vencer el empuje horizontal de los vientos, es decir a mayor viento lateral mas empuje se requiere. salu2 No se ha encontrado proveedor de globos climáticos en Colombia, si lo localizas por favor compártelo a la lista. El 19 de febrero de 2012 09:58, Cristian Paul Peñaranda Rojas p...@kristianpaul.org escribió: Ah, pero estos globos no son para aplicaciones relacionadas con el clima..? Claro si tiene la misma dureza y confiabilidad para el re-uso sera suficiente. Particularmente no reutilizo los globos Yo tenia algo como esto en mente pero compraloe en colombia http://randomaerospace.com/Random_Aerospace/Balloons.html Gracias por tu respuesta, saludos ! Si consigues globos climáticos avisanos. salu2 freed ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- Por favor, no me envíe documentos con extensiones .doc, .docx, .xls, .xlsx, .ppt, .pptx, .mdb, mdbx OpenOffice es libre: se puede copiar, modificar y redistribuir libremente. Gratis y totalmente legal. http://GaleNUx.com es el sistema de información para la salud --///-- Teléfono USA: (347) 688-4473 (Google voice) skype: llamarafredyrivera ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
[Talk-co] Nuevas imágenes Bing
Señores: Acabo de descubrir con el Bing Analizer que se liberaron nuevas imágenes para calcar!! Las imágenes están llenando los espacios entre las existentes previamente y trato de confirmar si obedecen a las Áreas de Interés (AOI) que hemos definido. http://wiki.openstreetmap.org/wiki/2011_Colombia_floods#Working_areas_.26_Imagery_request Anímense a explorar! http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=10.040059841670598lon=-74.56057045664777zoom=9 Saludos, Humberto Yances PD: Otra noticia, Leaflet ha sido liberada http://leaflet.cloudmade.com/ ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Nuevas imágenes Bing
Pues duitama sigue sin cubrimiento :( Me alcance a ilusionar. El día 19 de febrero de 2012 21:04, hyan...@gmail.com hyan...@gmail.com escribió: Señores: Acabo de descubrir con el Bing Analizer que se liberaron nuevas imágenes para calcar!! Las imágenes están llenando los espacios entre las existentes previamente y trato de confirmar si obedecen a las Áreas de Interés (AOI) que hemos definido. http://wiki.openstreetmap.org/wiki/2011_Colombia_floods#Working_areas_.26_Imagery_request Anímense a explorar! http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=10.040059841670598lon=-74.56057045664777zoom=9 Saludos, Humberto Yances PD: Otra noticia, Leaflet ha sido liberada http://leaflet.cloudmade.com/ ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- ___ Leonardo Gutierrez ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-co] Nuevas imágenes Bing
Explora si existen en el Orbview3 de http://earthexplorer.usgs.gov/ El 19 de febrero de 2012 21:16, Leonardo Gutierrez l...@autobusesaga.comescribió: Pues duitama sigue sin cubrimiento :( Me alcance a ilusionar. El día 19 de febrero de 2012 21:04, hyan...@gmail.com hyan...@gmail.com escribió: Señores: Acabo de descubrir con el Bing Analizer que se liberaron nuevas imágenes para calcar!! Las imágenes están llenando los espacios entre las existentes previamente y trato de confirmar si obedecen a las Áreas de Interés (AOI) que hemos definido. http://wiki.openstreetmap.org/wiki/2011_Colombia_floods#Working_areas_.26_Imagery_request Anímense a explorar! http://ant.dev.openstreetmap.org/bingimageanalyzer/?lat=10.040059841670598lon=-74.56057045664777zoom=9 Saludos, Humberto Yances PD: Otra noticia, Leaflet ha sido liberada http://leaflet.cloudmade.com/ ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co -- ___ Leonardo Gutierrez ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co ___ Talk-co mailing list Talk-co@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-co
Re: [Talk-dk] Kommune/regionsgrænser ved kysten
Den 11-02-2012 22:52, Jonas Häggqvist skrev: Det eneste der kan ske/sker automatisk er at punkter som er blevet slettet vil blive oprettet igen. Jeg har umiddelbart svært ved at se dette som værende særligt problematisk. Den eneste ulempe er at vi ikke kan påvirke statistikken over dækningsgrad ved at fjerne uønskede adressepunkter. Men statistikken er jo ikke et mål i sig selv. At vi ender op med et par adresser som ikke (evt. endnu) modsvarer noget vi kan finde i virkeligheden (planlagte adresser, administrative adresser osv.) er da ikke 100% perfekt, men på den anden side heller ikke noget større problem som jeg umiddelbart synes det lyder som om det bliver gjort til. Jeg håber jeg misforstår det skrevne. Det er for mig helt og aldeles uacceptabelt at eller andet script automatisk genopretter adresse noder som jeg manuelt har slettet fordi jeg har konstateret på stedet at adressen er fjernet. Jeg sletter ikke noder for at påvirke statistikken, men for at afspejle virkeligheden. Hvis der er nogen der mener det er rimeligt at behandle mine opdateringer på denne måde vil jeg behandle deres redigeringer med samme niveau af respekt. Carsten ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
Re: [Talk-dk] Hen over pladser
Jeg er principielt enig i at rutning bør kunne foregå via arealer, men synes egentlig at det er interessant lige at sammenligne med strategien for floder http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driver her har man faktisk en streg der beskriver flodens retning inde imellem riverbanks der definerer arealet. Carsten Den 13-02-2012 11:48, Emil Tin skrev: ja det er fjollet. men hvis pladsen ikke har nogen faste stier, er den rigtige løsning at ruteberegneren tager sig sammen J Med venlig hilsen *Emil Tin *IT- og Processpecialist Cykelsekretariatet KØBENHAVNS KOMMUNE Teknik- og Miljøforvaltningen Center for Trafik Islands Brygge 37 Vær. 118 Postboks 450 2300 København S Telefon +45 3366 3433 Mobil +45 2972 3788 Email z...@tmf.kk.dk mailto:z...@tmf.kk.dk *Fra:*Sonny Andersen [mailto:s...@bukhmark.dk] *Sendt:* 13. februar 2012 11:46 *Til:* 'OpenStreetMap Denmark' *Emne:* [Talk-dk] Hen over pladser Prøv at se dette eksempel med Nordøvandreruten/Drivvejen i Ribe. http://hiking.lonvia.de/?zoom=18lat=55.32997lon=8.76687 http://hiking.lonvia.de/?zoom=18lat=55.32997lon=8.76687 Fodgængere kan nok finde vej, men kønt er det altså ikke, så jeg er mest fristet til at tegne den sti !! /sba-dk ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk Ingen virus fundet i denne meddelelse. Kontrolleret af AVG - www.avg.com http://www.avg.com Version: 2012.0.1913 / Virusdatabase: 2112/4817 - Udgivelsesdato: 18-02-2012 ___ Talk-dk mailing list Talk-dk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-dk
[Talk-ec] Imagery offset
Hola chicos, tengo un problema con la ubicación de los imágenes de BING. Como se ve en esta parte de mi pantalla de JOSM [http://bodega.towiski.de/josm-floreana.png] todos los elementos del mapa corresponden muy bien con las imágenes aéreas, pero no con mi track del GPS. Hay un montón den fotos al lado izquierdo que debería aparecer en la casita al lado sur de la playa. La ubicación correcta de las tres en la esquina derecha superior también es una cuadra al sur, en la línea verde donde hay una otra foto. Ya pensé que fuera un problema de mi GPS pero en los pocos casos en que lo he comparado con mapas existentes siempre ha sido bastante exacto. Parece que eso es nada extraordinario: https://wiki.openstreetmap.org/wiki/Yahoo!_Aerial_Imagery/Accuracy Pero que exactamente hago en este caso que ya existen bastante datos en el mapa y casi nadie anotó la fuente de sus diseños? Puedo bajar la isla entera, seleccionar todo y moverlo los ~120m, pero no hay como saber los limites de los imágenes malos (en Sta. Cruz y Isabela por ejemplo me parecen perfectos) y el limite puede ser en el medio del mapa. Y hay como avisar los otros editores de mi cambio? Eso no entiendo muy bien: https://wiki.openstreetmap.org/wiki/True_Offset_Process pero suena como quizás podríamos en el futuro ... saludos, Matthias signature.asc Description: Digital signature ___ Talk-ec mailing list Talk-ec@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ec
Re: [Talk-es] Herramienta de fusión de los datos actuales con el catastro
en general veo que el catastro tiene sus cosas y requiere trabajo manual gracias por mirarlo si no tienen solución por lo menos queda como cosas en las que fijarse antes de subir a osm El 17/02/2012, a las 12:22, Ander Pijoan escribió: @sergiosevillano.mail en gmail.com VP__all; VP_0001_cauceNoEsFarm_EsNada; polígonos estrechos muy largos suelen ser cauces o caminos, no subir, dejar hueco VP_0002_CaminoNoEsFarm_EsNada; polígonos estrechos muy largos suelen ser cauces o caminos, no subir, dejar hueco Entendemos que lo que comentas es que no se suba el polígono que representa el hueco entre parcelas delimitadas por un río o carretera. Es complicado ya tendríamos que mirar como hacer que el programa entienda cuando es un polígono de esos porque no llevan ningún tag especial. VP_0003_streamNoEsLimite; a veces los arroyos (stream o river) no dividen las parcelas si a ambos lados son la misma En catastro se representan así, no cortan una parcela. No se muy bien como querrías representarlo de otra manera. mi sugerencia es que si realmente el río está en la parcela y ésta no se divide en dos, la línea del río no debe incluirse como un miembro de la relación de la parcela. VP_0004_streamDireccionesERR; el sentido del río (que debe coincidir con el de la vía) no es congruente se divide en dos y uno de ellos acaba, luego éste tiene sentido erróneo. No nos habíamos dado cuenta de que en OSM los ríos se indicase en su sentido. Esto en catastro seguramente no esté contemplado por lo que habría que invertir la vía desde JOSM. VP_0005_farmNoEsScree; el tag scree se refiere a pedregal de alta montaña (Canchal) creo que viene de improductivo en el catastro no tiene traducción para osm, dejar vacío En la imagen pone scrub. De todas formas scree se ha descartado hace un tiempo. ups, fallo mío VP_0006_huertoNoEsScrub; scrub es matorral, pero esto no lo es parece huerto (no sé en osm, quizás también farm) Esto tiene pinta de ser datos incorrectos en el catastro porque ese scrub viene de que lo han catalogado como suelo improductivo. VP_0007_FarmEsIgualAFarmland; en la wiki landuse=farm es lo mismo que landuse=farmland deberíamos elegir uno, parece preferible landuse=farm (tierras de cultivo) no confundir con landuse=farmyard que es donde están las construcciones de granja apero almacenes ... VP_0008_NoScreeNoFarmSiFarmyard; ver VP_0007 VP_0009_NoFarmSiFarmyardFaltaBuilding; VP_0012_NoFarmSiFarmyard; edificio de granja esta siempre en landuse=farmyard y no en landuse=farm, ver VP_0007 En catastro no hay una categoría para granja o edificios de granja. El decirle al programa que toda construcción que encuentre sobre un landuse=farm lo convierta a farmyard puede ser peor porque pueden ser viviendas, silos, etc. etc. VP_0010_SiScrub; el matorral está en parcela residencial VP_0011_NoScrub; un edificio no puede ser natural=scrub Esto seguramente sea porque pertenecen a los datos rústicos del catastro. A estos datos por ser rústicos hay que añadirles un tipo de cultivo de la parcela y tendrá como cultivo asociado improductivo. Lo único que se podría hacer es introducir bloqueos. En este caso ¿cuales serían los bloqueos? ¿landuse=residencial no puede tener tipo de cultivo que en este caso se traduce en natural=scrub? parece que terreno improductivo es lo que más errores genera . quizás eliminaría todo terreno improductivo de la importación. ésta definición es negativa, y no sé si hay tag para terreno improductivo en general, aunque sí hay para cosas que son improductivas: de hecho todos los landuse excepto los de cultivo (que son farm, orchard, vineyard, grass, forest), son improductivos. http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29 lo que es cierto es que no todo lo improductivo es scrub por ejemplo a todo el casco urbano se le aplica scrub !? VP_0013_SegmentoPerdidoOverRio; el rio se usa como línea que divide cultivos y miembro de relaciones, pero en este segmento tenemos 2 vías superpuestas una con las relaciones y otra con el río solo. Esto es una chapuza de los que hayan hecho la importación, cada pueblo tiene sus sorpresas. VP_0014_SinTagsRelevantes; vías y relaciones sin ningún tag que lo identifique como algo de osm, solo tiene refs del catastro y source.. Esto significa que esa casa no tiene ningún registro en el catastro. Solo tenemos su geometría en los shapefiles y no hay datos extra del archivo .cat. VP_0015_NoWater; natural=water es tag de vías cerradas o o tag de relaciones multipoligono, nunca un segmento suelto puede tener tag de área. ademas el propio tag no es correcto la relacion superior ya dice que es piscina luego no es natural=water. (porque los segmentos no están unidos en una sola vía cerrada?) Esto esta explicado en la wiki, las piscinas, pozos, etc tienen las geometrías partidas de origen (de formas muy
Re: [Talk-es] Herramienta de fusión de los datos actuales con el catastro
Curioso lo de la presa. Si tiene los tags de building-levels es que lo han incluido en catastro como construcción y tendrá el atributo CONSTRU indicando que tiene 1050 alturas. No tengo ni idea en qué se habrán basado para decidir que tiene esa altura. Otra de las muchas curiosidades que irán apareciendo en catastro. mi sugerencia es que si realmente el río está en la parcela y ésta no se divide en dos, la línea del río no debe incluirse como un miembro de la relación de la parcela. Tendría que mirar exactamente si esto para la mayoría de los municipios es algo que está haciendo cat2osm el partir esa pequeña parcela en dos por haber un río en medio o de verdad viene así también en catastro. En caso de que sea la primera, una solución rápida puede ser crear primero un resultado sin los archivos ELEMLIN que son los que contienen ríos y elementos lineales, luego generar uno solo con estos elementos y al final juntarlos. ups, fallo mío parece que terreno improductivo es lo que más errores genera . quizás eliminaría todo terreno improductivo de la importación. ésta definición es negativa, y no sé si hay tag para terreno improductivo en general, aunque sí hay para cosas que son improductivas: de hecho todos los landuse excepto los de cultivo (que son farm, orchard, vineyard, grass, forest), son improductivos. http://wiki.openstreetmap.org/wiki/ES:Map_Features#Uso_del_suelo_.28Landuse.29 lo que es cierto es que no todo lo improductivo es scrub por ejemplo a todo el casco urbano se le aplica scrub !? El problema es que en cada población siempre hay alguna cosa distinta que es la que da problemas. En cada pueblo han importado de una forma distinta y han tenido sus vicios con X tag o han hecho las cosas de cierta manera distinto a lo que se indica en catastro. Cierto es que cualquier traducción mejor para los datos es muy bienvenida y sigue haciendo falta adecuar los tags de la mejor forma. VP_0013_SegmentoPerdidoOverRio; el rio se usa como línea que divide cultivos y miembro de relaciones, pero en este segmento tenemos 2 vías superpuestas una con las relaciones y otra con el río solo. Esto es una chapuza de los que hayan hecho la importación, cada pueblo tiene sus sorpresas. VP_0014_SinTagsRelevantes; vías y relaciones sin ningún tag que lo identifique como algo de osm, solo tiene refs del catastro y source.. Esto significa que esa casa no tiene ningún registro en el catastro. Solo tenemos su geometría en los shapefiles y no hay datos extra del archivo .cat. VP_0015_NoWater; natural=water es tag de vías cerradas o o tag de relaciones multipoligono, nunca un segmento suelto puede tener tag de área. ademas el propio tag no es correcto la relacion superior ya dice que es piscina luego no es natural=water. (porque los segmentos no están unidos en una sola vía cerrada?) Esto esta explicado en la wiki, las piscinas, pozos, etc tienen las geometrías partidas de origen (de formas muy entretenidas). de acuerdo, pero nunca son natural=water. en osm (que básicamente es lago natural) tenemos piscina, deposito, estanque, fuente...(todo artificial) alguno parece registro de aguas que no sé que sería en osm.. puede que la solución sea saber el error y simplemente chequear todos ellos a mano uno a uno. Bien, me parece correcto, ¿entonces cual sería el tag apropiado? En un principio catastro no diferencia de agua artificial y natural, pero si que parece que salen mas artificiales que naturales. donde está documentado landuse=health ? sí he encontrado que la relación tenga un type=health http://wiki.openstreetmap.org/wiki/Proposed_features/Healthcare_2.0#Usage_of_the_health-relation Es lo que nos recomendaron en la página http://wiki.openstreetmap.org/wiki/Traduccion_metadatos_catastro_a_map_features. Aunque si que nos planteamos el cambiarlo a amenity=hospital. La que creáis que es la mejor opción. VP_0016_Scrubdentrodeedificio; un multipolígono edificio contiene (dentro no a modo de patio) otro mas pequeño que es matorral (scrub), no puede ser, parece que quería ser edificio con patio jardín y el edificio estrecho es mas bien barier=wall que sería lineal .esto último es mejor a mano Esto es tema de las geometrías interesantes de catastro. Poco se puede hacer. Saludos. -- Ander Pijoan Lamas ademas de lo anterior en el mismo archivo osm de Villanueva de Perales esta lo que comenté de que el contorno urbano está marcado como scrub Esto creo que no hay forma de solucionarlo. En los archivos rústicos de parcelas crean una parcela que abarca toda la urbana y le dan un tag que crean conveniente. Por ejemplo en el caso de Aldeaseca de Alba la zona urbana está sobre una parcela rústica de tierras de cultivo o en Ciudad Real también toda la ciudad está sobre una parcela de scrub. A lo mejor se podría poner un tag landuse=none que veo en TagInfo que suele usarse. VP_0017_CemeteryNoIndustrial; un cementerio es landuse=industrial?
Re: [Talk-at] Orf.at mal wieder
On 19.02.2012 19:06, Felix Hartmann wrote: Grad beim lesen von orf.at bin ich doch tatsächlich auf einen screenshot aus meiner openmtbmap gestoßen. Ohne copyrights. An wen meldet man sich denn da zwecks korrektur? Siehe http://salzburg.orf.at/news/stories/2521707/ onl...@orf.at (aus dem Impressum). Wenn da nichts kommt, kann mans immer noch mit dem Kundendienst probieren. Dort bearbeitet zumindest jemand die Mails manuell. LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-ro] Diverse aplicații pentru starea drumurilor (a fost: Maparea zonelor Sinistrate,)
În data de 19 februarie 2012, 10:22, George Soghior george.sogh...@gmail.com a scris: Salut! Ati verificat www.trafficguide.ro? Se pare ca preia datele de la CNADNR si le pun destul de elegant (zic eu) pe o harta OSM. Nu stiu insa de unde fac rost de vitezele medii de deplasare pe anumite tronsoane in Bucuresti. Sa fie de la senzorii din asfalt, sau niste estimate de la Politia Rutiera? Eu unul l-am descoperit cu ocazia marelui viscol și mi s-a părut actualizat un pic mai încet decât harta de la hotnews ( http://www.arcgis.com/home/webmap/viewer.html?webmap=5995751b63a245d397d679c4a8361ebc ) Tot legat de starea drumurilor, hotnews mai are câteva hărți despre care nu mi-e clar cât de des sunt actualizate: http://www.arcgis.com/home/search.html?q=owner:HotNews.ro . Aveau la un moment dat chiar o legătură de pe prima pagină și oamenii mai raportau evenimente. Mai avem apoi harta lui Ciprian, shameless hintpe care eu încă aștept să o porteze pe pagina principală openmap.ro sau măcar să pot să-mi suprapun traseul pe starea drumurilor cumva/shameless hint Concluzia ar fi că OSM își îndeplinește cu brio menirea de bază pentru diverse aplicații. Dar eu ca utilizator nu pot decât să deplâng faptul că toate datele astea sunt așa de fragmentate încât trebuie să mă uit în vreo 3 locuri pentru toate informațiile de care am nevoie în pregătirea unui drum (și ca să le downloadez pe GPS trebuie să mă uite pe alt site). Strainu ___ Talk-ro mailing list Talk-ro@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ro
Re: [Talk-lv] Jaunas Bing bildes sarkandaugavas rajona
Vecmilgrāvis jau tika kārtīgi pilnveidots pa brivdienām. Ja kādam nav slinkums, būtu pateicīgs par pārbaudi, jo neesmu pārliecināts kā mans stils ir pietiekami labs. Jautājumus izraisa: - bērnudārzi, jo Mapnik slānī izskatās kā parastās mājas - veikali vienkarši netiek atspoguļoti Mapnik slānī Vadims 2012/2/12 Marat mar...@gmail.com FYI http://shtosm.ru/2012/02/07/1/ http://mvexel.dev.openstreetmap.org/bing/ 2012/2/12 Viesturs Zarins viest...@gmail.com: Izskatās ka updeits ir visai Rīgai! Ir (pusbūvēts) slāvu aplis, Azūrs, zemgaļa gatves pārvads, Bet vislabākais: VAIRS NAV NOBĪDES! (nu vismaz tā kļuvusi 1 m robežās) Ikšķilei arī ir parādījušās ciešamas Bing bildes bet tur nobīde pret LĢIA ir 5 m. Ogres gan nav :/ Yey, jāiet dzert :) Viesturs 2012/2/12 Viesturs Zarins viest...@gmail.com: Tai skaitā arēna Rīga un Skanstes virsotnes... 2012/2/12 Viesturs Zarins viest...@gmail.com: Sveiciens! Tikko pamanīju ka pie Traumatoloģijas slimnīcas ir parādījušās jaunākas Bing bildes (2010 gada, ja var ticēt Microsoft). Tas nozīmē ka var nokartēt tur jauni sabūvētās ēkas ;) Viesturs ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-lv] Jaunas Bing bildes sarkandaugavas rajona
On 02/20/12 01:14, vtv wrote: Vecmilgrāvis jau tika kārtīgi pilnveidots pa brivdienām. Ja kādam nav slinkums, būtu pateicīgs par pārbaudi, jo neesmu pārliecināts kā mans stils ir pietiekami labs. Jautājumus izraisa: - bērnudārzi, jo Mapnik slānī izskatās kā parastās mājas - veikali vienkarši netiek atspoguļoti Mapnik slānī ja lietoji pusliidz populaarus tagus, tad jau viss buus ok - mapnik nav vieniigais un pareizas rendereris (un jamaa osm.org stylesheet). veikali - ja vien neiestaajas collision detection, daljai veikalu buutu gan jaaparaadaas (convenience, supermarket, florist un daudzi citi) - varbuut vari iedot linku uz konkreetu veikalu, kursh neparaadaas ? (tev nav gluzhi vienkaarshi vecas bildes ieksh browsera cache, vai ne ? :) ) Vadims ... -- Rich ___ Talk-lv mailing list Talk-lv@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-lv
Re: [Talk-cz] Import chráněných území z EEA
Ahoj, koukal jsem na současný stav a tagování... tady je pár mých postřehů. V OSM jsou chráněná území momentálně tagována převážně třemi způsoby leisure=nature_reserve, boundary=national_park a potom novější obecnější způsob boundary=protected_area (bohužel oficiální mapnik zatím nekreslí). Navrhoval bych se přidržet systému boundary=protected_area [1] s použitím dalších tagů: - protection_title - celými slovy NP, CHKO, NPR, PR, NPP, PP; toto označení by pak už nemělo být v tagu name (s výjimkou NP?) - protect_class - ref - iucn_level - valid_from - pro rok vytvoření Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik renderovat) boundary=national_park. Ještě pár dalších věcí k NP: Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba na Šumavě ochranné pásmo je CHKO. Současný stav zmapování NP: * KRNAP Relace obsahovala mix cest hranic bez/s ochranného pásma; prozatím jsem relaci upravil tak, aby to aspoň byl platný polygon - ponechal jsem kompletnější hranice včtně ochranného pásma. Je potřeba upřesnit hranice ochranného pásma především okolo Vrchlabí, Některé cesty pro hranici vnitřních zón v databázi jsou, ale není jich moc. * Podyjí V OSM je dvakrát: - Nová relace (hranice včetně ochranného pásma). - Rozdělaný polygon (hranice bez ochranného pásma), kde chybí díra na Čížov, který je jen v ochranném pásmu. * Šumava, České Švýcarsko Vypadají celkem kompletně. Zdraví, Petr Morávek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
Ahoj Ahoj, koukal jsem na současný stav a tagování... tady je pár mých postřehů. V OSM jsou chráněná území momentálně tagována převážně třemi způsoby leisure=nature_reserve, boundary=national_park a potom novější obecnější způsob boundary=protected_area (bohužel oficiální mapnik zatím nekreslí). Navrhoval bych se přidržet systému boundary=protected_area [1] s použitím dalších tagů: Jsem pro - protection_title - celými slovy NP, CHKO, NPR, PR, NPP, PP; toto označení by pak už nemělo být v tagu name (s výjimkou NP?) To by mělo záležet na názvu parku, většinou by tam asi to označení zůstalo - protect_class - ref - iucn_level - valid_from - pro rok vytvoření Použil bych spíš start_date, je rozšířenější. Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik renderovat) boundary=national_park. Když se budou dělat změny kvůli kompatibilitě s mapnikem tak nebude mít mapnik moc motivaci být měněn. Ještě pár dalších věcí k NP: Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba na Šumavě ochranné pásmo je CHKO. Na wiki je to popsané (site_zone), přidržel bych se toho Současný stav zmapování NP: * KRNAP Relace obsahovala mix cest hranic bez/s ochranného pásma; prozatím jsem relaci upravil tak, aby to aspoň byl platný polygon - ponechal jsem kompletnější hranice včtně ochranného pásma. Je potřeba upřesnit hranice ochranného pásma především okolo Vrchlabí, Některé cesty pro hranici vnitřních zón v databázi jsou, ale není jich moc. * Podyjí V OSM je dvakrát: - Nová relace (hranice včetně ochranného pásma). - Rozdělaný polygon (hranice bez ochranného pásma), kde chybí díra na Čížov, který je jen v ochranném pásmu. * Šumava, České Švýcarsko Vypadají celkem kompletně. Zdraví, Petr Morávek aka Xificurk [1] http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area Lukáš Matějka ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
LM_1 wrote: - valid_from - pro rok vytvoření Použil bych spíš start_date, je rozšířenější. V kombinaci s boundary=protected_area není... Můj návrh byl motivován zmínkou daného tagu na wiki a jeho použitím při podobném importu ve Francii. Pro NP možná použít kvůli kompatibilitě (aspoň dokud to nezačně mapnik renderovat) boundary=national_park. Když se budou dělat změny kvůli kompatibilitě s mapnikem tak nebude mít mapnik moc motivaci být měněn. V tomhle jsem osobně opravdu na vážkách - ty čtyři parky v ČR to vážně nevytrhnou (narozdíl od stovek dalších chráněných území)... prozatím by se aspoň vykraslovaly, jakožto nejdůležitější chráněná území v ČR, a po změně stylu pro mapnik by stačilo jen změnit boundary=national_park - boundary=protected_area Ještě pár dalších věcí k NP: Jak se vypořádat s ochrannými pásmy vs. vnitřními zónami NP? Já bych byl pro to, aby se jako hranice NP označila hranice vnitřních zón a ochranné pásmo označilo pomocí zvláštní relace podobně jako CHKO - ostatně třeba na Šumavě ochranné pásmo je CHKO. Na wiki je to popsané (site_zone), přidržel bych se toho Osobně moc nerozumím tomu popisu na wiki a jak konkrétně ho převést do praxe, pokud mi to po lopatě někdo vysvětlí (a ukáže, že se to takto vážně aspoň trochu používá), tak to uvítám. Zdraví, Petr Morávek aka Xificurk attachment: xificurk.vcf signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
Zdravím, s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil stránku o importu http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas s návrhy mých překladů EEA shapefile tagů do OSM. Osobně bych byl pro to natagovat tak, aby se to vše vykreslovalo (national_park), ale to je dosti brutální řešení. Rendering protected_area by bylo potřeba urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně stejně jako national_park - viděl jsem v tom jistou výhodu oproti spamovacímu tagu NR, který dává plošně text NR do území, myslel jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného kret*na, co to má nahoře nastarosti... Kozuch ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
PS. Nerenderuje se náhodou protected_area podle následujícího klíče? http://wiki.openstreetmap.org/wiki/Protected_Area_Rendering#Protected_Areas 2012/2/19 Jan Kučera kozuc...@gmail.com: Zdravím, s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil stránku o importu http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas s návrhy mých překladů EEA shapefile tagů do OSM. Osobně bych byl pro to natagovat tak, aby se to vše vykreslovalo (national_park), ale to je dosti brutální řešení. Rendering protected_area by bylo potřeba urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně stejně jako national_park - viděl jsem v tom jistou výhodu oproti spamovacímu tagu NR, který dává plošně text NR do území, myslel jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného kret*na, co to má nahoře nastarosti... Kozuch ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Import chráněných území z EEA
Jan Kučera wrote: Zdravím, s většinou, co bylo dosud řečeno, souhlasím. Na wiki jsem vytvořil stránku o importu http://wiki.openstreetmap.org/wiki/EEA:Nationally_designated_areas Měl bych pár připomínek: eea:cdda:sitecode - nahradil bych něčím jako 'ref:cdda' eea:cdda:objectid - nevím jestli je nutné... stejně bude výsledek jako relace a rozdělení na jednotlivé cesty se pravděpodobně s časem změní. eea:cdda:parentiso - je zbytečné, kde se daná oblast nachází vyplývá přímo z její polohy. area:ha - je zbytečné, rozloha je dána vymezením geometrie start_date - na zváženou, viz odpověď LM_1 Rendering protected_area by bylo potřeba urgentně pořešit, osobně jsem měl za to, že se již renderuje úplně stejně jako national_park - viděl jsem v tom jistou výhodu oproti spamovacímu tagu NR, který dává plošně text NR do území, myslel jsem, že to bylo výsledkem přirozeného vývoje v této oblasti. Bohužel dle mých krátkých zkušeností jsou změny nastavení mapniku asi těžko průchozí, že? Chtělo by to alespoň zatlačit ne nějakého patřičného kret*na, co to má nahoře nastarosti... Asi nejrychlejším řešením (které zvažuji i v souvislosti s double-renderingem názvů KÚ, obcí atd.) je poslat přímo návrh na změnu stylu jako pull-request na githubu [1]. [1] https://github.com/openstreetmap/mapnik-stylesheets attachment: xificurk.vcf signature.asc Description: OpenPGP digital signature ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [OSM-talk-fr] josm à court de memoire
Le 18/02/2012 10:06, Emilie Laffray a écrit : ...mon script pour lancer JOSM sous Windows 7 64 bits memoire 16Go 2012/2/18 PhQ pierre.que...@sfr.fr mailto:pierre.que...@sfr.fr Mon Josm.bat avec la latest sous Win7 (64 bits). mémoire 4Go Merci à tous des indications données. En effet, mes problèmes s'expliquent par le fait que je suis toujours en 32 bits. Bon, ben, va falloir que je migre. Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Re : Re : Accès KO au suivi des communes
De : Philippe Verdy verd...@wanadoo.fr Parfois aussi, il est inutile d'importer dans la base OSM des tags dont l'utilité n'est que temporaire et correspond à une tâche de maintenance ou de migration de données, puisque ces données de suivi peuvent être stockées ailleurs, et mises en relation en utilisant les numéros de référence d'OSM (numéro de nœuds, de chemins ou de relation), le plus souvent sur une page web dédiée à ce travail sous forme de tables (fichiers CSV faciles à générer et traiter avec des tonnes d'outils, feuilles de calcul Excel ou Openoffice, tableaux wiki, base de donnée MySQL ou similaire)... Les donnees OSM ne sont pas figees, se pose alors le probleme de la coherence avec les tables externes que tu mentionnes... De : Philippe Verdy verd...@wanadoo.fr À : simon msr...@gmail.com Cc : Discussions sur OSM en français talk-fr@openstreetmap.org Envoyé le : Samedi 18 février 2012 20h42 Objet : Re: [OSM-talk-fr] Re : Accès KO au suivi des communes Le 16 février 2012 21:27, simon msr...@gmail.com a écrit : Où est la charte de nommage des tags ? ici http://wiki.openstreetmap.org/wiki/Map_Features Ce n'est pas une charte de nommage, mais un catalogue... plus ou moins à jour, avec aussi des tas de propositions non abouties, voire abandonnées et remplacées par d'autres. La charte devrait consister à clarifier la façon de nommer les tags spécifiques à certains outils ou à certaines sources importées, afin d'éviter les conflits. Elle devrait aussi permettre de définir le domaine de leur utilisation, qui maintient ces spécifications, comment on peut les utiliser ou les classer, et leur concepteur doit aussi s'attendre à recevoir des demandes de discussion quant à certains choix. Parfois aussi, il est inutile d'importer dans la base OSM des tags dont l'utilité n'est que temporaire et correspond à une tâche de maintenance ou de migration de données, puisque ces données de suivi peuvent être stockées ailleurs, et mises en relation en utilisant les numéros de référence d'OSM (numéro de nœuds, de chemins ou de relation), le plus souvent sur une page web dédiée à ce travail sous forme de tables (fichiers CSV faciles à générer et traiter avec des tonnes d'outils, feuilles de calcul Excel ou Openoffice, tableaux wiki, base de donnée MySQL ou similaire)... ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Re : Re : Accès KO au suivi des communes
Le 19 février 2012 11:36, THEVENON Julien julien_theve...@yahoo.fr a écrit : De : Philippe Verdy verd...@wanadoo.fr Parfois aussi, il est inutile d'importer dans la base OSM des tags dont l'utilité n'est que temporaire et correspond à une tâche de maintenance ou de migration de données, puisque ces données de suivi peuvent être stockées ailleurs, et mises en relation en utilisant les numéros de référence d'OSM (numéro de nœuds, de chemins ou de relation), le plus souvent sur une page web dédiée à ce travail sous forme de tables (fichiers CSV faciles à générer et traiter avec des tonnes d'outils, feuilles de calcul Excel ou Openoffice, tableaux wiki, base de donnée MySQL ou similaire)... Les donnees OSM ne sont pas figees, se pose alors le probleme de la coherence avec les tables externes que tu mentionnes... Surtout que les ID des objets OSM ne sont pas pérennes. Par exemple, un node décrivant un POI peut disparaitre pour retrouver ses tags sur le way du bâtiment. C'est donc dans OSM qu'il faut stocker des références pérennes vers l'extérieur (les différents ref et ref:xxx). -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM - INSEE
Opps, Bien entendu ce mail n'était pas destiné à la liste de diffusion. Il s'agit d'un projet (plus trop) top secret ;). Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM - INSEE
Bonjour, Peut-on en savoir plus sur ce projet ? svp.let's be pleased with the environment Date: Sun, 19 Feb 2012 21:58:32 +0100 From: fred.rodr...@gmail.com To: talk-fr@openstreetmap.org Subject: Re: [OSM-talk-fr] OSM - INSEE Opps, Bien entendu ce mail n'était pas destiné à la liste de diffusion. Il s'agit d'un projet (plus trop) top secret ;). Frédéric ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] OSM - INSEE
Le 19 février 2012 22:04, sukran.geo sukran.geo sukran@live.fr a écrit : Bonjour, Peut-on en savoir plus sur ce projet ? svp. Patience... c'est encore en gros chantier. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-ja] Bing画像更新中？
Tomです。 やっぱり、そうでしたか。 画像が変わったような気がして、数日前から、気になってました。 JOSMのキャッシュで気が付くのが遅れたかもしれませんが。 もしかしたら、配信エリアが増えているかもしれませんね。要調査ですが。 2012年2月20日0:16 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 つい最近、何箇所かでBing画像が 新しくなったり(2010/1、2010/3、2011/2など) 以前よりひとつ上のズームレベル(18-19)まで 配信されるようになっているのに気付きました。 おおすごい、と思ったものの 場所により、新しく配信された画像のレベル19だけがズレているところがありました。 下記は大分の例ですがズームを19に上げて頂くとズレが分かります。 http://www.openstreetmap.org/edit?lat=32.853279lon=131.627403zoom=18 よろしければいちどご近所を再確認してみてはいかがでしょうか。 やはりsourceタグには以下のように年月まで付けた方が良さそうですが source=Bing, 2010-01 現状、下記で年月を調べるしか無いんですかね。 http://mvexel.dev.openstreetmap.org/bing/ ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 早川知道 (Tomomichi Hayakawa) tom.hayak...@gmail.com うえこみ春日井小牧 - http://www.kasugai-komaki.jp/ Malaika System - http://malaika-system.com/ blog - close to you - http://malaika.air-nifty.com/ OSM Tokai - http://groups.google.com/group/OSM-Tokai XOOPS Cube TOKAI - http://xc-tokai.net/ =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] GeocachingがOSMを採用
古橋＠OSMFJ/マップコンシェルジュです。 ジオキャッシング、2008年のジオジオスタンプラリー以来で、４年ぶりにチャレンジしてみましたが あえなく、レベル１のキャッシュすらみつからず今日の夕方保育園帰りに再度チャレンジします。 SotM 2012 Tokyo で 9/9(日) に予定している 高尾山エクスカーションで、世界中のマッパーとジオキャッシングやりたいなと企画中です。 どうぞよろしくお願いいたします。 FacebookのグループURLみつけたので共有します。 しかし、G社 ってついGoogle社と脳内変換してしまいますね。 :-) G社 OSM部 http://www.facebook.com/groups/gcjp.osmap/ ジオキャッシング・ジャパン (Geocaching Japan) http://www.facebook.com/groups/geocachingjapan/ 2012年2月19日1:10 Satoshi IIDA nyamp...@gmail.com: いいだです。 以前からジオキャッシュには興味あったので、 この機会に参加・ユーザ登録してみました。 都市圏でもけっこうキャッシュが隠してあるみたいなので、 機会を見つけて探してみたいと思います。 どちらも興味深い活動だと思っているので、 お互いの面白みを話せると嬉しいですね〜♪ 上記グループにはどうやったら参加できますか？ Facebookで「ジオキャッシング・ジャパン」で検索すると、出てきた。。。はずです(^^; # ごめんなさい、僕はFacebookのインターフェースがとても苦手なので、 # ジオキャッシングのOSMコミュニティを見つけられませんでした。 # ao_zealさんの紹介をお待ちしてます m(_ _)m 2012年2月17日1:00 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 そうです。先日は色々と教えていただきありがとうございました。 ぜひ４月７日予定の花見にもいらしてください。 100人近いジオキャッシャーが各地から集まってきますので。 行きます！ 少し前からfacebookにジオキャッシャー向けのOSM用グループをたてて 参加者を募っていましたが今回の公式地図の変更で何人か増え、 早速マッピングしてみたという人も出てきたようです。 僕自身始めたばかりで正しいタグ付けが出来てるとは言いがたいので 手探り状態です。皆さんのお力をお借り出来ればと思います。 できることでしたら何なりとお手伝いさせて頂きたいと思います。 facebookの使い方があまり良く分かっていないのですが 上記グループにはどうやったら参加できますか？ On 2012/02/16, at 0:48, Shu Higashi wrote: ao_zealさん、こんにちは。東です。 人違いでしたらすみませんが、OSC東京で少しお話させて頂いた Geocashingをやられている方でしょうか。 情報ありがとうございます。 MapQuest(OSMベース)のマップを使っているようですね。 海外ではGeocashingをやっているマッパーは結構いると聞いたことがあります。 日本でもぜひマッピングへの参加者が出てくることを期待しています！ 私もキャッシュはひとつだけゲットしたことがあります。 Geocashingのイベントに参加したいなぁ、と思いつつ随分経ってしまいました。。 12/02/15 藤本 正樹 ao_z...@yahoo.co.jp: ao_zealと言います。 GPSを使った宝探しゲーム・Geocachingの公式サイトで使われていた地図が GoogleMapからOpenStreetMapに切り替わりました。 GoogleMapのライセンス料の負荷に耐えきれなくなったようです。 海外が主流のゲームなので日本のユーザーは少ないものの、 ユーザーの多くはGPSrを持っているので今後マッピングに参加する人が出るかもしれません。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap F. Japan with sinsai.info ## Director of the OSGeo F. Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## ZIP359-1142, Kamiarai 4-4-1,Tokorozawa,Saitama ## 〒359-1142 埼玉県所沢市上新井4-4-1 ## TEL/SkypeTwitterLIFB: 070-6401-5963 / mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan Shop: http://gpsconcierge.jp 備考欄「古橋紹介」記載で5%OFF ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] GeocachingがOSMを採用
東です。 私も久々に近所のキャッシュを検索してみたら 飛躍的に数が増えていてびっくりしました。 ぜひ再開したいと思っています。 FBの方は、主催者の方のお考えがあるかと思いますので そちらのご判断をお待ちください。 12/02/20 FURUHASHI Taichi mapconcie...@gmail.com: 古橋＠OSMFJ/マップコンシェルジュです。 ジオキャッシング、2008年のジオジオスタンプラリー以来で、４年ぶりにチャレンジしてみましたが あえなく、レベル１のキャッシュすらみつからず今日の夕方保育園帰りに再度チャレンジします。 SotM 2012 Tokyo で 9/9(日) に予定している 高尾山エクスカーションで、世界中のマッパーとジオキャッシングやりたいなと企画中です。 どうぞよろしくお願いいたします。 FacebookのグループURLみつけたので共有します。 しかし、G社 ってついGoogle社と脳内変換してしまいますね。 :-) G社 OSM部 http://www.facebook.com/groups/gcjp.osmap/ ジオキャッシング・ジャパン (Geocaching Japan) http://www.facebook.com/groups/geocachingjapan/ 2012年2月19日1:10 Satoshi IIDA nyamp...@gmail.com: いいだです。 以前からジオキャッシュには興味あったので、 この機会に参加・ユーザ登録してみました。 都市圏でもけっこうキャッシュが隠してあるみたいなので、 機会を見つけて探してみたいと思います。 どちらも興味深い活動だと思っているので、 お互いの面白みを話せると嬉しいですね〜♪ 上記グループにはどうやったら参加できますか？ Facebookで「ジオキャッシング・ジャパン」で検索すると、出てきた。。。はずです(^^; # ごめんなさい、僕はFacebookのインターフェースがとても苦手なので、 # ジオキャッシングのOSMコミュニティを見つけられませんでした。 # ao_zealさんの紹介をお待ちしてます m(_ _)m 2012年2月17日1:00 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 そうです。先日は色々と教えていただきありがとうございました。 ぜひ４月７日予定の花見にもいらしてください。 100人近いジオキャッシャーが各地から集まってきますので。 行きます！ 少し前からfacebookにジオキャッシャー向けのOSM用グループをたてて 参加者を募っていましたが今回の公式地図の変更で何人か増え、 早速マッピングしてみたという人も出てきたようです。 僕自身始めたばかりで正しいタグ付けが出来てるとは言いがたいので 手探り状態です。皆さんのお力をお借り出来ればと思います。 できることでしたら何なりとお手伝いさせて頂きたいと思います。 facebookの使い方があまり良く分かっていないのですが 上記グループにはどうやったら参加できますか？ On 2012/02/16, at 0:48, Shu Higashi wrote: ao_zealさん、こんにちは。東です。 人違いでしたらすみませんが、OSC東京で少しお話させて頂いた Geocashingをやられている方でしょうか。 情報ありがとうございます。 MapQuest(OSMベース)のマップを使っているようですね。 海外ではGeocashingをやっているマッパーは結構いると聞いたことがあります。 日本でもぜひマッピングへの参加者が出てくることを期待しています！ 私もキャッシュはひとつだけゲットしたことがあります。 Geocashingのイベントに参加したいなぁ、と思いつつ随分経ってしまいました。。 12/02/15 藤本 正樹 ao_z...@yahoo.co.jp: ao_zealと言います。 GPSを使った宝探しゲーム・Geocachingの公式サイトで使われていた地図が GoogleMapからOpenStreetMapに切り替わりました。 GoogleMapのライセンス料の負荷に耐えきれなくなったようです。 海外が主流のゲームなので日本のユーザーは少ないものの、 ユーザーの多くはGPSrを持っているので今後マッピングに参加する人が出るかもしれません。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap F. Japan with sinsai.info ## Director of the OSGeo F. Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## ZIP359-1142, Kamiarai 4-4-1,Tokorozawa,Saitama ## 〒359-1142 埼玉県所沢市上新井4-4-1 ## TEL/SkypeTwitterLIFB: 070-6401-5963 / mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan Shop: http://gpsconcierge.jp 備考欄「古橋紹介」記載で5%OFF ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] GeocachingがOSMを採用
古橋です。 失礼しましたー！ Facebookで公開グループだったので、 何も考えずにシェアしちゃいましたー。 2012年2月20日10:20 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 私も久々に近所のキャッシュを検索してみたら 飛躍的に数が増えていてびっくりしました。 ぜひ再開したいと思っています。 FBの方は、主催者の方のお考えがあるかと思いますので そちらのご判断をお待ちください。 12/02/20 FURUHASHI Taichi mapconcie...@gmail.com: 古橋＠OSMFJ/マップコンシェルジュです。 ジオキャッシング、2008年のジオジオスタンプラリー以来で、４年ぶりにチャレンジしてみましたが あえなく、レベル１のキャッシュすらみつからず今日の夕方保育園帰りに再度チャレンジします。 SotM 2012 Tokyo で 9/9(日) に予定している 高尾山エクスカーションで、世界中のマッパーとジオキャッシングやりたいなと企画中です。 どうぞよろしくお願いいたします。 FacebookのグループURLみつけたので共有します。 しかし、G社 ってついGoogle社と脳内変換してしまいますね。 :-) G社 OSM部 http://www.facebook.com/groups/gcjp.osmap/ ジオキャッシング・ジャパン (Geocaching Japan) http://www.facebook.com/groups/geocachingjapan/ 2012年2月19日1:10 Satoshi IIDA nyamp...@gmail.com: いいだです。 以前からジオキャッシュには興味あったので、 この機会に参加・ユーザ登録してみました。 都市圏でもけっこうキャッシュが隠してあるみたいなので、 機会を見つけて探してみたいと思います。 どちらも興味深い活動だと思っているので、 お互いの面白みを話せると嬉しいですね〜♪ 上記グループにはどうやったら参加できますか？ Facebookで「ジオキャッシング・ジャパン」で検索すると、出てきた。。。はずです(^^; # ごめんなさい、僕はFacebookのインターフェースがとても苦手なので、 # ジオキャッシングのOSMコミュニティを見つけられませんでした。 # ao_zealさんの紹介をお待ちしてます m(_ _)m 2012年2月17日1:00 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 そうです。先日は色々と教えていただきありがとうございました。 ぜひ４月７日予定の花見にもいらしてください。 100人近いジオキャッシャーが各地から集まってきますので。 行きます！ 少し前からfacebookにジオキャッシャー向けのOSM用グループをたてて 参加者を募っていましたが今回の公式地図の変更で何人か増え、 早速マッピングしてみたという人も出てきたようです。 僕自身始めたばかりで正しいタグ付けが出来てるとは言いがたいので 手探り状態です。皆さんのお力をお借り出来ればと思います。 できることでしたら何なりとお手伝いさせて頂きたいと思います。 facebookの使い方があまり良く分かっていないのですが 上記グループにはどうやったら参加できますか？ On 2012/02/16, at 0:48, Shu Higashi wrote: ao_zealさん、こんにちは。東です。 人違いでしたらすみませんが、OSC東京で少しお話させて頂いた Geocashingをやられている方でしょうか。 情報ありがとうございます。 MapQuest(OSMベース)のマップを使っているようですね。 海外ではGeocashingをやっているマッパーは結構いると聞いたことがあります。 日本でもぜひマッピングへの参加者が出てくることを期待しています！ 私もキャッシュはひとつだけゲットしたことがあります。 Geocashingのイベントに参加したいなぁ、と思いつつ随分経ってしまいました。。 12/02/15 藤本 正樹 ao_z...@yahoo.co.jp: ao_zealと言います。 GPSを使った宝探しゲーム・Geocachingの公式サイトで使われていた地図が GoogleMapからOpenStreetMapに切り替わりました。 GoogleMapのライセンス料の負荷に耐えきれなくなったようです。 海外が主流のゲームなので日本のユーザーは少ないものの、 ユーザーの多くはGPSrを持っているので今後マッピングに参加する人が出るかもしれません。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- Satoshi IIDA mail: nyamp...@gmail.com twitter: @nyampire ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap F. Japan with sinsai.info ## Director of the OSGeo F. Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## ZIP359-1142, Kamiarai 4-4-1,Tokorozawa,Saitama ## 〒359-1142 埼玉県所沢市上新井4-4-1 ## TEL/SkypeTwitterLIFB: 070-6401-5963 / mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan Shop: http://gpsconcierge.jp 備考欄「古橋紹介」記載で5%OFF ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja -- ## Taichi FURUHASHI(MAPconcierge Inc. President) ## MAPconcierge satellite office at http://goo.gl/VgWD6 in NOMAD NEW'SBASE ## Vice-President of OpenStreetMap F. Japan with sinsai.info ## Director of the OSGeo F. Japan ## Researcher of the center for spatial info. science, univ.of Tokyo ## ZIP359-1142, Kamiarai 4-4-1,Tokorozawa,Saitama ## 〒359-1142 埼玉県所沢市上新井4-4-1 ## TEL/SkypeTwitterLIFB: 070-6401-5963 / mapconcierge ## URL/Mail: http://www.mapconcierge.jp tai...@mapconcierge.jp ## GPS/GigaPan Shop: http://gpsconcierge.jp 備考欄「古橋紹介」記載で5%OFF ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] オンラインマップ作成GISツールShareMap.org（ベータ版）
ikiyaです。 紹介ありがとうございます。 いろいろ使ってみました。 東さんご指摘のノードのインポートも可能になったみたいで 大変良いと思います。 OSMerにとっては自由に地図を書くだけではなく 自由に地図を使うためのツールが増えることはうれしいです。 OSMデータからのインポートを使って、別レイヤにPOIのコピーを 持てせればいろいろできます。 ・POIへのアイコン選択登録、大きさ、色、テキスト付与などできます。 ・普段目にするmapnikでは画面表示のズーム倍率で消えてしまう POIも別レイヤにすることでズーム倍率に縛られずに表示できます。 ・mapnikでは隣り合うPOIが近すぎると干渉してname（お店の名前など）が 表示されませんがこちらではラベルを書けば表示できます。 ・mapnikではレンダリングされないman madeタグやemergencyタグの POIをインポートして表示させることが可能です。 （私はこれが一押しです） ・gpsログもインポート表示できますがあまり大きなログは負荷がかかって 固まります。 ただ、用意されてるアイコンで一部不足やインポートできないPOIなどが見うけられました。 --- On Sun, 2012/2/19, Yoichi Kayama yoichi.kay...@gmail.com wrote: かやまです これいいですねえ。 OSMのデータを応用したい場合、いいアイデアですねえ。 2012年2月19日11:47 Shu Higashi s_hig...@mua.biglobe.ne.jp: 東です。 OSMをベースに、QGISのような本格的なクライアントアプリとまでは行かなくても オンラインで簡単にOSMデータを抽出・分析したり、 別レイヤで点、線、エリアや注釈を書き込んで 手軽にシェアしたい時があります。 そういったサービスの代表的なものは arcgis.com だと思いますが その簡易版のようなサービスが http://sharemap.org/site/index で提供されています。 まだベータ版なのでOSMからウェイはインポートできるが ノードができない、といったバグがありますが、日本語は通るようです。 元々はWikipediaやWikimedia Commons掲載用のマップを 作るために開発されたようです。 東京のサンプル http://sharemap.org/public/Tokyo ログインしなくてもパブリックなマップは誰でも作成、編集できます。 アカウントを作ると自分の領域でマップを作れるようです。 ご参考まで。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
[Talk-GB] National Trust Scotland Talk
Hi, Just wanted to update you on the OSM lunchtime talk I gave to the National Trust Scotland. You can find the slides and video here: http://wiki.openstreetmap.org/wiki/Edinburgh#Talks Thanks for the maps and examples everyone sent. I made some useful contacts and signed up a few more volunteers. Tim From: talk-gb-requ...@openstreetmap.org Subject: Talk-GB Digest, Vol 65, Issue 18 To: talk-gb@openstreetmap.org Date: Sun, 19 Feb 2012 12:00:02 + Send Talk-GB mailing list submissions to talk-gb@openstreetmap.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.openstreetmap.org/listinfo/talk-gb or, via email, send a message with subject or body 'help' to talk-gb-requ...@openstreetmap.org You can reach the person managing the list at talk-gb-ow...@openstreetmap.org When replying, please edit your Subject line so it is more specific than Re: Contents of Talk-GB digest... Today's Topics: 1. License remapping - Just deleting (Michael Collinson) -- Message: 1 Date: Sat, 18 Feb 2012 16:05:34 +0100 From: Michael Collinson m...@ayeltd.biz To: OSM talk-gb talk-gb@openstreetmap.org Subject: [Talk-GB] License remapping - Just deleting Message-ID: 4f3fbe3e.3020...@ayeltd.biz Content-Type: text/plain; charset=ISO-8859-1; format=flowed Hi, I got an email from a respected contributor and I want to pass on one concern. It is very natural to want all the red ink on OSMI License View disappear as quickly as possible so that we don't have to revisit the spots. I suggest though that where there are things that you can't remap using Bing, OS StreetView and general local knowledge, like footpaths, (not easy to see and the designation is very important in the UK), and some POIs, then just leave them alone or take a winter trip. Footpaths in particular are the most time consuming to map, several hours of walking for just one line. In the UK, we are now in pretty good shape with only 5 declined and 14 undecided mappers in the top 1,000 [1]. But ya never know, more may still come aboard. Thank you for everyone's efforts. Mike [1] http://odbl.de/great_britain.html -- ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb End of Talk-GB Digest, Vol 65, Issue 18 *** ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-GB] United Kingdom Tagging Guidelines on the OSM wiki: due for an update?
Hi All, I hadn't thought about public footpaths along a road. It nicely demonstrates that for RoWs the highway tag really doesn't matter as it is the designation that gives the relevant information. In that case I would tend to agree with Andrew's methodology (which also makes things easier for routing software): 1. If it is clearly a route for walking on (e.g. paved or signposted) then use highway=footway. 2. If it looks like people use it as a route to walk/cycle(?) (e.g. well trodden ground) but no sign or paving then highway=path. I would also be happy to review any proposed edits to the wiki page if the link is posted here. I don't know of the technical ins and outs of the relevant laws but could give you good new user feedback. Cheers, Rob Hi You are dead right - I was talking about paths as in narrow strips of ground for walking on. I would tag a public footpath as highway=whatever is appropriate: unclassified|residential|service|track|path, designation=public_footpath. Graham. On 18 February 2012 10:48, Derick Rethans osm at derickrethans.nl http://lists.openstreetmap.org/listinfo/talk-gb wrote: * Hi, On Sat, 18 Feb 2012, Graham Jones wrote: On the other hand I treat highway=path as just being a statement of fact** -** 'there is a path here', so it needs some access tags adding to it. In** my** mind highway = footway is about the same as highway=path; foot=yes (or** maybe designation=public_footpath, but that is more specific). During the Weybridge mapping party, I'd encountered some residential** roads (highway=residential) or service roads (highway=service) that were** also public footpaths, so I've mapped those as: highway=residential** designation=public_footpath http://www.openstreetmap.org/browse/way/150222454 Marking those roads as highway=footway or highway=path makes no sense** (to me). cheers,** Derick --** http://derickrethans.nl | http://xdebug.org** Like Xdebug? Consider a donation: http://xdebug.org/donate.php** twitter: @derickr and @xdebug*** -- Graham Jones Hartlepool, UK. ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
Re: [Talk-GB] United Kingdom Tagging Guidelines on the OSM wiki: due for an update?
On Sun, 19 Feb 2012, Rob Nickerson wrote: I hadn't thought about public footpaths along a road. It nicely demonstrates that for RoWs the highway tag really doesn't matter as it is the designation that gives the relevant information. Well, in my case it's not even *along* the road... it's just the road. cheers, Derick -- http://derickrethans.nl | http://xdebug.org Like Xdebug? Consider a donation: http://xdebug.org/donate.php twitter: @derickr and @xdebug ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-us] Feature Proposal - RFC - Tag:cycleway=buffered_lane
I've proposed a tag for buffered bicycle lanes, see the proposal herehttp://wiki.openstreetmap.org/wiki/Cycleway%3Dbuffered_lane. Any feedback is appreciated. -Grant ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Feature Proposal - RFC - Tag:cycleway=buffered_lane
On 2/19/2012 5:34 PM, Humphries, Grant wrote: I've proposed a tag for buffered bicycle lanes, see the proposal here http://wiki.openstreetmap.org/wiki/Cycleway%3Dbuffered_lane. Any feedback is appreciated. It seems like it would be better as an additional tag like cycleway:buffer=yes, keeping cycleway=lane for backwards compatibility. By the way, it's wrong to say that it is not intended for travel by any mode, since you have to cross it to reach the parking. You should also keep opinions about which is safer out of OSM; there are certainly arguments on both sides. http://commuteorlando.com/wordpress/2011/07/22/the-bikespace-on-west-colonial/ ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Tracking Deleted Streets and Comparison Tools
At 2012-02-18 16:03, Humphries, Grant wrote: I am attempting to track deleted streets and other changes that have significant effects on routing between versions of OSM data that are approximately one and two months apart ... the purpose of this effort is to ensure the integrity of the data each time we update, which happens every several weeks. How about: move along each way, printing a list of intersections (nodes that are shared with other ways) as pairs of names. Diff this against the new version to see where changes are. If you want to include changes in distance, include the intersection coordinates. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
