Re: [OSM-talk] Extracting data from traffic sign recognition aboard modern cars ?
Paul Johnson-3 wrote Sounds like all the more reason to try this. Not a good idea. If you break anything trying to hack into the driver assistance functions, you might cause an accident, either directly by malfunctions of the driver assistance or indirectly by distracting the driver with unexpected results. By design, fiddling with those devices is likely to trigger the theft protection, disabling them completely and voiding the warranty of the car. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/Extracting-data-from-traffic-sign-recognition-aboard-modern-cars-tp5757713p5757787.html Sent from the General Discussion mailing list archive at Nabble.com. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] GeoJSON and TileMill
Hi. I want to do some maps in TileMill and have a question. As a data source for now I use GeoJSON exports from overpass-turbo, which looks fine so far. I can style that as long as I style everything (e.g. I exported all highway=* in my target area and I'm able to draw lines for all highways), but how can I query only specific tags in that layer? It looks like tags are recognized as one field by tilemill, not as individual fields/columns, so that a selector by field is not sufficient. Is there anything I could do or is geojson support that limited? regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extracting data from traffic sign recognition aboard modern cars ?
On 04/20/2013 09:20 AM, NopMap wrote: Paul Johnson-3 wrote Sounds like all the more reason to try this. Not a good idea. If you break anything trying to hack into the driver assistance functions, you might cause an accident, either directly by malfunctions of the driver assistance or indirectly by distracting the driver with unexpected results. By design, fiddling with those devices is likely to trigger the theft protection, disabling them completely and voiding the warranty of the car. Passively sniffing the CAN bus for sign recognition events would be entirely undetected - but that would require reverse engineering the protocol and writing specific code... One might argue that rigging a dashcam and processing its output on a desktop with some road sign recognition software (generic pattern recognition neural net trained with road signs ?) would be less effort - albeit an inelegant effort duplication. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extracting data from traffic sign recognition aboard modern cars ?
On 04/20/2013 11:37 AM, Jean-Marc Liotier wrote: On 04/20/2013 09:20 AM, NopMap wrote: Paul Johnson-3 wrote Sounds like all the more reason to try this. Not a good idea. If you break anything trying to hack into the driver assistance functions, you might cause an accident, either directly by malfunctions of the driver assistance or indirectly by distracting the driver with unexpected results. By design, fiddling with those devices is likely to trigger the theft protection, disabling them completely and voiding the warranty of the car. Passively sniffing the CAN bus Or would that be the MOST bus nowadays ? My knowledge of automotive technology is hazy... ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extracting data from traffic sign recognition aboard modern cars ?
Jean-Marc Liotier skrev 2013-04-20 11:42: On 04/20/2013 11:37 AM, Jean-Marc Liotier wrote: Passively sniffing the CAN bus Or would that be the MOST bus nowadays ? My knowledge of automotive technology is hazy... Probably one of the many CAN busses. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
... hi, here http://wiki.openstreetmap.org/wiki/Tag:boundary=protected_area something is prepared. may be boundary=protected_area + protect_class=24 + protection_title=... best, tshrub ___ talk mailing list talk at openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
OK, but would you apply this to Scotland and Wales? Because that's an analogous situation in the UK. On Sat, Apr 20, 2013 at 8:33 AM, tshrub my-email-confirmat...@online.dewrote: ... hi, here http://wiki.openstreetmap.org/wiki/Tag:boundary=protected_area something is prepared. may be boundary=protected_area + protect_class=24 + protection_title=... best, tshrub ___ talk mailing list talk at openstreetmap.org http://lists.openstreetmap.org/listinfo/talk ___ 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] Native American/First Nation, etc. Reservation Boundaries
Paul Johnson baloo at ursamundi.org writes: OK, but would you apply this to Scotland and Wales? Because that's an analogous situation in the UK. basic is, to mark the reservation situation worldwide by two tags - to become rendered (once). A fine tuning you have to align by additional keys; there are some proposed, for collecting important data - like zones, or something like no photos (don´t know yet, if a tag like that already exists). a boundary=protected_area is running beside a boundary=administrative (line-bundle). I'm from the continent, but 'think, I would apply this to Scotland and Wales :) examples: russ: http://www.openstreetmap.org/browse/way/178596361 colum: http://www.openstreetmap.org/browse/way/102574866 ... best, tshrub ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Extracting data from traffic sign recognition aboard modern cars ?
On Sat, 2013-04-20 at 11:37 +0200, Jean-Marc Liotier wrote: On 04/20/2013 09:20 AM, NopMap wrote: Paul Johnson-3 wrote Sounds like all the more reason to try this. Not a good idea. If you break anything trying to hack into the driver assistance functions, you might cause an accident, either directly by malfunctions of the driver assistance or indirectly by distracting the driver with unexpected results. By design, fiddling with those devices is likely to trigger the theft protection, disabling them completely and voiding the warranty of the car. Passively sniffing the CAN bus for sign recognition events would be entirely undetected - but that would require reverse engineering the protocol and writing specific code... I am wondering how good this technology is. Does it cope with implied speed limits such as a change from single to dual-carriageway, motorway chopsticks sign, the presence of street lights, a placename, a placename with a line through it. Does it have a GPS to know if the limit is mph of kph, or what country it is in. If it is using a GPS and stored mapping then there is the danger of polluting OSM with proprietary data. There is also the danger of picking up temporary limits, such as roadworks, which should not be imported into OSM. One might argue that rigging a dashcam and processing its output on a desktop with some road sign recognition software (generic pattern recognition neural net trained with road signs ?) would be less effort - albeit an inelegant effort duplication. I have used a dash cam to enable me to tag speed limits, no automation, just fast step through when I get home. One other advantage is it can be used to extract a lot more information, crossings, traffic lights, shop names and so on. Phil (trigpoint) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On 2013-04-20 19:24, Paul Johnson wrote: OK, but would you apply this to Scotland and Wales? Because that's an analogous situation in the UK. Not really. Scotland/England/Wales are clearly administrative boundaries, and they are tagged as such in OSM. And they fit in the hierarchy of admin levels, ie below national boundaries, above council areas etc. They are comparable to states in the USA. So not relevant to tagging Native American lands. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On Fri, Apr 19, 2013 at 6:52 PM, Paul Johnson ba...@ursamundi.org wrote: As previously stated, admin levels 3 and 5 depending on status as a nation or reservation, respectively. Looking at the admin levels, I agree 3 and 5 would appear to fit. But boundary=domestic_dependent_nation (not a currently accepted tag, just a place holder) would eliminate problems of which admin level the boundary is assigned. I don't care for the term aboriginal_lands as proposed on the wiki. I don't believe we need to tag small tribal lands when they are remote from the main tribal boundary. However, I don't have any good examples to offer. One part of my original message I still need help with. Why aren't we adding these boundaries to OSM? If it is just that no one as added any or is there an issue I'm not aware of? Personally I'd like to start adding in these boundaries, at least in the US and then only for geographical areas I'm familiar with. -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On Apr 20, 2013 7:23 PM, Craig Wallace craig...@fastmail.fm wrote: On 2013-04-20 19:24, Paul Johnson wrote: OK, but would you apply this to Scotland and Wales? Because that's an analogous situation in the UK. Not really. Scotland/England/Wales are clearly administrative boundaries, and they are tagged as such in OSM. And they fit in the hierarchy of admin levels, ie below national boundaries, above council areas etc. They are comparable to states in the USA. So not relevant to tagging Native American lands. It is entirely relevant, because Native American nations are, for almost all practical purposes, either above the county level or the state level to try to shoehorn it into that hierarchy. They have their own laws, levy their own taxes, run their own courts, schools, jails, road authorities, police, issue license plates, and in a few even more sovereign examples, issue internationally recognized passports and have their own militia forces. They're even recognized as independent in the US constitution, and analogous UK situations just aren't running into this debate. I'm having trouble grasping why this situation is different from autonomous and sovereign regions within the national boundaries of another state are somehow special or different on this continent than on every other continent. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On Apr 20, 2013 8:53 PM, Clifford Snow cliff...@snowandsnow.us wrote: One part of my original message I still need help with. Why aren't we adding these boundaries to OSM? If it is just that no one as added any or is there an issue I'm not aware of? Personally I'd like to start adding in these boundaries, at least in the US and then only for geographical areas I'm familiar with. It's a little bit of a chicken/egg thing right now. As far as I'm aware, rendering of tribal nations went offline in mapnik around the time I pointed out the overly broad tagging and that having most of Oklahoma and big chunks of New Mexico hatched in white on green IR (had the former tagging scheme been used on all 200+ such territories in North America) would have been awkward and was misleading due to the nearly identical NR hatch of nature reserves circa summer 2010 when I moved my geographic focus to indian country. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
I can't speak for the US, but tagging of them in BC was set back by people pushing the view that they should be tagged as provinces. There were also issues that someone imported a bunch without geometry or tag cleanup. The fact that they generally cross admin_level=* boundary=administrative boundaries and those boundaries cross them is a pretty strong indication that they're orthogonal to admin_level boundary. AFAIK, reservations are pretty much unique to Canada, the US and Australia. Oddly enough, I've been to all of those countries. From: Clifford Snow [mailto:cliff...@snowandsnow.us] Sent: Saturday, April 20, 2013 6:54 PM To: Paul Johnson Cc: Talk Openstreetmap Subject: Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries One part of my original message I still need help with. Why aren't we adding these boundaries to OSM? If it is just that no one as added any or is there an issue I'm not aware of? Personally I'd like to start adding in these boundaries, at least in the US and then only for geographical areas I'm familiar with. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On Sat, Apr 20, 2013 at 9:37 PM, Paul Johnson ba...@ursamundi.org wrote: It's a little bit of a chicken/egg thing right now. As far as I'm aware, rendering of tribal nations went offline in mapnik around the time I pointed out the overly broad tagging and that having most of Oklahoma and big chunks of New Mexico hatched in white on green IR (had the former tagging scheme been used on all 200+ such territories in North America) would have been awkward and was misleading due to the nearly identical NR hatch of nature reserves circa summer 2010 when I moved my geographic focus to indian country. Is rendering the issue or tagging? You provoked me to look further. I found a level 4 admin boundary with a boundary:type of aboriginal_lands for the Hoopa Valley Tribe. Previously I was only looking for a name with the work reservation. It was just added August 4, 2012, relatively recently. I think your suggestion of a level 3 or 5 would be more appropriate. At first glance it looked like the Six Rivers National Forest, but it actually the Tribal boundaries. Hoopa Valley Tribe http://www.openstreetmap.org/?lat=41.0997lon=-123.6757zoom=12layers=M -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Native American/First Nation, etc. Reservation Boundaries
On Sat, Apr 20, 2013 at 10:21 PM, Paul Norman penor...@mac.com wrote: I can’t speak for the US, but tagging of them in BC was set back by people pushing the view that they should be tagged as provinces. There were also issues that someone imported a bunch without geometry or tag cleanup. In the US, Federally recognized tribes seem to be somewhere equal to state or higher, thus admin level 3 would seem more appropriate. But then there are cases where the the tribe occupies a small city. Question, how does the admin level impact the rendering? The fact that they generally cross admin_level=* boundary=administrative boundaries and those boundaries cross them is a pretty strong indication that they’re orthogonal to admin_level boundary. I agree. AFAIK, reservations are pretty much unique to Canada, the US and Australia. Oddly enough, I’ve been to all of those countries. Lived in two, but not Australia. What about New Zealand for example the Maori? Because of treaties, how we tag the boundaries, may be universal. I'm planning to get in touch with a friend from a tribe in Alaska. I'm hoping that he might have good contacts to help me understand this better. I think he is out of the country on a holiday right now. -- Clifford OpenStreetMap: Maps with a human touch ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [Talk-br] Matheus Eduardo está de volta
Como normalmente sou o mais afetado pelas edições dele, dei uma olhada em todas essas novas edições e não encontrei nenhum problema nelas. O que podemos fazer é ficar de olho. Eu estou vigiando os changesets dele (e de todo mundo no RN), mas às vezes atraso um pouco por falta de tempo. 2013/4/20 Blademir Andrade de Lima blademi...@hotmail.com Pelo que vi, minhas edições não foram afetadas, ainda. Só me resta parar e esperar o pior. Ja cogitei parar de colaborar se ele continuar com essa pichação. att Blademir Andrade de Lima -- Date: Mon, 15 Apr 2013 12:33:01 -0300 From: vitor.geo...@gmail.com To: talk-br@openstreetmap.org Subject: [Talk-br] Matheus Eduardo está de volta Pessoal, O Matheus Eduardo está fazendo edições novamente: http://www.openstreetmap.org/user/Matheus%20Eduardo/edits Se alguém notar que ele continua fazendo má edições, por favor, avisem para que possamos tomar providências. Vitor ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br ___ Talk-br mailing list Talk-br@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-br
Re: [Talk-de] proposed/construction bei Relationen
Hi, Am Sat, 20 Apr 2013 07:17:37 +0200 schrieb RainerU ra...@sfr.fr: ...proposed=bicycle anstelle von route=bicycle? In einer Relation mit type=route sollte auf jeden Fall route=* vorkommen. Das proposed müsste man also ggf. woanders unterbringen type=route, route=bicycle_proposed oder type=proposed_route, proposed_route=bicycle. Wilhelm ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Die Verwendung [1] von proposed/construction ist i.d.R. ja die folgende: highway=construction + construction=primary railway=proposed + proposed=tram oder ... Auf Routen-Relationen umgelegt also: type=route + route=proposed + proposed=bicycle Grüße Martin / tyr_asd [1] http://wiki.openstreetmap.org/wiki/DE:Key:proposed#Wie_eintragen ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
state=proposed Siehe: https://wiki.openstreetmap.org/wiki/Cycle_routes Beispiel: relation 1742549 Gruss Volker Padova, Italien 2013/4/20 RainerU ra...@sfr.fr Hallo, Bei Straßen, die geplant oder im Bau sind, setzt man proposed=highway_type bzw, construction=highway_type anstelle des highway-Attributes. Wie macht man das bei Relationen, z.B. einem geplanten Radwanderweg? proposed=bicycle anstelle von route=bicycle? Gruß Rainer ___ 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] proposed/construction bei Relationen
Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Mit dem Nachteil, dass viele Anwendungen das nicht kennen. Ist im Fall der Routen aber weniger tragisch, da die zugrundeliegenden Straßen / Wege ja existieren (sollten). Chris ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Andreas Schmidt wrote: Klar, man kann alle Zeichen, die die Tastatur nicht hat, per Tastaturcode einfügen. Ist halt nur sehr umständlich. Eben. Also ich werde zumindest nicht mit irgendwelchen Alt + Nummer-Kombinationen irgendwelchen Text setzen sondern auch weiterhin schnell meine tippen. Auch ein Sonderzeichen einfügen-Feature würde *ich* nicht nutzen. Zumal man diese Zeichen beim Rendern eigentlich recht unkompliziert auch automatisiert durch die anderen Zeichen ersetzen kann. Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20.04.2013 11:27, schrieb RainerU: Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Rechtschreibung und Zeichensetzung in den Karten
Am 20. April 2013 11:24 schrieb Manuel Reimer manuel.s...@nurfuerspam.de: Andreas Schmidt wrote: Klar, man kann alle Zeichen, die die Tastatur nicht hat, per Tastaturcode einfügen. Ist halt nur sehr umständlich. Eben. Also ich werde zumindest nicht mit irgendwelchen Alt + Nummer-Kombinationen irgendwelchen Text setzen sondern auch weiterhin schnell meine tippen. Auch ein Sonderzeichen einfügen-Feature würde *ich* nicht nutzen. Zumal man diese Zeichen beim Rendern eigentlich recht unkompliziert auch automatisiert durch die anderen Zeichen ersetzen kann. zugegeben ist die Eingabe von „“ auf manchen Systemen ein Problem, (auf anderen nicht, alt+^ bzw. alt+2). Traditionell ersetzt man mit Schreibmaschinen die Anführungszeichen durch oder ggf. auch durch »« oder «». Beim Rendern kann man das hinterher nicht mehr ersetzen, wenn die Information, welche Zeichen verwendet werden, beim Mappen verloren gegangen ist, dann kann man eigentlich nur raten oder besser das darstellen, was auch gemappt ist. Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
2013/4/20 Henning Scholland o...@aighes.de Am 20.04.2013 11:27, schrieb RainerU: Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.**org/wiki/Cycle_routeshttps://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. Da kann man durchaus verschiedener Meinung sein. Vorgeschlagene Radrouten auf der Karte wiederzugeben kann in vielen Faellen nuetzlich sein, insbesondere, wenn solche Routen der tatsaechlichen touristischen Benutzung durch Fahrrad tour operators entspricht (was in Norditalien der Fall ist). OpenCycleMap nuetzt den state=proposed, um die Route gestrichelt wiederzugeben, waehrend cycling.waymarkedtrails.org sie nicht zeigt. Volker ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20. April 2013 11:34 schrieb Henning Scholland o...@aighes.de: Am 20.04.2013 11:27, schrieb RainerU: Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.**org/wiki/Cycle_routeshttps://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. sehe ich auch so, prinzipiell finde ich das mappen von vorgeschlagenen Routen nicht so besonders glücklich, aber es gibt wohl Situationen, wo man es tolerieren sollte. Haben in Italien schon einiges zu dem Thema diskutiert und die Aussagen waren, dass diese Routen zwar noch nicht offiziell ausgeschildert sind, im Prinzip aber schon aktive Radrouten sind, d.h. bevorzugt von Radfahrern genutzt werden. Mangels offizieller Alternativen (d.h. es gibt überhaupt noch sehr wenige offizielle Radrouten) sei diese Information für Fahrradfahrer von ausserhalb daher mindestens so wichtig, als wären die Routen bereits ausgeschildert ;-) Gruß, Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20.04.2013 11:55, schrieb Martin Koppenhoefer: Am 20. April 2013 11:34 schrieb Henning Scholland o...@aighes.de: Am 20.04.2013 11:27, schrieb RainerU: Am 20.04.2013 11:05, schrieb Volker Schmidt: state=proposed Siehe: https://wiki.openstreetmap.**org/wiki/Cycle_routeshttps://wiki.openstreetmap.org/wiki/Cycle_routes Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. sehe ich auch so, prinzipiell finde ich das mappen von vorgeschlagenen Routen nicht so besonders glücklich, aber es gibt wohl Situationen, wo man es tolerieren sollte. Haben in Italien schon einiges zu dem Thema diskutiert und die Aussagen waren, dass diese Routen zwar noch nicht offiziell ausgeschildert sind, im Prinzip aber schon aktive Radrouten sind, d.h. bevorzugt von Radfahrern genutzt werden. Mangels offizieller Alternativen (d.h. es gibt überhaupt noch sehr wenige offizielle Radrouten) sei diese Information für Fahrradfahrer von ausserhalb daher mindestens so wichtig, als wären die Routen bereits ausgeschildert ;-) Da hab ich ja nichts gegen, dass die dargestellt werden. Auch das es sinnvoll für die Radler sein kann bestreite ich nicht. Ich finde es nur schlecht, wenn man als Auswerter zig Tags zusätzlich abfragen muss, um tatsächlich existierende Objekte zu finden. Das steigert nicht gerade die Lust unsere Daten zu nutzen. Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Hallo Henning, Am 20.04.2013 11:34, schrieb Henning Scholland: Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. Anlass meiner Frage ist die im Radreise Fernradler Forum hochgekommene Kritik an der OpenCycleMap [1], die speziell in Frankreich viele Radwanderwege anzeigt, die nur in der Planung existieren. Ich halte es nicht für sinnvoll, die entsprechenden Relationen zu löschen. Das würde die dortige Community auch nicht akzeptieren. In einigen Fällen sind die Wege bereits in der Realisierung, z.B. der Abschnitt am Canal du Midi im Département Aude. Da ist es nicht sinnvoll, die Relation jetzt zu löschen und in ein paar Monaten wieder neu anzulegen. Wie bei Straßen kann es auch interessant sein den Planungsstand zu erfassen. Und es wäre auch unfair den Mappern gegenüber, die sich viel Mühe gemacht haben. Ich werde wohl den Vorschlag state=proposed zu verwenden. Schön wäre wenn Waymarkedtrails dieses Attribut auch auswerten und die Routen gestrichelt oder auf andere Weise erkennbar anzeigen würde. Gruß Rainer [1] http://radreise-forum.de/topics/930026/Neues_aus_dem_Radreise_Wiki#Post930026 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Da hab ich ja nichts gegen, dass die dargestellt werden. Auch das es sinnvoll für die Radler sein kann bestreite ich nicht. Ich finde es nur schlecht, wenn man als Auswerter zig Tags zusätzlich abfragen muss, um tatsächlich existierende Objekte zu finden. Das steigert nicht gerade die Lust unsere Daten zu nutzen. Da gebe ich dir grundsätzlich Recht. Aber wer die Lust nicht schon verloren hat, wenn er aus den access-Tags ermitteln will, ob ein Weg für Radfahrer zugelassen ist, der die schafft auch noch das eine oder andere Tag an Route-Relationen. Gruß Rainer ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Hallo Rainer, wie von Löschen hab ich nichts gesagt. Was man mit type=route route=bicycle aussagt ist, dass es eine Radroute ist. Im Fall einer geplanten Radroute ist das einfach mal falsch. Betrachtet man es logisch, müsste etwas wie type=proposed_route proposed_route=bicycle gesetzt werden. Henning Am 20.04.2013 12:36, schrieb RainerU: Hallo Henning, Am 20.04.2013 11:34, schrieb Henning Scholland: Da finde ich ncn/rcn/lcn=proposed besser. Allerdings vermute ich, dass das von den Spezialkarten wie cycling.waymarkedtrails.org und Opencyclemap auch nicht ausgewertet wird. So wird es sein. Warum auch? Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. Anlass meiner Frage ist die im Radreise Fernradler Forum hochgekommene Kritik an der OpenCycleMap [1], die speziell in Frankreich viele Radwanderwege anzeigt, die nur in der Planung existieren. Ich halte es nicht für sinnvoll, die entsprechenden Relationen zu löschen. Das würde die dortige Community auch nicht akzeptieren. In einigen Fällen sind die Wege bereits in der Realisierung, z.B. der Abschnitt am Canal du Midi im Département Aude. Da ist es nicht sinnvoll, die Relation jetzt zu löschen und in ein paar Monaten wieder neu anzulegen. Wie bei Straßen kann es auch interessant sein den Planungsstand zu erfassen. Und es wäre auch unfair den Mappern gegenüber, die sich viel Mühe gemacht haben. Ich werde wohl den Vorschlag state=proposed zu verwenden. Schön wäre wenn Waymarkedtrails dieses Attribut auch auswerten und die Routen gestrichelt oder auf andere Weise erkennbar anzeigen würde. Gruß Rainer [1] http://radreise-forum.de/topics/930026/Neues_aus_dem_Radreise_Wiki#Post930026 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20. April 2013 12:16 schrieb Henning Scholland o...@aighes.de: Am 20.04.2013 11:55, schrieb Martin Koppenhoefer: Am 20. April 2013 11:34 schrieb Henning Scholland o...@aighes.de: Wer rechnet damit, dass wenn einer route=bicycle und network=*cn setzt, dann noch ein weiteres Tag kommt, dass sagt: Ätsch, aber erst in x Jahren? Wenn die Route noch keine Radroute ist, dann ist das Setzen von route=bicycle falsch. sehe ich auch so, prinzipiell finde ich das mappen von vorgeschlagenen Routen nicht so besonders glücklich, aber es gibt wohl Situationen, wo man es tolerieren sollte. Haben in Italien schon einiges zu dem Thema diskutiert und die Aussagen waren, dass diese Routen zwar noch nicht offiziell ausgeschildert sind, im Prinzip aber schon aktive Radrouten sind, d.h. bevorzugt von Radfahrern genutzt werden. Mangels offizieller Alternativen (d.h. es gibt überhaupt noch sehr wenige offizielle Radrouten) sei diese Information für Fahrradfahrer von ausserhalb daher mindestens so wichtig, als wären die Routen bereits ausgeschildert ;-) Da hab ich ja nichts gegen, dass die dargestellt werden. Auch das es sinnvoll für die Radler sein kann bestreite ich nicht. Ich finde es nur schlecht, wenn man als Auswerter zig Tags zusätzlich abfragen muss, um tatsächlich existierende Objekte zu finden. Das steigert nicht gerade die Lust unsere Daten zu nutzen. wobei das, wenn Du der Argumentation oben folgst, wohl in Italien bewusst so gemacht wurde, so dass diese Routen als existierend dargestellt werden, was auch nicht unbedingt ganz falsch ist (d.h. sie existieren de facto, sind aber (noch) nicht ausgeschildert vor Ort). Gruß Martin ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Am 20.04.2013 12:43, schrieb RainerU: Da hab ich ja nichts gegen, dass die dargestellt werden. Auch das es sinnvoll für die Radler sein kann bestreite ich nicht. Ich finde es nur schlecht, wenn man als Auswerter zig Tags zusätzlich abfragen muss, um tatsächlich existierende Objekte zu finden. Das steigert nicht gerade die Lust unsere Daten zu nutzen. Da gebe ich dir grundsätzlich Recht. Aber wer die Lust nicht schon verloren hat, wenn er aus den access-Tags ermitteln will, ob ein Weg für Radfahrer zugelassen ist, der die schafft auch noch das eine oder andere Tag an Route-Relationen. Oder aber er sagt sich: Ist mir zu komplex, das lasse ich lieber. ;) Henning ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] Internal Server Error beim Zugriff auf die API?
Hallo, gerade kann ich nicht editieren, weil ich ständig Internal Server Errors bekomme. Laut Wiki ist aber alles am Laufen. Hat noch jemand das Problem? Gruß Manuel ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Internal Server Error beim Zugriff auf die API?
dito :( eventuell schrauben die ein wenig dran rum? Gruss walter -- View this message in context: http://gis.19327.n5.nabble.com/Internal-Server-Error-beim-Zugriff-auf-die-API-tp5757820p5757822.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Internal Server Error beim Zugriff auf die API?
On 04/20/13 15:00, Walter Nordmann wrote: dito :( eventuell schrauben die ein wenig dran rum? Gruss walter Ich hatte gestern ein paar mal die Meldung irgendwann gings dann wieder :-D ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OsmAnd nicht verfuegbar
OsmAnd is not available on Google Play ... We experienced some problems with DMCA request on Google Play, but it should be available soon in 1-3 working days (depends on Google site). So lautet die Info bei http://osmand.net/ Seit 13.04.2013 (7 Tage) ist OsmAnd nicht mehr verfügbar und im OsmAnd-Forum häufen sich die Klagen dass auch die kostenpflichtige Version OsmAnd+ trotz Bezahlung nicht verfügbar sei. Weiß jemand Näheres? Bernhard ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OsmAnd nicht verfuegbar
Seit 13.04.2013 (7 Tage) ist OsmAnd nicht mehr verfügbar und im Weiß jemand Näheres? Gibt wohl Ärger hinter den Kullissen auf Entwicklerseite. Hier etwas näheres: https://groups.google.com/forum/?fromgroups=#!topic/osmand/vLaJtB4FRHc Gruß TimG ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-de] OSM-history nach verschwundener Relation durchsuchen (online)
Hi Kann mir jemand weiterhelfen ? Ich suche eine Relation welche vor einiger Zeit mal gemappt war und jetzt fehlt jede Spure von ihr. Ich weiß noch Teile des Namen und route=road. Auch kann ich den Bereich sehr gut einschränken. Gibt es eine Seite, auf der ich online suchen kann ? Was für andere Möglichkeiten bleiben mir mit schwachen PC (Linux) und lahmen Internet ? Danke fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OsmAnd nicht verfuegbar
Weiß jemand Näheres? Es scheint Differenzen zwischen dem Designer und dem Projektmanagement gegeben zu haben. Jetzt ist man vermutlich nicht mehr berechtigt, die bisherigen Icons zu verwenden. Dies hatte dann vermutlich auch die Entfernung aus dem Google Play Store zur Folge. Jetzt ist man dabei, alle Icons auszutauschen. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-history nach verschwundener Relation durchsuchen (online)
Auch kann ich den Bereich sehr gut einschränken. Dann hilft dir vielleicht: http://zverik.osm.rambler.ru/whodidit/ http://owl.apis.dev.openstreetmap.org ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] OSM-history nach verschwundener Relation durchsuchen (online)
On 20.04.2013 22:01, qunuxy-osmmailingli...@yahoo.com wrote: Auch kann ich den Bereich sehr gut einschränken. Leider ist er nicht gerade klein. Dann hilft dir vielleicht: Danke für die Links. http://zverik.osm.rambler.ru/whodidit/ Was heißt hier eternity ? Ganz brauchbar aber nichts gefunden. http://owl.apis.dev.openstreetmap.org Werden hier überhaupt Relationen ausgewertet. Leider bin ich mir nicht sicher wie lange die Relation schon gelöscht ist. Kann gut auch schon ein Jahr her sein. Ein Service mit flexibler Zeitspanneneingabe und Objektentypfilter wäre super, dann könnte ich systematisch filtern. Mir ist gerade eingefallen, dass ich vielleicht Glück habe und doch noch ein paar alte .osm Dateien rumfahren. fly ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] proposed/construction bei Relationen
Martin Raifer wrote Die Verwendung [1] von proposed/construction ist i.d.R. ja die folgende: highway=construction + construction=primary railway=proposed + proposed=tram oder ... Auf Routen-Relationen umgelegt also: type=route + route=proposed + proposed=bicycle +1 Für Construction auf highways gibt es ein etabliertes und kompatibles System. Dementsprechend sollte man bei Routen analog verfahren. Es funktioniert, wer construction/proposed anzeigen will kann es sich gezielt dazunehmen. Und es ist schon vertraut. Ich fände es ziemlich bedauerlich, hier trotz etablierter besserer Lösung auf Zusatztags zurückzufallen, bei denen klar ist daß die noch nicht existenten Routen dann bei allen Auswertern zu sehen sind, die von den Zusatztags nichts wissen und der Nutzer in die Irre geschickt wird. bye, Nop -- View this message in context: http://gis.19327.n5.nabble.com/proposed-construction-bei-Relationen-tp5757785p5757864.html Sent from the Germany mailing list archive at Nabble.com. ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-it] Fwd: [OSM-dev] Show Me The Way - Yet Another Live Edit Viewer
Il 04/17/2013 12:52 AM, Martin Koppenhoefer scrisse: OSM live, ancora una volta... C'e' un articolo anche su Wired: http://www.webmonkey.com/2013/04/watch-openstreetmap-improve-in-real-time/ ciao maxx ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Dilemma marciapiede non connesso.
Controllando con tools geofabrik [1], opzione routing, la zona da me mappata mi rivela delle way che non sono connesse, e corrispondono ai tratti di marciapiede. Quindi, dopo aver guardato nella wiki, ma non trovo riferimenti di sorta, per capire, la way dedicata al marciapiede, deve partire da un nodo della strada per poi, dopo un tratto ricongiungersi, oppure può rimanere isolato, ovvero distaccato dalla strada? Mi sembrerebbe utile che nella wikifosse spiegato questo particolare, lo farei io, ma l'inglese non lo so, wuindi semmai, se lo faccio, mi servirebbe poi una mano per la traduzione della rispettiva parte di pagina.. [1] http://tools.geofabrik.de/osmi/ ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] Dilemma marciapiede non connesso.
On sab, 2013-04-20 at 13:23 +0200, girarsi_liste wrote: deve partire da un nodo della strada per poi, dopo un tratto ricongiungersi, oppure può rimanere isolato, ovvero distaccato dalla strada? Deve ricongiungersi, altrimenti un algoritmo di routing non saprebbe come passare dal marciapiede ad un'altra strada. Mi sembrerebbe utile che nella wikifosse spiegato questo particolare Giusto. Ora si intuisce qualcosa leggendo la pagina sugli attraversamenti [1] «mappare gli attraversamenti pedonali come una way vera e propria, che collega un footway=sidewalk al nodo Node highway=crossing sulla strada principale.» Qui si dice che la way corrispondente al marciapiede deve essere collegata con un nodo highway=crossing che faccia parte anche della strada principale. È anche possibile indicare la presenza/assenza di marciapiedi aggiungendo tag direttamente alla strada principale: sidewalk=both se c'è da entrambe le parti, left/right se c'è solo da un lato o sidewalk=none se non c'è. [1] https://wiki.openstreetmap.org/wiki/IT:Tag:footway%3Dcrossing -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email br...@tracciabi.li GNU/Linux registered user #121507 http://linuxcounter.net signature.asc Description: This is a digitally signed message part ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] negozio cani e gatti
Cosa si può mettere x negozio cani e gatti...? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] negozio cani e gatti
On sab, 2013-04-20 at 15:13 +0200, beppebo...@libero.it wrote: Cosa si può mettere x negozio cani e gatti...? shop=pet https://wiki.openstreetmap.org/wiki/Tag:shop%3Dpet -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email br...@tracciabi.li GNU/Linux registered user #121507 http://linuxcounter.net signature.asc Description: This is a digitally signed message part ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] negozio cani e gatti
Ok anche se pet è generale non solo x cani e gatti ---Messaggio originale Da: br...@anche.no Data: 20/04/2013 15.31 A: talk-it@openstreetmap.org Ogg: Re: [Talk-it] negozio cani e gatti On sab, 2013-04-20 at 15:13 +0200, beppebo...@libero.it wrote: Cosa si può mettere x negozio cani e gatti...? shop=pet https://wiki.openstreetmap.org/wiki/Tag:shop%3Dpet -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email bruno@tracciabi. li GNU/Linux registered user #121507 http://linuxcounter.net ___ 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] negozio cani e gatti
Sulla stessa pagina è scritto: Add pethttps://wiki.openstreetmap.org/w/index.php?title=Key:petaction=editredlink=1 =* if they sell specific pet. allora se sei sicuro, puoi specificare pet=cat; dog On 20 April 2013 22:06, beppebo...@libero.it beppebo...@libero.it wrote: Ok anche se pet è generale non solo x cani e gatti ---Messaggio originale Da: br...@anche.no Data: 20/04/2013 15.31 A: talk-it@openstreetmap.org Ogg: Re: [Talk-it] negozio cani e gatti On sab, 2013-04-20 at 15:13 +0200, beppebo...@libero.it wrote: Cosa si può mettere x negozio cani e gatti...? shop=pet https://wiki.openstreetmap.org/wiki/Tag:shop%3Dpet -- CONTACTS http://tracciabi.li/~bruno/contacts.html 2nd email bruno@tracciabi. li GNU/Linux registered user #121507 http://linuxcounter.net ___ 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 ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-se] FixaMinGata - samarbete?
Jag tänkte skapa en ny sida med länk från svenska startsidan och där börja med att lägga upp några huvudrubriker (sidor) med underrubriker (kapitel/stycken). Sen jobbar vi lite med rubrikerna och när vi är nöjda skapar vi en sida per huvudrubrik och börjar skriva. Jag hojtar till när jag skapat sidan. Solen trädgården har dock högsta prio i helgen. ;-) -- Vänliga hälsningar Peter Kindström Christoffer Holmstedt christoffer.holmst...@gmail.com skrev: Jag kan hjälpa till med en nybörjarmanual. Jag tänker mig någon form av flossmanual eller liknande där innehållet är väldigt praktiskt vinklat. Vart på wikin börjar vi? Peter du kan ju hojta till i nytt mail till listan när du har fått upp den gamla strukturen. -- Christoffer Holmstedt Den 19 april 2013 22:08 skrev Henrik Lundqvist h.lundqv...@gmail.com: Jag är på, med den lilla tid jag kan avvara mvh Henrik ___ Henrik Lundqvist h.lundqv...@gmail.com Den 19 april 2013 20:58 skrev Peter Kindström peter.kindst...@abc.se: Hej! Vad sägs om att påbörja en arbetsversion av en 'nybörjarmanual' som ett projekt/samling undersidor på svenska delen av OSM-wikin? Jag hittade en gammal fil med både en struktur och lite innehåll som jag kan lägga upp. Sen kan den som vill/kan/orkar vara med och komplettera, ändra, flytta och ta bort. När vi har tillräckligt mycket information kan jag tänka mig göra om mina gamla OSM-sidor för detta ändamål - och helst också lägga till några redaktörer som kan hjälpa till med olika delar av webbplatsen. Blir detta sen stort kan vi ju alltid gå vidare med eget webbhotell, domän och annat. Eller återgå till wikin om intresset svalnar. Vad tycker ni? Vilka är med? -- Vänliga hälsningar Peter Kindström Joakim Fors joa...@joakimfors.org skrev: On 19 apr 2013, at 18:31, Peter Kindström peter.kindst...@abc.se wrote: Hej! Det här låter intressant! Jag har väntat ett tag på en svensk tjänst som vill samarbeta med OSM, till gagn för bägge parter. Som Henrik skriver kan man hämta mycket från wikin, men jag rekommenderar inte att man hänvisar direkt dit. En separat webbplats vore mycket bättre och där fokus skulle vara att lära nybörjare komma igång med OSM. För djupare info kan man å andra sidan gärna hänvisa till wikin! Jag hade en gång en ambition att samla nyheter och fakta om hur man karterar specifika saker. Kanske kan vi fortsätta där eller utgå från det? http://www.infolagret.se/openstreetmap/ Brukar (Brukade) läsa din blog när du ännu höll den uppdaterad och det var trevligt med någon som lite mer utåtriktat informerade om OSM i .se. En möjlighet är ju att försöka skyffla in något (MediaWiki?) på openstreetmap.se (Kalle vet hur man får tag i personen som sitter på domänen). I vilket fall är jag också beredd att hjälpa till lite, med liknande reservation att nyköpt hus på landet kräver stor del av min fritid. Frågan är hur vi går vidare? //Mvh Peter Kindström Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-es] Calle sin nombre.
Hola a todos, Tengo una duda, he utilizado la etiqueta noname=yes para marcar calles que no tienen nombre, sin embargo, en OSM Inspector siguen apareciendo como layer: name_missing_minor ¿Alguien puede comentar cual es la forma más correcta de etiquetar calles sin nombre? Gracias. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
[Talk-es] Proyecto de Senderos en Canarias
Hola. He creado la página http://wiki.openstreetmap.org/wiki/WikiProject_Spain/Senderismo/Canarias Si alguien quiere colaborar falta por actualizar el estado de cada sendero. Saludos. ___ Talk-es mailing list Talk-es@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-es
Re: [Talk-at] OGD NÖ
Hallo, Am 13. April 2013 01:18 schrieb Soldier Boy soldierboy2...@gmail.com: Grenzen wirken sehr ungenau. Sollte man mal checken was die echten Grenzen sind. Denke aber die Daten sind auch eher nutzlos. es handelt sich dabei um generalisierte Daten fr den Mastab 1:200.000, die fr uns ziemlich unbrauchbar sind, siehe dazu auch die unten zitierten Mails. Wie dort auch zu lesen ist, war der Grund, warum ich mich berhaupt fr die Daten interessiert habe, diese Gemeindegrenze zw. Mnchendorf und Velm: http://www.openstreetmap.org/?lat=48.03395lon=16.41704zoom=16layers=M Nachdem ich den genauen Grenzverlauf nicht kenne, aber zumindest wei, dass der Drrsee komplett auf Mnchendorfer und die Kienerseen auf Velmer Gebiet liegen sollten, soll ich zumindest das einmal irgendwie hinschtzen, was dann wohl immer noch eher korrekt ist, als die jetzige Grenze? Ich vermute, dass es beim Seedrfl an der Grenze zu Laxenburg hnlich sein wird. LG Andreas Am 17.04.2013 07:32, schrieb Andreas Wecer: Sehr geehrte Damen und Herren, Ich wrde gerne wissen, wie oft die von Ihnen angebotenen Daten zu den Verwaltungsgrenzen (http://data.noe.gv.at/Land-Zukunft/Open-Government-Data/Geographie-und-Planung/Verwaltungsgrenzen_politische_Gemeinden.html) aktualisiert werden? Konkret interessiert mich die Gemeinde- und Bezirksgrenze zw. Mnchendorf und Velm, die ich gerne in Openstreetmap aktualisieren wrde: http://www.openstreetmap.org/?lat=48.03395lon=16.41704zoom=16layers=M Laut Mnchendorfer Chronik msste sich hier der Grenzverlauf 2007 gendert haben, sodass die Grenze nicht mehr durch den Drrsee verluft, sondern dieser komplett auf Mnchendorfer Gebiet liegt, was in dem von Ihnen angebotenen Shapefile allerdings noch nicht der Fall ist. Vielen Dank Andreas Wecer Am 18.04.2013 15:56, schrieb GIS-Support (BD3): Sehr geehrter Herr Wecer, Wie in den Metainformationen zu diesem Datensatz ersichtlich wurden diese Gemeindegrenzpolygone 2005 erstmalig erstellt und werden in den darauffolgenden Jahren "bei Bedarf" aktualisiert. VORSICHT: Ebenfalls ersichtlich ist, dass es sich hierbei um auf den Mastab 1:200.000 !!!GENERALISIERTE!!! Polygone handelt. D.h. diese wurden von Ihrer Sttzpunktanzahl derart vereinfacht, dass sie fr Karten im Mastab 1:200.000 (etwa Niedersterreichbersichten im Papierformat A0) geeignet sind. Wrde man in solchen Kartenmastben die exakten Grenzverlufe verwenden, wre das Darstellungsergebnis nicht zufriedenstellend, deshalb ist es fr kartografisch hochwertige Produkte notwendig zu generalisieren. Da wir die Urheberschaft fr diesen generalisierten Datensatz halten ist es uns mglich diese im Rahmen von OGD zur freien Verwendung anzubieten. Allerdings bezweifle ich, dass die Openstreetmap Community daran interessiert ist, generalisierte Grenzverlufe in Ihrer Plattform vorzuhalten, da dies fr Webkartendienste in der Regel nicht sinnvoll ist. Die Urheberschaft fr katasterscharfe Verwaltungsgrenzen liegt bei den sterreichischen Vermessungsmtern, bzw. in weiterer Folge beim Bundesamt fr Eich- und Vermessungswesen, da diese Grenzverlufe in der Regel direkt aus dem Grundstckskataster abgeleitet wird. Um Ihnen den Unterschied zu verdeutlichen kann ich Ihnen folgenden Screenshot beilegen auf dem Sie die Grundstcksparzellen des fraglichen Ausschnitts in Mnchendorf sehen knnen. Die rote Linie zeigt dabei den katasterscharfen Grenzverlauf der Gemeindegrenze, whrend unser Generalisierungsalgorithmus diese Schikane geradlinig durchluft (schwarze Linie). Der Informationsgehalt im Mastab 1:200.00 wird durch diese Vereinfachung eben nicht oder kaum beeinflusst, das Darstellungsergebnis aber entsprechend verbessert. Ich wrde also dringend davon abraten die generalisierten Gemeindegrenzen generell in OpenStreetMap einzuarbeiten. signature.asc Description: OpenPGP digital signature
Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise
Concernant le fichier RNIPP de l'INSEE ou du CNAVTS (français nés à l'étranger, dans les TOM ou Mayotte) [citation] Qui peut consulter ce fichier ? Les organismes autorisés par la CNIL ou par des dispositions législatives ou réglementaires prises après avis de la CNIL. Le casier judiciaire reçoit chaque année un extrait du RNIPP conformément à l’article 1er de la loi n°80-2 du 4 janvier 1980 [/citation] Autrement dit il existe des restrictions à la consultation publique de ce fichier. L'autorisation donnée par la CNIL pourrait donc ne pas s'étendre d'une part à d'autres personnes que celle autorisées ci-dessus, ni à leur mise en place par d'autres que l'Insee et le CNAVTS. Prudence donc concernant les noms de personnes physiques (dans une autre proposition j'avais parlé de n'indiquer QUE les noms d'artistes et un lien vers Wikipédia pour leur biographie, pas le reste ; même le lien vers Wikipédia pourrait être un article sujet au respect des droits exclusifs de la personnes, qui s'étendent 70 ans après leur mort, une durée étendue en cas de mort pour la France' ou de vie durant les périodes de guerre). On peut considérer que la sépulture des personnes rentre aussi dans le champ du droit d'auteur (la personne a eu le droit d'organiser ses obsèques, son monument funéraire, et sa mémoire). Avant d'intégrer les noms des personnes sur les tombes, un avis de la CNIL sera sans doute nécessaire (déclaration en bonne et due forme de la base OSM : description des champs, droit d'accès et de correction pour les héritiers représentants légaux des défunts, description complète des usages très ouverts par l'inscription dans OSM puisqu'il n'y aura aucune restriction, la CNIL doit le savoir et pourrait opposer son veto complet à une telle inscription de données personnelles). En y réfléchissant je ne suis même pas sûr que les noms d'artistes puissent même y figurer (ils font partie de la propriété intellectuelle couverte par le droit d'auteur et dont sont titulaires les héritiers légaux qui peuvent les exploiter comme des marques commerciales, par exemple Picasso, Dalida, Dior, Citroen... des marques qui par ailleurs pourraient déjà avoir été cédées par les personnes de leur vivant sans les priver, de leur droit personnel de continuer à porter ce nom pour elles et leurs conjoint ou enfants ou le reste de leur famille, seul ce droit s'éteignant à leur mort, mais pas leur droit moral). Le 18 avril 2013 16:15, Pieren pier...@gmail.com a écrit : 2013/4/18 Christian Quest cqu...@openstreetmap.fr http://www.legifrance.gouv.fr/affichTexte.do?cidTexte=JORFTEXT00886460 Ca, c'est la définition d'une personne physique (par opposition à une personne morale) cette notion juridique s'éteint avec la proclamation du décès (d'après WP): Vi. Là, on dit juste que la personne ne peut plus être trainée en justice ou jugée après son décès (ne riez pas, ça s'est vu par le passé). On parle de sa personnalité juridique propre. Ce qui ne dit rien sur le respect de sa vie privée, qui ne s'éteint pas avec le décès. Cela n'a rien à voir avec la constitution d'un fichier nominatif de personnes physiques, qui est lié au droit au respect de la vie privée et qui peut aussi concerner celle de la famille. En googlant un peu, je tombe par exemple sur: http://www.comparavie.fr/fiches-pratiques/contrat-non-reclame-agira.php A partir du fichier des personnes physiques décédées depuis 1978, communiqué et mis à jour mensuellement par l'Insee, la Cnil a autorisé l'Agira a organiser une base de données relative aux personnes décédées On peut aussi parler du fichier RNIPP de l'INSEE qui contient les informations de 97 millions de personnes physiques, vivantes ou mortes: http://www.cnil.fr/en-savoir-plus/fichiers-en-fiche/fichier/article/rnipp-repertoire-national-didentification-des-personnes-physiques/ Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise
Ci-git Dalida©®™ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Suite au redémarrage du service, j'ai le plaisir, l'honneur et l'avantage de vous signaler la fin de l'import du bâti du PDD (63) . A nous le plaisir des mis à jour et suivi :) -- View this message in context: http://gis.19327.n5.nabble.com/http-cadastre-openstreetmap-fr-tp5757271p5757797.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Rendu OSM-FR : couleurs highway
Je suis géné depuis longtemps par les couleurs utilisées par le rendu par défaut de osm.org (mapnik) notamment concernant les routes et plus particulièrements les highway qi sont rendus en vert... Ce qui ce confond très largement avec les forêts et autres champs. Rendant la lisibilité de ces axes importants plus faible que les routes secondaires... D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs différents qui permettent de bien rendre lisible tout les axes (en même temps heureusement car c'est un rendu orienté routes). Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit essayé de tout rendre au mieux (pas simple), mais je trouve vraiment dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont quand même très important et structurant. Comme la communauté française dispose désormais d'une base d'expérimentation (merci Christian), je proposerai (à discuter bien sur) d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple : motorway : Bleu foncé/violet trunk : Bleu primary, primary_link : Rouge secondary, secondary_link : Orange tertiary, tertiary_link : Jaune unclassified, residential, road : Blanc living_street, pedestrian : Gris clair service : track, path : pointillé noir ? J'y connais rien en rendu mais le plus souvent les axes autoroutes et routes pour automobile sont rendus avec un style différent : couleur interne et bordure d'une autre couleur et épaisse. C'est la cas de openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est une piste à explorer pour rentrer dans les standards... Pour illustrer voici une image du même endroit avec plusieurs rendus (dont des rendus commerciaux) : https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour permettre d'identifier le rendu FR comme provenant d'OSM. J'ai déjà modifié la couleur verte des trunks pour qu'elles soient plus contrastées sur les landuse de couleur proche mais ça peut sûrement encore s'affiner sans changer complètement le jeu de couleur. Le 20 avril 2013 12:47, Pierre-Alain Dorange pdora...@mac.com a écrit : Je suis géné depuis longtemps par les couleurs utilisées par le rendu par défaut de osm.org (mapnik) notamment concernant les routes et plus particulièrements les highway qi sont rendus en vert... Ce qui ce confond très largement avec les forêts et autres champs. Rendant la lisibilité de ces axes importants plus faible que les routes secondaires... D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs différents qui permettent de bien rendre lisible tout les axes (en même temps heureusement car c'est un rendu orienté routes). Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit essayé de tout rendre au mieux (pas simple), mais je trouve vraiment dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont quand même très important et structurant. Comme la communauté française dispose désormais d'une base d'expérimentation (merci Christian), je proposerai (à discuter bien sur) d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple : motorway : Bleu foncé/violet trunk : Bleu primary, primary_link : Rouge secondary, secondary_link : Orange tertiary, tertiary_link : Jaune unclassified, residential, road : Blanc living_street, pedestrian : Gris clair service : track, path : pointillé noir ? J'y connais rien en rendu mais le plus souvent les axes autoroutes et routes pour automobile sont rendus avec un style différent : couleur interne et bordure d'une autre couleur et épaisse. C'est la cas de openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est une piste à explorer pour rentrer dans les standards... Pour illustrer voici une image du même endroit avec plusieurs rendus (dont des rendus commerciaux) : https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/synthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] tag pour un toit en terrasse
Bonjour, Je m'attaque à spécifier les différents types de building=* (à la place des yes). Comment peut-on indiquer un toit (de quelque chose, comme une habitation ou un garage) qui est aussi une terrasse ? Je ne trouve pas d'info particulière nulle part à ce sujet. Agnès ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Rendu OSM-FR : couleurs highway
En même temps OSM a fait des compromis pour s'adapter aux couleurs habituellement utilisées dans certains pays : le Royaume-Uni par exemple a ses motorways différents du reste de l'Europe. Si on regarde dans le détail chaque pays, il y a des adaptations locales du rendu du réseau routier, de la couleur des cartouches pour les numéros des routes, pour la façon d'afficher des restrictions de circulation comme les sens de circulation obligatoires et interdits. La couleur habituelle des autoroutes en France est une ligne jaune tracée au milieu sur une ligne rouge plus épaisse (le fin liseré rouge foncé ou noir en bordure est optionnel mais s'obtient aussi facilement en traçant d'abord la ligne plus foncée légèrement plus épaisse avant les lignes rouge et jaune). [note] Pour tracer les tunnels c'est un peu plus compliqué car on ne peut pas superposer des traits pleins si le coeur de la ligne doit rester semi-transparent : les pointillés de bordure demandent de préparer d'abord une géométrie de buffers : ce que fait de toute façon le tracé de n'importe quelle ligne simple qui nécessite de transformer un trait sans aucune épaisseur, en un polygone à remplir, avec en plus un éventuel rendu anticrénelage utilisant des pixels semi-transparents tout autour...). Mais là on entre dans la mécanique et les performances du moteur de rendu vectoriel (ils sont aujourd'hui excellent pour le rendu SVG et profitent des accélérations matérielles des cartes graphiques actuelles pour ne pas avoir à utiliser les anciennes techniques plus lentes et plus couteuses en temps de calcul, de type FSAA ; tout bon rendu travaille aujourd'hui dans un colorspace de type RGBA et non plus RGB, même si l'image produite en final est de type RGB seulement). [/note] Donc en France on peut tout à fait utiliser un rendu plus habituel à ce qu'on trouve habituellement. Mais Google Maps lui ne le fait pas (en revanche son schéma de couleurs est plus lisible et permet plus facilement de positionner des bulles bien lisibles pour les POIs métiers, car les couleurs de fond sont nettement plus pâles), et les libellés affichés en couleurs foncées sont alors aussi plus lisibles. On a de quoi s'en inspirer (sans chercher à copier le style, même si on est habitué en France au style Michelin) en évitant justement de tracer des traits noirs ou trop foncés un peu partout, et en éclaircissant nettement le rendu des bâtiments notamment en zone urbaine dense où les couleurs actuelles rendent les nombreux POIs et libellés peu lisibles. Le 20 avril 2013 13:46, Christian Quest cqu...@openstreetmap.fr a écrit : J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour permettre d'identifier le rendu FR comme provenant d'OSM. J'ai déjà modifié la couleur verte des trunks pour qu'elles soient plus contrastées sur les landuse de couleur proche mais ça peut sûrement encore s'affiner sans changer complètement le jeu de couleur. Le 20 avril 2013 12:47, Pierre-Alain Dorange pdora...@mac.com a écrit : Je suis géné depuis longtemps par les couleurs utilisées par le rendu par défaut de osm.org (mapnik) notamment concernant les routes et plus particulièrements les highway qi sont rendus en vert... Ce qui ce confond très largement avec les forêts et autres champs. Rendant la lisibilité de ces axes importants plus faible que les routes secondaires... D'autres rendus, comme OpenMapQuest utilisent des jeux de couleurs différents qui permettent de bien rendre lisible tout les axes (en même temps heureusement car c'est un rendu orienté routes). Mapnik est bien sur un rendu généraliste qui sert de base, et qui doit essayé de tout rendre au mieux (pas simple), mais je trouve vraiment dommageable ce manque flagrant de lisibilité pour les axes xxx qui sont quand même très important et structurant. Comme la communauté française dispose désormais d'une base d'expérimentation (merci Christian), je proposerai (à discuter bien sur) d'utiliser d'autres jeux de couleurs et d'expérimenter, par exemple : motorway : Bleu foncé/violet trunk : Bleu primary, primary_link : Rouge secondary, secondary_link : Orange tertiary, tertiary_link : Jaune unclassified, residential, road : Blanc living_street, pedestrian : Gris clair service : track, path : pointillé noir ? J'y connais rien en rendu mais le plus souvent les axes autoroutes et routes pour automobile sont rendus avec un style différent : couleur interne et bordure d'une autre couleur et épaisse. C'est la cas de openmapquest, Michelin, IGN... Je sais pas si c'est possible mais c'est une piste à explorer pour rentrer dans les standards... Pour illustrer voici une image du même endroit avec plusieurs rendus (dont des rendus commerciaux) : https://dl.dropboxusercontent.com/u/722984/osm-couleurs.pdf -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr
Re: [OSM-talk-fr] Cartopartie au cimetière du Père-Lachaise
Tout à fait approprié, pourtant sa tombe est une des plus visitées (ce qui apporte aussi des subsides pour l'entretien du reste du cimetière) et les plus abondamment et fréquemment fleuries. Il faut dire aussi qu'elle est superbe par la gravure et sa représentation immortelle. Il n'y en a pas autant pour la tombe d'André Citroen (je ne sais même pas où elle est, peu importe), ni celle de Christian Dior pourtant mort très récemment, ou encore celle de François Mitterrand ou Charles de Gaulle, hormi à certaines dates de cérémonies officielles. Mais en fin de compte est-ce si important ? Les morts ont droit aussi à leur intimité et celle de leur famille qui apportent des embellissements simples mais bien plus importants que ceux apportés par des fans aussi nombreux soient-ils : comment une famille pourrait identifier son propre apport modeste ou se recueillir face à des nuées de fans toute l'année sur la tombe de leur défunt? Dalida n'a cependant pas laissé de famille hors de son frère qui gère la marque Dalida et ne s'est pas beaucoup occupé d'elle de son vivant. La beauté d'un cimetière c'est celle des ornements simples de sépultures très différentes. Elle est moins dans les monuments funéraires que dans les petits apports minimes qui témoignent qu'on a aimé ces personnes, et dans le recueillement des gens les plus simples qu'on ne doit pas déranger dans leur hommage et leur souvenir, et même s'ils n'apportent rien (leur seule présence suffit). Ceux qui ont perdu un être cher, un parent, un enfant, le savent, respectent ces lieux et ceux qui viennent s'y recueillir même sur les tombes les plus simples ou devant une simple plaque au pied d'un carré de pelouse où on a dispersé les cendres. 2013/4/20 Christian Quest cqu...@openstreetmap.fr Ci-git Dalida©®™ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Compte bloqué : je fais quoi ?
Bonjour, Je ne peux toujours pas uploader des modifications : création de changeset impossible sur mon compte, modification impossible des informations sur ma page user... J'ai déjà ré-ouvert deux fois le ticket 4540 : https://trac.openstreetmap.org/ticket/4540 Contrairement à ce que dit TomH : I think the problem is most likely just that the data you uploaded from data2upload.osm is large, and touches a number of very large and complicated relations, so processing it will take some time and your user record is likely to be locked during that processing. You should really wait for a changeset upload to complete before trying to do any more edits, or at least before trying to do any more uploads. In any case this is not related (and never really was) to this ticket, so we should stop reopening this ticket now. je suis convaincu que ça n'est pas une question de taille de changeset : il n'y a même pas eu de création de changeset par JOSM aujourd'hui. Et sa réponse fait un peu fin de non recevoir ! You should really wait for a changeset upload to complete J'aimerai bien ! Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un moment que ça dure ! Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ? -- FrViPofm ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Compte bloqué : je fais quoi ?
Tom a un surnom de M. Wontfix sur certains tickets à cause de sa propension à les fermer plus vite que son ombre, souvent sans chercher à comprendre. Je pense que ce qui le gêne dans l'histoire, c'est que malgré les symptômes identiques au problèmes de Christian, il ne s'agit pas en amont du même problème. Essaye de créer un nouveau ticket en restant le plus courtois possible, on verra bien sa réaction... Le 20 avril 2013 16:05, Vincent Pottier vpott...@gmail.com a écrit : Bonjour, Je ne peux toujours pas uploader des modifications : création de changeset impossible sur mon compte, modification impossible des informations sur ma page user... J'ai déjà ré-ouvert deux fois le ticket 4540 : https://trac.openstreetmap.**org/ticket/4540https://trac.openstreetmap.org/ticket/4540 Contrairement à ce que dit TomH : I think the problem is most likely just that the data you uploaded from data2upload.osm is large, and touches a number of very large and complicated relations, so processing it will take some time and your user record is likely to be locked during that processing. You should really wait for a changeset upload to complete before trying to do any more edits, or at least before trying to do any more uploads. In any case this is not related (and never really was) to this ticket, so we should stop reopening this ticket now. je suis convaincu que ça n'est pas une question de taille de changeset : il n'y a même pas eu de création de changeset par JOSM aujourd'hui. Et sa réponse fait un peu fin de non recevoir ! You should really wait for a changeset upload to complete J'aimerai bien ! Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un moment que ça dure ! Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ? -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Compte bloqué : je fais quoi ?
J'ai eu le problème temporairement, il s'est passé tout seul au redémarrage du serveur. Mais le problème peut arriver même sur un changeset très petit. Pour une raison inconnue, le serveur cesse de répondre à la requête et tue la session alors que du côté SQL la transaction n'est pas annulée ni revertée. On se retrouve alors avec un changeset vide toujours ouvert, et bloquant tout le reste. Une solution peut être de tenter de chercher les changesets encore ouverts (même s'ils sont vides) pour les fermer avant de reprendre. Et j'évite bien des problèmes en n'envoyant pas des lots de données trop gros (j'envoie 5 objets maxi par requête, et autant de requêtes si nécessaire dans le changeset. Cela évite bien des ruptures de session, le serveur répond correctement. Je voudrais bien mettre plus que 5 objets mais JOSM actuellement ne permet pas de distinguer entre un envoi de neuds (on peut les envoyer par paquet de 200 environs), et un envoi de chemins ou relations (en comptant le nombre de leurs membres). Mais avec le réglage à 5 objets maxi par requête, j'ai de bonnes performances globales, pas réellement pires que si j'en envoyais plus, et le serveur traite ces requêtes plus petites bien plus facilement et plus vite, donc j'ai moins de chance de perdre la session... mais ça arrive parfois quand même). Si j'ai une rupture de session c'est aussi plus facile de corriger ce qu'il y a ou pas dans la base (sinon on risque de renvoyer plein de doublons et de laisser des centaines de noeuds orphelins, inutilisés ensuite par les chemins ou relations). Le 20 avril 2013 16:05, Vincent Pottier vpott...@gmail.com a écrit : Bonjour, Je ne peux toujours pas uploader des modifications : création de changeset impossible sur mon compte, modification impossible des informations sur ma page user... J'ai déjà ré-ouvert deux fois le ticket 4540 : https://trac.openstreetmap.**org/ticket/4540https://trac.openstreetmap.org/ticket/4540 Contrairement à ce que dit TomH : I think the problem is most likely just that the data you uploaded from data2upload.osm is large, and touches a number of very large and complicated relations, so processing it will take some time and your user record is likely to be locked during that processing. You should really wait for a changeset upload to complete before trying to do any more edits, or at least before trying to do any more uploads. In any case this is not related (and never really was) to this ticket, so we should stop reopening this ticket now. je suis convaincu que ça n'est pas une question de taille de changeset : il n'y a même pas eu de création de changeset par JOSM aujourd'hui. Et sa réponse fait un peu fin de non recevoir ! You should really wait for a changeset upload to complete J'aimerai bien ! Je ne voudrais pas le froisser, mais c'est frustrant et ça fait un moment que ça dure ! Je ré-ouvre le ticket ? J'en crée un autre ? J'arrête de contribuer à OSM ? -- FrViPofm __**_ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.**org/listinfo/talk-frhttp://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] Rendu OSM-FR : couleurs highway
Christian Quest cqu...@openstreetmap.fr wrote: J'ai fait le choix de ne pas trop m'écarter du style OSM actuel pour permettre d'identifier le rendu FR comme provenant d'OSM. J'ai déjà modifié la couleur verte des trunks pour qu'elles soient plus contrastées sur les landuse de couleur proche mais ça peut sûrement encore s'affiner sans changer complètement le jeu de couleur. Je comprend, mais a mon avis, les trunks ne sont toujours pas du tout assez visible... Ils disparaissent litéralement, tout les autres axes routiers sont beaucoup plus visible, c'est un soucis de hiérarchisation amha. Sur l'exemple cité, on voit bien que la structure routière la ville de Saintes forme un arc sud clair, sur toutes les cartes... Sauf celle d'OSM ou il manque un bout qui est un trunk. Je dois être daltonien et le seul que cela gène... j'avais fait un rapport il y a 3 ans, sans retour... https://trac.openstreetmap.org/ticket/3038 -- Pierre-Alain Dorange OSM experiences : http://www.leretourdelautruche.com/map/ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Source d'un label
Bonjour, Un label La Seine se ballade en dehors de son lit habituel : http://www.openstreetmap.org/?lat=49.47193lon=1.13228zoom=15layers=M (en plein milieu, à gauche de la rocade) Comment savoir d'où vient ce label ? ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Bonjour, Le 20/04/2013 19:56, Plop76 a écrit : Un label La Seine se ballade en dehors de son lit habituel : http://www.openstreetmap.org/?lat=49.47193lon=1.13228zoom=15layers=M (en plein milieu, à gauche de la rocade) Comment savoir d'où vient ce label ? un waterway=riverbank mal fermé ? Le rendu n'étant pas un bon indice, voir dans JOSM pour avoir une idée plus précise. -- Jean-Francois Nifenecker, Bordeaux ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Rien dans JOSM bien sûr à cet emplacement... ça serait beaucoup trop facile ;) J'ai retrouvé l'objet à l'origine de ce libellé en bricolant le rendu FR. Ces libellés pas trop contrôlés proviennent souvent du layer area-text du projet tilemill, donc je passe la couleur de texte en rouge sur ce layer pour avoir confirmation, puis au lieu d'afficher le name, j'affiche l'id de l'objet OSM et là j'ai un beau -13820 en rouge. Il s'agit donc de la relation 13820: http://www.openstreetmap.org/browse/relation/13820 C'est un multipolygone de la boucle de la Seine qui traverse Rouen plus au sud... allez savoir comment postgis/mapnik arrivent à mettre le libellé à cet endroit ! Y'a un bug quelque part, c'est sûr pour ce qui est de la position du libellé. Pas contre, le rendu affiche ce libellé indésirable car ce multipolygone est taggué en natural=water + water=river, alors que d'habitude on a un waterway=riverbank. Il y a 33 multipolygones de ce type sur un extrait France. J'ai modifié le rendu FR pour qu'il tienne compte des natural=water + water=river de la même façon que pour les waterway=riverbank (pour la prochaine mise à jour des tuiles). -- Christian Quest - OpenStreetMap France Synthèse du Week-end SOTM-FR à Lyon : http://openstreetmap.fr/shttp://openstreetmap.fr/sotmfr2013ynthese-sotmfr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Source d'un label
Dans son message précédent, Christian Quest a écrit : Ces libellés pas trop contrôlés proviennent souvent du layer area-text du projet tilemill, donc je passe la couleur de texte en rouge sur ce layer pour avoir confirmation, puis au lieu d'afficher le name, j'affiche l'id de l'objet OSM et là j'ai un beau -13820 en rouge. Il s'agit donc de la relation 13820: http://www.openstreetmap.org/browse/relation/13820 J'avais bien trouvé plusieurs waterway=riverbank non fermés avec La Seine comme nom et j'étais sceptique sur leur culpabilité, mais la relation 13820 n'était pas du tout un suspect à mes yeux :) Pas contre, le rendu affiche ce libellé indésirable car ce multipolygone est taggué en natural=water + water=river, alors que d'habitude on a un waterway=riverbank. Il y a 33 multipolygones de ce type sur un extrait France. Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à utiliser le New tagging du wiki riverbank et à retirer le waterway=riverbank quand une partie n'est pas un vrai riverbank... Merci. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Le samedi 20 avril 2013 02:24:56 PhQ a écrit : Suite au redémarrage du service, j'ai le plaisir, l'honneur et l'avantage de vous signaler la fin de l'import du bâti du PDD (63) . A nous le plaisir des mis à jour et suivi :) Heu, il semble en manquer encore un peu. Par exemple sur la commune d'Aydat, je n'avais importé que les villages d'Aydat et de Verneuge : http://tile.openstreetmap.fr/?zoom=14lat=45.66364lon=3.00299layers=B0F Ce qui est sûr c'est qu'il y a déjà pas mal de boulot en mise à jour depuis les premiers imports de 2-3 ans ! -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit : Bonsoir, Bonne nouvelle : cadastre refonctionne ! Un changement de plate-forme d'hébergement ayant eu lieu, vous pouvez rencontrer un problème d'accès, le temps que les DNS se mettent à jour (mais chez moi, ça fonctionne déjà). Youpi, merci ! Par contre, on n'avait pas dit qu'on ne donnait plus les *-water ? D'ailleurs, histoire de gagner en stockage, les *-houses.osm sont superflus vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien. Merci encore -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Pour les --water, il me semblait que ça avait été coupé parce que certains ne savaient pas les utiliser correctement et qu'il y avait de l'import foireux (appelons un chat un chat). Pour les--houses, je trouve que c'est pratique de les garder à part : perso, il m'arrive de ne vouloir que ça, pour vérifier/compléter le bâti d'une commune. Télécharger le tar.bz2 compliquerait les choses (c'est pas insurmontable, certes)... Francescu Le 20 avril 2013 23:30, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit : Bonsoir, Bonne nouvelle : cadastre refonctionne ! Un changement de plate-forme d'hébergement ayant eu lieu, vous pouvez rencontrer un problème d'accès, le temps que les DNS se mettent à jour (mais chez moi, ça fonctionne déjà). Youpi, merci ! Par contre, on n'avait pas dit qu'on ne donnait plus les *-water ? D'ailleurs, histoire de gagner en stockage, les *-houses.osm sont superflus vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien. Merci encore -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Idée de projet du mois de Mai (ou plus tard)
Honnêtement je ne sais pas et dans le doute je préfère indiquer chacune des voies au cas par cas. Si les voies à 30 km/h ne sont pas indiqué en tant que tel, elles risquent d'être indiqué automatiquement comme étant à 50 km/h tant que leur limitation réelle ne sera pas explicitement indiquée. Et ça permet d'avoir un visuel sur l'avancement du travail déjà effectué, par exemple sur Narbonne que je suis en train de quadrillé quartier par quartier : http://www.itoworld.com/map/35?lon=2.99667lat=43.18322zoom=14 Le 19 avril 2013 16:34, Tetsuo Shima tets...@gmail.com a écrit : Pour les limitations de vitesse implicites ... on se base sur quoi?! les landuse résidentiel pour définir si la route est en agglomération ou pas? ou faut-il expliciter chaque voie? Parce que la position du panneau fin agglomération début d'agglomeration n'a rien d'implicite elle? Le 19 avril 2013 13:17, Jo. perche...@gmail.com a écrit : Suite à l’intérêt porté sur ce projet j'ai mis à jour la page du projet en déplaçant le rappel du code de la route vers la page maxspeed. J'ai également ajouté deux lien vers des carte ITO et quelques idée de contribution parallèle que l'on peut relevé sur place. http://wiki.openstreetmap.org/wiki/FR:Project_of_the_month/Limitation_de_vitesse http://wiki.openstreetmap.org/wiki/FR:Key:maxspeed Les cartes ITO : http://www.itoworld.com/map/42?lon=2.33948lat=48.76664zoom=8 http://www.itoworld.com/map/35?lon=2.36557lat=48.82856zoom=11 Le 19 avril 2013 13:05, Jo. perche...@gmail.com a écrit : Suggestion : afficher les panneaux de signalisation surcharge la carte quand on visionne de grande zone. Leur affichage est intéressant pour des zone fortement zoomée. Le 19 avril 2013 11:29, kimaidou kimai...@gmail.com a écrit : Tony, les autres Comme j'ai ajouté le support de l'emprise dans le permalink de LizPoi, on peut maintenant se passer des URL de démonstration plus parlante. Par exemple les voies limitées à 30km/h dans le centre d'Orange : http://lizpoi.3liz.com/orange/index.php/lizpoi/map/?tree_id=7selected=390bbox=534076.178002,5486262.102976,536505.442306,5487657.078742zoom=16 Le 19 avril 2013 10:47, Jo. perche...@gmail.com a écrit : Même les gabarits… cool moi qui roule souvent en PL j'apprécie beaucoup ce genre d'information. 2013/4/18 Tony Emery tony.em...@yahoo.fr Pour info, voilà où nous en sommes à Orange http://lizpoi.3liz.com/orange/index.php/lizpoi/map/?tree_id=7 . Vous pouvez vous balader et voir aussi les limitations de gabarit, etc... -- View this message in context: http://gis.19327.n5.nabble.com/Idee-de-projet-du-mois-de-Mai-ou-plus-tard-tp5757552p5757620.html Sent from the France mailing list archive at Nabble.com. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] http://cadastre.openstreetmap.fr/
Pour les imports de --water je confirme pour y avoir passer de nombreuse heure à les convertir en fossé ou ruisseau intermittent. D'ailleurs comment utiliser ce genre de donnée efficacement ? Le 20 avril 2013 23:35, Francescu GAROBY windu...@gmail.com a écrit : Pour les --water, il me semblait que ça avait été coupé parce que certains ne savaient pas les utiliser correctement et qu'il y avait de l'import foireux (appelons un chat un chat). Pour les--houses, je trouve que c'est pratique de les garder à part : perso, il m'arrive de ne vouloir que ça, pour vérifier/compléter le bâti d'une commune. Télécharger le tar.bz2 compliquerait les choses (c'est pas insurmontable, certes)... Francescu Le 20 avril 2013 23:30, Nicolas Dumoulin nicolas_openstreetmap@dumoulin63.net a écrit : Le vendredi 19 avril 2013 22:26:59 Francescu GAROBY a écrit : Bonsoir, Bonne nouvelle : cadastre refonctionne ! Un changement de plate-forme d'hébergement ayant eu lieu, vous pouvez rencontrer un problème d'accès, le temps que les DNS se mettent à jour (mais chez moi, ça fonctionne déjà). Youpi, merci ! Par contre, on n'avait pas dit qu'on ne donnait plus les *-water ? D'ailleurs, histoire de gagner en stockage, les *-houses.osm sont superflus vu qu'on a l'archive compressée en tar.bz2 … je dis ça, je dis rien. Merci encore -- Nicolas Dumoulin http://wiki.openstreetmap.org/wiki/User:NicolasDumoulin ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr -- Cordialement, Francescu GAROBY ___ 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] Source d'un label
Le 20 avril 2013 22:41, Plop76 vaujani...@free.fr a écrit : Ah, c'est un peu de ma faute donc ;) C'est vrai que lorsque je touche à des waterway=riverbank, que ce soit relation ou polygone, j'ai tendance à utiliser le New tagging du wiki riverbank et à retirer le waterway=riverbank quand une partie n'est pas un vrai riverbank... Pourquoi la boucle Nord de la Sein qui traverse le centre de Royen ne serait pas un vrai riverbank ? En quoi tu veux lui appliquer une autre politique par rapport au bras plus court et plus direct qui passe au Sud ? Même si ce bras sud est canalisé, la bouche nord l'est aussi, la Seine n'a dans cette zone cessé de faire des méandres avec des lits délaissés, puis repris plus tard, et la canalisation a souvent tiré prodit des anciens lits pour les remettre en eau et éviter des méandres qui ne sont pas toujours vidés pour autant (pas comme le Bras de la Vilaine à l'Est de Reine, qui a été comblé et est devenu une avenue, la Vilaine actuelle passant un peu plus au Sud dans la Plaine de Baud, via un bras auparavant plus mineur) ; Il y a plein d'autres exemples où les lits de fleuves et rivières ont été réaménagés, mais le creusement de canaux spécifiques là où il n'y avait jamais eu de bras avant est assez rare, on a très souvent profité des anciens bras morts, tout bonnement car c'était nettement moins coûteux et plus facile à contrôler en cas de crue contre des inondations, les terrains autour du bras mort formant déjà une cuvette limitant l'impact d'un débordement. C'est dans le cas où il n'y a pas de restes de bras mort qu'on creuse un canal de zéro mais ça coûte cher et cela crée des risques (et pour les limiter on garde le lit naturel encore en eau même si le lit naturel devient un bras mineur en terme de débit (ce ne sera pas un lit mineur en cas de crue). J'ai peut qu'on se retrouve aussi dana la base avec des (multi)polygones natural=water et pas seulement water=river mais aussi avec water=stream, water=canal; water=delta, water=mouth, water=canalized_river, water=waterfall, et d'autres qui n'apparaissent pas encore ou que j'aurais oubliés (pour le drainage ou l'irrigation ou des lits formés par l'assèchement et la surélévation de terrains dans des marais), là où avant on avait un unique waterway=riverbank pour tous les lits secondaires (qui forment souvent un fin maillage dans les zones de marais ou les deltas, sans que tous les bras ne prennent un nom spécifique, et sans forcément un sens unique de circulation naturelle de l'eau) == Dans ce cas il faudrait traiter tous les polygones naturel=water+water=* comme équivalents aux waterway=riverbank (ce qui inclut alors aussi les bassins et étangs de rétention ou de débordement, en marge des fleuves et rivières, et les biefs qui les alimentent ou les vident, la valeur donnée à water)* étant un détail de spécilaistes, assez difficile en fait à évaluer et différencier. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-ja] OSMタイル配信サーバ開発の実施状況共有（WAS: （開発者募集）OSMタイル配信サーバの開発）
三浦です。
OSMタイル配信サーバの開発状況について共有します。
説明しきれていないことも多数有ると思うので、
質問くださいませ。
開発参加情報
===
１．開発環境前提
Ubuntu Linux 12.04(LTS) 64bit環境です。
2. ソースコード、依存ライブラリ、パッケージ等の入手
タイルキャッシュサーバおよびタイル画像レンダリングサーバ コード
https://github.com/osmfj/tilecache
依存ライブラリ、パッケージ等
https://launchpad.net/~miurahr/+archive/openstreetmap
3. 課題管理
https://github.com/osmfj/tilecache/issues?state=open
４．リアルタイム・時間差での議論
Lingrを用いて公開議論しています。
http://lingr.com/signup?letmein=osmfj_devel
開発で更新があったときは、こちらに通知が出るので、
便利です。
マイルストーンについて
===
本開発のマイルストーンについては、課題管理システム上に記録されています。
https://github.com/osmfj/tilecache/issues/milestones
Ver 0.8 タイルキャッシュ機能の実現
Ver 0.9 タイル置き換え機能の実現
Ver 1.0 独自タイル配信機能の実現
進捗状況について
=
Ver0.8のパラメータ・チューニング法の確立とドキュメントができていませんが機能は実現されています。
Ver0.9の目標は実現されました。
Ver1.0の目標では、タイルのexpire法と独自スタイル設定方法の確立がされていません。
１．タイルキャッシュサーバの実現
*.tile.openstreetmap.org での配信は、実はグローバルに分散されて
配信されています。
この一員に参加できるようなタイルキャッシュサーバについて実現しています。
a.tile.openstreetmap.jp/{z}/{x}/{y}.png にアクセスすると、本機能により
タイル配信されます。
キャッシュサーバのリソースは、GMOグループから提供されているVPSサーバを
利用させていただいています。
2. 独自タイルの置き換え機能の実現
一部のタイルについて、サーバ上に配置した静的なpngファイルに置き換えることができるように
なります。システム要件で、特定の地域の地図について、OSMのタイル画像を使用したくないケースで
有効です。
地方自治体や中央省庁等の利用する地理情報システムでは、
竹島、北方四島、国境線、県境等について、国や自治体が定める表記になっていないと
問題があるかもしれません。
とはいえ、独自にレンダリングサーバを設置する必要のない場合も有るでしょう。
（商用利用の場合は、レンダリングサーバを設置することを推奨します）
その場合に、センシティブなタイルについてのみ、置き換えられるような仕組みを提供します。
本プロジェクトでは、サンプルタイルとして竹島周辺のタイルを同梱し、動作確認できるように
しています。
この機能は、（１）のキャッシュに優先して働き、置き換えのない場合は（１）のキャッシュサーバとして
動作します。
http://www.osm.jp/ の地図は、（１）（２）の機能で実現しています。
3. タイルレンダリング機能の実現
OpenStreetMap.orgの地図は、 apache httpサーバに mod_tileというエンジン＋Tirexで
実現されています。
今回、nginxに LUA言語によるスクリプト+Tirexで同様の機能を実現しています。
現在、海岸線だけのzoom 4までのサンプルデータを元に、
http://j.openstreetmap.jp/{z}/{x}/{y}.png でアクセスすると、
本機能でのレンダリングが確認できるところまで進んでいます。
例えば、 http://j.openstreetmap.jp/0/0/0.png
４．ドキュメント
利用者向けのドキュメントは、
https://github.com/osmfj/tilecache/wiki
に整備していきたいと考えていますが、現在は未整備です。
貢献者を募集します。
インストール方法などREAME やINSTALL ファイル や
https://github.com/osmfj/tilecache/tree/master/doc
同梱のドキュメントに記載しています。
一部、開発に追随できていないものも有るかもしれません。
日本語しか無いもの、英語しか無いものもあります。英訳和訳の翻訳者歓迎。
タイルキャッシュサーバの説明
https://github.com/osmfj/tilecache/blob/master/doc
/howto_make_tilecache_server.md
静的タイル置き換えの説明
https://github.com/osmfj/tilecache/blob/master/doc /statictile.ja.txt
開発者向けのノート
https://github.com/osmfj/tilecache/blob/master/doc /DEVELOPMENT.ja.md
５．独自スタイル
スタイルの開発は未着手です。一部、アイコンの整備やスタイルの検討が
されていますが、本開発との統合はまだです。
開発参加者を募集しています。
スタイル開発のベースとして、github.comにリポジトリをジュンビシました。
https://github.com/osmfj/mapnik-stylesheets
これは、現在は OpenStreetMap.orgのリポジトリのコピーになっています。
以上
三浦
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSMタイル配信サーバ開発の実施状況共有（WAS: （開発者募集）OSMタイル配信サーバの開発）
三浦様
ありがとうございます。
分からない事など質問させて頂きます。
今後ともよろしくお願いいたします。
iPhoneから送信
H.25/04/20 21:55、Hiroshi Miura(@osmf) miur...@osmf.jp のメッセージ:
三浦です。
OSMタイル配信サーバの開発状況について共有します。
説明しきれていないことも多数有ると思うので、
質問くださいませ。
開発参加情報
===
１．開発環境前提
Ubuntu Linux 12.04(LTS) 64bit環境です。
2. ソースコード、依存ライブラリ、パッケージ等の入手
タイルキャッシュサーバおよびタイル画像レンダリングサーバ コード
https://github.com/osmfj/tilecache
依存ライブラリ、パッケージ等
https://launchpad.net/~miurahr/+archive/openstreetmap
3. 課題管理
https://github.com/osmfj/tilecache/issues?state=open
４．リアルタイム・時間差での議論
Lingrを用いて公開議論しています。
http://lingr.com/signup?letmein=osmfj_devel
開発で更新があったときは、こちらに通知が出るので、
便利です。
マイルストーンについて
===
本開発のマイルストーンについては、課題管理システム上に記録されています。
https://github.com/osmfj/tilecache/issues/milestones
Ver 0.8 タイルキャッシュ機能の実現
Ver 0.9 タイル置き換え機能の実現
Ver 1.0 独自タイル配信機能の実現
進捗状況について
=
Ver0.8のパラメータ・チューニング法の確立とドキュメントができていませんが機能は実現されています。
Ver0.9の目標は実現されました。
Ver1.0の目標では、タイルのexpire法と独自スタイル設定方法の確立がされていません。
１．タイルキャッシュサーバの実現
*.tile.openstreetmap.org での配信は、実はグローバルに分散されて
配信されています。
この一員に参加できるようなタイルキャッシュサーバについて実現しています。
a.tile.openstreetmap.jp/{z}/{x}/{y}.png にアクセスすると、本機能により
タイル配信されます。
キャッシュサーバのリソースは、GMOグループから提供されているVPSサーバを
利用させていただいています。
2. 独自タイルの置き換え機能の実現
一部のタイルについて、サーバ上に配置した静的なpngファイルに置き換えることができるように
なります。システム要件で、特定の地域の地図について、OSMのタイル画像を使用したくないケースで
有効です。
地方自治体や中央省庁等の利用する地理情報システムでは、
竹島、北方四島、国境線、県境等について、国や自治体が定める表記になっていないと
問題があるかもしれません。
とはいえ、独自にレンダリングサーバを設置する必要のない場合も有るでしょう。
（商用利用の場合は、レンダリングサーバを設置することを推奨します）
その場合に、センシティブなタイルについてのみ、置き換えられるような仕組みを提供します。
本プロジェクトでは、サンプルタイルとして竹島周辺のタイルを同梱し、動作確認できるように
しています。
この機能は、（１）のキャッシュに優先して働き、置き換えのない場合は（１）のキャッシュサーバとして
動作します。
http://www.osm.jp/ の地図は、（１）（２）の機能で実現しています。
3. タイルレンダリング機能の実現
OpenStreetMap.orgの地図は、 apache httpサーバに mod_tileというエンジン＋Tirexで
実現されています。
今回、nginxに LUA言語によるスクリプト+Tirexで同様の機能を実現しています。
現在、海岸線だけのzoom 4までのサンプルデータを元に、
http://j.openstreetmap.jp/{z}/{x}/{y}.png でアクセスすると、
本機能でのレンダリングが確認できるところまで進んでいます。
例えば、 http://j.openstreetmap.jp/0/0/0.png
４．ドキュメント
利用者向けのドキュメントは、
https://github.com/osmfj/tilecache/wiki
に整備していきたいと考えていますが、現在は未整備です。
貢献者を募集します。
インストール方法などREAME やINSTALL ファイル や
https://github.com/osmfj/tilecache/tree/master/doc
同梱のドキュメントに記載しています。
一部、開発に追随できていないものも有るかもしれません。
日本語しか無いもの、英語しか無いものもあります。英訳和訳の翻訳者歓迎。
タイルキャッシュサーバの説明
https://github.com/osmfj/tilecache/blob/master/doc
/howto_make_tilecache_server.md
静的タイル置き換えの説明
https://github.com/osmfj/tilecache/blob/master/doc /statictile.ja.txt
開発者向けのノート
https://github.com/osmfj/tilecache/blob/master/doc /DEVELOPMENT.ja.md
５．独自スタイル
スタイルの開発は未着手です。一部、アイコンの整備やスタイルの検討が
されていますが、本開発との統合はまだです。
開発参加者を募集しています。
スタイル開発のベースとして、github.comにリポジトリをジュンビシました。
https://github.com/osmfj/mapnik-stylesheets
これは、現在は OpenStreetMap.orgのリポジトリのコピーになっています。
以上
三浦
___
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] OSMタイル配信サーバ開発の実施状況共有（WAS: （開発者募集）OSMタイル配信サーバの開発）
いくつか書き忘れました。 現在、1.0 Beta１リリースしていますが、まもなく1.0 Beta2リリースかなぁ、と 思っとります。 On 2013年04月20日 21:55, Hiroshi Miura(@osmf) wrote: 三浦です。 OSMタイル配信サーバの開発状況について共有します。 説明しきれていないことも多数有ると思うので、 質問くださいませ。 ０．謝辞 GMOインターネットさんには、検証環境となるVPSを提供いただいています。 関さんには、開発環境の自動構築ツールの整備やドキュメント整備をいただきました 藤澤さんには、タイルデータ提供や不具合の指摘をいただきました。 興味を持っていただいた皆さん、ご指摘いただいた皆さん、ありがとうございます。 １．性能 今回、Nginxをhttpサーバおよびキャッシュサーバとして選択したことで、 性能的に優位になっていると思っています。 どなたか、 Apache http サーバ + mod_tile + Tirex(example map)と 本成果とのベンチーマーク比較に興味ありませんか？ また、今後、 OSGeo-japanや グローバルのosm-dev MLにアナウンスして いきたいと思います。 2. Planet.osmデータのPostGISへのインポートや日次のアップデート ２．１ スクリプト https://github.com/osmfj/tilecache/tree/master/updatedb このへんにスクリプトを整理しています ２．２ インポートした結果古くなったタイル画像の消去 https://github.com/osmfj/tilecache/tree/master/render_expire こちらのツールが使えるようにしています。 mod_tileから、最小限だけ抽出したです。 動作は未確認。 ２．３ 静的置き換えデータ サンプル https://github.com/osmfj/tilecache/tree/master/data 3．プラットホーム 今回、Ubuntu/Debian系のみ前提として環境構築手順や 動作検証しています。その他の環境に興味のある方の参加も Welcomeです。依存するライブラリなどのYUMリポジトリ整備など 有益ではないかと思います。 4．ドキュメント系ボランティア募集 本ポストを参考に、Wikiにまとめを作ってくれると嬉しっす。 本開発の参考文献の日本語を作ったり、更新したりすると 嬉しがる人が沢山いると思います。 5．その他参考文献、リソース等 OSMのWiki関係 https://wiki.openstreetmap.org/wiki/Tirex http://wiki.openstreetmap.org/wiki/Mod_tile http://wiki.openstreetmap.org/wiki/Mapnik http://wiki.openstreetmap.org/wiki/Osm2pgsql http://wiki.openstreetmap.org/wiki/Osmosis Nginx関係 http://blog.cloudflare.com/pushing-nginx-to-its-limit-with-lua http://wiki.nginx.org/Main http://openresty.org/download/agentzh-nginx-tutorials-en.html LUA言語 http://www.lua.org/ 各種ライブラリ https://github.com/chaoslawful/lua-nginx-module http://ndevilla.free.fr/iniparser/ http://bitop.luajit.org/ http://lua-users.org/wiki/BitwiseOperators Redis関係 http://redis.io/ https://github.com/agentzh/lua-resty-redis http://redis.io/topics/replication http://d.hatena.ne.jp/hiroe_orz17/20111003/1317621057 インポート関係 http://imposm.org/docs/imposm/latest/ 本開発をインスパイアしたプロジェクト Node.jsでのタイルサーバ実装 http://blog.jochentopf.com/2011-03-03-a-nodejs-tileserver-for-tirex.html https://trac.openstreetmap.org/browser/applications/utils/tirex/tileserver/tileserver.js?desc=1 以上 もっと有るかもしれないが。。。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSMタイル配信サーバ開発の実施状況共有
Akamaさん、反応あると嬉しいですね。 On 2013年04月20日 22:38, Syuukou Akama wrote: 三浦様 ありがとうございます。 分からない事など質問させて頂きます。 今後ともよろしくお願いいたします。 H.25/04/20 21:55、Hiroshi Miura(@osmf) miur...@osmf.jp のメッセージ: OSMタイル配信サーバの開発状況について共有します。 説明しきれていないことも多数有ると思うので、 質問くださいませ。 みなさんも、それぞれの角度から、調べたり実験したりしていると思います。 わかったこと、わからないことなど、共有いただけると、いいなぁ、と思います。 三浦 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] OSMタイル配信サーバ開発の実施状況共有
ありがとうございます。 今後一生懸命勉強して行きたいと思います。 iPhoneから送信 H.25/04/20 22:58、Hiroshi Miura(@osmf) miur...@osmf.jp のメッセージ: Akamaさん、反応あると嬉しいですね。 On 2013年04月20日 22:38, Syuukou Akama wrote: 三浦様 ありがとうございます。 分からない事など質問させて頂きます。 今後ともよろしくお願いいたします。 H.25/04/20 21:55、Hiroshi Miura(@osmf) miur...@osmf.jp のメッセージ: OSMタイル配信サーバの開発状況について共有します。 説明しきれていないことも多数有ると思うので、 質問くださいませ。 みなさんも、それぞれの角度から、調べたり実験したりしていると思います。 わかったこと、わからないことなど、共有いただけると、いいなぁ、と思います。 三浦 ___ 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: [Talk-GB] NCN 28?
On 20/04/2013 13:58, Kevin Peat wrote: I am not that familiar with NCN signage. Why are the route numbers sometimes shown in brackets and sometimes not? Just as with ordinary road signs in the UK, the number in brackets means this is the way to route N rather than being route N itself. David ___ Talk-GB mailing list Talk-GB@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-gb
[Talk-us] Whole-US Garmin Map update - 2013-04-18
These are based off of Lambertus's work here: http://garmin.openstreetmap.nl If you have questions or comments about these maps, please feel free to ask. However, please do not send me private mail. The odds are, someone else will have the same questions, and by asking on the talk-us@ list, others can benefit. Downloads: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-04-18 Map to visualize what each file contains: http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-04-18/kml/kml.html FAQ Why did you do this? I wrote scripts to joined them myself to lessen the impact of doing a large join on Lambertus's server. I've also cut them in large longitude swaths that should fit conveniently on removable media. http://daveh.dev.openstreetmap.org/garmin/Lambertus/2013-04-18 Can or should I seed the torrents? Yes!! If you use the .torrent files, please seed. That web server is in the UK, and it helps to have some peers on this side of the Atlantic. Why is my map missing small rectangular areas? There have been some missing tiles from Lambertus's map (the red rectangles), I don't see any at the moment, so you may want to update if you had issues with the last set. Why can I not copy the large files to my new SD card? If you buy a new card (especially SDHC), some are FAT16 from the factory. I had to reformat it to let me create a 2GB file. Does your map cover Mexico/Canada? Yes!! I have, for the purposes of this map, annexed Ontario in to the USA. Some areas of North America that are close to the US also just happen to get pulled in to these maps. This might not happen forever, and if you would like your non-US area to get included, let me know. -- Dave ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Proposed small import of UTA bus stops
Hi all, During the edit-a-thon today I finally got around to working on preparing a relatively small import of bus stop point data for the UTA service area (comprising a half dozen counties along the Utah Wasatch Front). There are ~6450 bus stops in the data I got from my contact at UTA. This data is being released to the public through the Utah GIS data portal [1], but the data I got directly from UTA is more recent (Dec 2012). Data processing consisted of removing empty and irrelevant fields, and sanitizing the fields that are relevant. I kept: COUNTY -- is_in:county CITY -- is_in:city ACCESS -- wheelchair = yes|limited|no BENCH -- bench = yes|no LOCATIONID -- uta:stop_id I checked the existing bus stop data and there are 92 existing nodes. I have saved these as an OSM file and intend to manually conflate these after the fact. This will mean most existing bus stop nodes will be removed, I spot checked a dozen and so far did not find a any added value. There are a few non-UTA stops (Airport parking lot shuttle stops etc) that will be retained. The source data I received can be found here: https://www.dropbox.com/s/tyxdhf9hlpuc9z8/BusStops_UTA_shp.zip The processed data can be found in OSM XML format here: https://www.dropbox.com/s/v3c0tsgfhlc6izx/busstops_uta.osm Future updates will be handled using the persistent uta:stop_id. A new stops file is released around once a year. Light rail stops are captured in a separate dataset that I do not intend to import, as these stops and stations are mostly already captured in greater detail in OSM. I am running this by all of you because I have not really done any external data imports before. This is a relatively small one, but I would like your opinion on the following: * Is this data import properly prepared? * If not, which steps should I revisit / add and how? * Do you recommend using a separate account for uploading the external data? Looking forward to your feedback. Martijn [1] http://gis.utah.gov/data/sgid-transportation/transit/ -- Martijn van Exel ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
