Re: [OSM-talk] Lost tags
On Sun, Jul 29, 2012 at 4:37 AM, Frederik Ramm frede...@remote.org wrote: Hi, On Sat, 28 Jul 2012 23:39:56 +0530 Arun Ganesh arun.plane...@gmail.com wrote: It is quite painful to see that countless hours of effort has been deleted for no fault of my own. Is this just the result of the osm data model where tags cannot exist without geometries, or were these tags considered as being dirty and were legally supposed to be erased? I think the former is correct. This is good news for a start. We essentially have a UI problem, and if solved, will help getting back the most useful bits of the lost data back into osm. If you go through the history planet file and create a list that goes: somewhere in the world there is a way that has the properties name=Bingbong Street, maxspeed=30 (provided that both these properties were added by agreers) then it would be ok to publish that list and even use it to add to OSM. I don't see how it can be much help though, especially if it contains info like somewhere in the world there is an object with wheelchair=yes and opening_times=so-and-so ;) The most easily identifiable data that I see are those that have name tags. What if you have a list view alongside a map, which is populated based on your current view and zoom level? For ways, this can have additional information like the length of the way and orientation to assist mappers who lost their tags to identify where the original way was. For POIs, you could have the name of the street beside which it was located and also distance and orientation from the nearest place=* node There are probably better ideas, but its an absolute shame that clean and extremely valuable data is lost because the data model does not support its existence. Bye Frederik -- j.mp/ArunGanesh http://j.mp/ArunGanesh ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Lost tags
Am 29.07.2012 08:37, schrieb Arun Ganesh: On Sun, Jul 29, 2012 at 4:37 AM, Frederik Ramm frede...@remote.org mailto:frede...@remote.org wrote: Hi, On Sat, 28 Jul 2012 23:39:56 +0530 Arun Ganesh arun.plane...@gmail.com mailto:arun.plane...@gmail.com wrote: It is quite painful to see that countless hours of effort has been deleted for no fault of my own. Is this just the result of the osm data model where tags cannot exist without geometries, or were these tags considered as being dirty and were legally supposed to be erased? I think the former is correct. This is good news for a start. We essentially have a UI problem, and if solved, will help getting back the most useful bits of the lost data back into osm. If you go through the history planet file and create a list that goes: somewhere in the world there is a way that has the properties name=Bingbong Street, maxspeed=30 (provided that both these properties were added by agreers) then it would be ok to publish that list and even use it to add to OSM. I don't see how it can be much help though, especially if it contains info like somewhere in the world there is an object with wheelchair=yes and opening_times=so-and-so ;) The most easily identifiable data that I see are those that have name tags. What if you have a list view alongside a map, which is populated based on your current view and zoom level? Then you use geometry information that's not there any more out of license issues, so there cannot be something like based on your current view, there can only be a list, not ordered by geography, of sets of tags. For ways, this can have additional information like the length of the way and orientation to assist mappers who lost their tags to identify where the original way was. Length of way and orientation are derived from geometry only, and geometry isn't valid in terms of ODBL. For POIs, you could have the name of the street beside which it was located and also distance and orientation from the nearest place=* node and again you need the information of beside and orientation - which consists of coordinates and therefore the geometry information. There are probably better ideas, but its an absolute shame that clean and extremely valuable data is lost because the data model does not support its existence. Probably, if you have a good idea that is useful on the one hand, can be implemented (e.g. by you), and does not require the use of non-odbl-data to be derived, it may be possible to introduce as a new tool; but I don't see a way to do that. regards Peter ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] Proposed mechanical import: Empty relations 1
Now that the redaction bot has finished running, I want to propose what should be a simple uncontroversial mechanical edit (hah). I propose cleaning up two types of empty relations that are not members of other relations. - Those with no members and no tags - Those with no members and type=multipolygon as the only tag Relations removed will be limited to those more than a day old to avoid conflicting with any open changesets. This will not break any relations linked to from the wiki. You'd have to know the ID of them to reference them, and if you know the ID you can retrieve the deleted relation. Technical details are at http://wiki.openstreetmap.org/wiki/Mechanical_Edits/pnorman_imports This would impact 1295 relations, unless you take the view that objects which are identical are the same, in which case it would impact 2. :) ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed mechanical import: Empty relations 1
On 7/29/2012 5:06 AM, Paul Norman wrote: - Those with no members and no tags - Those with no members and type=multipolygon as the only tag Relations removed will be limited to those more than a day old to avoid conflicting with any open changesets. I would suggest a longer time interval, perhaps a week - I have performed multiple edit sessions with periodic uploads with 'dangling empty relations' before they were filled in. (Although they would have had more tags). ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed mechanical import: Empty relations 1
Am Sonntag, den 29.07.2012, 02:06 -0700 schrieb Paul Norman: Now that the redaction bot has finished running, I want to propose what should be a simple uncontroversial mechanical edit (hah). I propose cleaning up two types of empty relations that are not members of other relations. - Those with no members and no tags - Those with no members and type=multipolygon as the only tag What about additionally add last editor=redaction bot? ... then there will be less controversion ;-) Regards werner2101 ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[OSM-talk] New Potlatch feature to aid remapping
Hi all, I've added a small feature to Potlatch 2 which should be generally useful but will particularly help in remapping. When you've selected a way, you can now add intermediate points just by shift-clicking a blank area. P2 will work out where to put the node in the way, and do it. Exactly like shift-clicking the way to insert a node then dragging it, but quicker. (It's a bit like JOSM's ImproveWayAccuracy feature, I think.) You can also incorporate existing nodes by shift-clicking them. This is useful for those times when a bunch of orphan nodes are hanging around, but the way itself has been straightened. cheers Richard ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed mechanical import: Empty relations 1
From: Werner Hoch [mailto:werner...@gmx.de] Sent: Sunday, July 29, 2012 6:33 AM To: Paul Norman Cc: talk@openstreetmap.org Subject: Re: [OSM-talk] Proposed mechanical import: Empty relations 1 Am Sonntag, den 29.07.2012, 02:06 -0700 schrieb Paul Norman: Now that the redaction bot has finished running, I want to propose what should be a simple uncontroversial mechanical edit (hah). I propose cleaning up two types of empty relations that are not members of other relations. - Those with no members and no tags - Those with no members and type=multipolygon as the only tag What about additionally add last editor=redaction bot? ... then there will be less controversion ;-) Regards werner2101 The redaction bot didn't leave behind any relations with no geodata. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
Re: [OSM-talk] Proposed mechanical import: Empty relations 1
From: Mike N [mailto:nice...@att.net] Subject: Re: [OSM-talk] Proposed mechanical import: Empty relations 1 On 7/29/2012 5:06 AM, Paul Norman wrote: - Those with no members and no tags - Those with no members and type=multipolygon as the only tag Relations removed will be limited to those more than a day old to avoid conflicting with any open changesets. I would suggest a longer time interval, perhaps a week - I have performed multiple edit sessions with periodic uploads with 'dangling empty relations' before they were filled in. (Although they would have had more tags). I can't imagine a use for a relation or multipolygon with no geodata and no tag data, even when considering multi-day edit sessions. If someone isn't going to provide some information (at least tags) then why would they make the relation at all? I wouldn't suggest using relations or MPs with no geodata and with tag data over long edit sessions since if you lose your spot and have to redownload from the API you'll of lost the relations unless you remember their IDs. I might propose something at a later data dealing with relations or MPs that have no geodata but have tag data, but that's not the purpose of this edit. Just for reference, there are approximately 5k relations with no geodata. ___ talk mailing list talk@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk
[talk-au] Brisbane bus stop density
I see a cluster of bus stops in an area that looks unusual. Would a Brisbane local have a look when they get a chance? Not an emergency, obviously. They've been there since 2009. http://www.openstreetmap.org/?lat=-27.403455lon=152.943559zoom=18layers=M ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction recovery
FYI, I am working on the Cooks River Cycleway which I mapped over 2005-2006 and can do the M7 cycleway if needed. I've been able to re-create a map of my efforts from a January 2007 planet dump so have 1,000+ streets and paths over NSW and QLD that I can re-map using Bing imagery. Dalby, Port Macquarie, Laurieton and some coastal villages are done. Brisbane and Toowoomba look good so I am now working on Sydney. Mostly this is Ultimo, Pyrmont, CBD, The Rocks, Elizabeth Bay and cycle trips around the eastern suburbs coast down to Cronulla. May I ask armchair mappers if they would not mind mapping in streets as highway=road instead of highway=residential? Otherwise they look done and I miss them. Putting source=Bing also helps me know that you have not ground-surveyed them and that my older data may still be good. Good luck to everyone on the ground with the remapping, alas I no longer live in Australia, Mike Collinson On 27/07/2012 03:57, Ben Kelley wrote: Hi. BTW, in terms of cycle routes in Marrickville I managed to remap some in advance of the redaction, and I know where any missing ones go. There is a page on the wiki for Sydney Cycle Routes (pre redaction). Most of the relations there should still exist, but I haven't had time to check them yet. I wondered about coordinating cycle route remapping. Maybe via the wiki page, and by LGA? For remapping roads, Bing is very good in Sydney, although exercise is also good. :) - Ben. On Jul 26, 2012 6:40 PM, Eric Rose er...@wamble.net mailto:er...@wamble.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/07/12 21:35, Leon Kernan wrote: I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. I'm in Marrickville, but may be able to spend time cycling around and collecting traces in surrounding areas. Given that I haven't been an active mapper for a while, I'll have to re-familiarise myself with the tools again, and work out how to easily convert data from my Edge 800 (FIT format) to GPX. All my previous mapping was done around Mullumbimby, and my primary focus is on recreating data from my old traces in that area. Eric ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction recovery
Keeping all Sydney cycle routes in the wiki is a good idea. Updating them there post-recovery seems reasonable too. Cooks River and Botany Bay I deleted and then remapped red sections prior to the redaction, and surprised how much disappeared regardless. Shouldn't take long to recover those. If there are any Sydney ones that need a survey, I'm happy to go for a pedal and do it. Ian On Jul 27, 2012 11:57 AM, Ben Kelley ben.kel...@gmail.com wrote: Hi. BTW, in terms of cycle routes in Marrickville I managed to remap some in advance of the redaction, and I know where any missing ones go. There is a page on the wiki for Sydney Cycle Routes (pre redaction). Most of the relations there should still exist, but I haven't had time to check them yet. I wondered about coordinating cycle route remapping. Maybe via the wiki page, and by LGA? For remapping roads, Bing is very good in Sydney, although exercise is also good. :) - Ben. On Jul 26, 2012 6:40 PM, Eric Rose er...@wamble.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/07/12 21:35, Leon Kernan wrote: I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. I'm in Marrickville, but may be able to spend time cycling around and collecting traces in surrounding areas. Given that I haven't been an active mapper for a while, I'll have to re-familiarise myself with the tools again, and work out how to easily convert data from my Edge 800 (FIT format) to GPX. All my previous mapping was done around Mullumbimby, and my primary focus is on recreating data from my old traces in that area. Eric - -- Web-footed fascists with manical eyes, Ducks, Ducks, Quack-quack! Quack-quack! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQnrcACgkQ+lmeGwHCyREHMwCfUsE4+0cvBJ2ydRdSU5GyhCZc f0QAn2Vg7nR9g5wGRfH3h9udlP9wQBS4 =LqAX -END PGP SIGNATURE- ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Redaction recovery
Hi. For the moment the cycle map still has the pre redacted data, which will give some tips. Many councils paint bike logos that can be seen in Bing, but not all. Hopefully all the relations linked to from the wiki still exist, but I know some are in bad shape. - Ben. On Jul 30, 2012 7:44 AM, Ian Sergeant inas66+...@gmail.com wrote: Keeping all Sydney cycle routes in the wiki is a good idea. Updating them there post-recovery seems reasonable too. Cooks River and Botany Bay I deleted and then remapped red sections prior to the redaction, and surprised how much disappeared regardless. Shouldn't take long to recover those. If there are any Sydney ones that need a survey, I'm happy to go for a pedal and do it. Ian On Jul 27, 2012 11:57 AM, Ben Kelley ben.kel...@gmail.com wrote: Hi. BTW, in terms of cycle routes in Marrickville I managed to remap some in advance of the redaction, and I know where any missing ones go. There is a page on the wiki for Sydney Cycle Routes (pre redaction). Most of the relations there should still exist, but I haven't had time to check them yet. I wondered about coordinating cycle route remapping. Maybe via the wiki page, and by LGA? For remapping roads, Bing is very good in Sydney, although exercise is also good. :) - Ben. On Jul 26, 2012 6:40 PM, Eric Rose er...@wamble.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 24/07/12 21:35, Leon Kernan wrote: I'm not too familiar with central Sydney but if a local could take a look, i'm not game to get too far into that mess. I'm in Marrickville, but may be able to spend time cycling around and collecting traces in surrounding areas. Given that I haven't been an active mapper for a while, I'll have to re-familiarise myself with the tools again, and work out how to easily convert data from my Edge 800 (FIT format) to GPX. All my previous mapping was done around Mullumbimby, and my primary focus is on recreating data from my old traces in that area. Eric - -- Web-footed fascists with manical eyes, Ducks, Ducks, Quack-quack! Quack-quack! -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAQnrcACgkQ+lmeGwHCyREHMwCfUsE4+0cvBJ2ydRdSU5GyhCZc f0QAn2Vg7nR9g5wGRfH3h9udlP9wQBS4 =LqAX -END PGP SIGNATURE- ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Brisbane bus stop density
Yeah, I'm pretty sure there would only be one bus stop there, or possibly one each side of the road, at best. I'll see if I can swing by that way next time I'm over that side of town, if somebody doesn't beat me to it. I suspect that a few of the other double pairs nearby should only be singles as well - minor suburban streets like that usually only have a one way bus path, if any, but I could be wrong. Particularly since some of the doubles appear to be on the same side of the road - that's very unusual. Stephen On 30 July 2012 00:34, Richard Weait rich...@weait.com wrote: I see a cluster of bus stops in an area that looks unusual. Would a Brisbane local have a look when they get a chance? Not an emergency, obviously. They've been there since 2009. http://www.openstreetmap.org/?lat=-27.403455lon=152.943559zoom=18layers=M ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [talk-au] Brisbane bus stop density
On 07/30/2012 10:59 AM, Stephen Hope wrote: Yeah, I'm pretty sure there would only be one bus stop there, or possibly one each side of the road, at best. I'll see if I can swing by that way next time I'm over that side of town, if somebody doesn't beat me to it. Pulling the data into josm and it looks like we have a massive import by user morb_au http://www.openstreetmap.org/user/morb_au http://www.openstreetmap.org/browse/changeset/755180 ___ Talk-au mailing list Talk-au@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-au
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Moin, Am 28.07.2012 14:31, schrieb Frederik Ramm: Jetzt wieder ok, oder? mir ist gerade aufgefallen, dass einzelne rote ways, die ich heute in den Papierkorb befördert habe, bei zoom 12 wieder auftauchen und bei zoom = 12 wieder verschwinden. Konkrete Beispiele: way 35584172 way 35906819 way 34240188 Ist das so beabsichtigt? Ich kann zwar damit leben, fände es allerdings schöner, auch größere Bereiche überfliegen zu können. Gruß Georg ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Neuer OSMI-Layer fuer Lizenzwechsel-Resultate
Hallo, On 29.07.2012 10:25, Georg Feddern wrote: mir ist gerade aufgefallen, dass einzelne rote ways, die ich heute in den Papierkorb befördert habe, bei zoom 12 wieder auftauchen und bei zoom = 12 wieder verschwinden. Das ist ja grad der Wechsel von Weg-als-Linie zu Weg-nur-mit-Mittelpunkt. Kann sein, dass bei letzterem die geloeschten nicht richtig rausgeworfen werden - sollten sie aber, und das kann ich auf jeden Fall naechruesten. Ich guck es mal an. (Auf der Raster-Overview auf z=9 reagiert noch nicht auf den Muelleimer, aber das hab ich auch auf der Liste.) Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
2012/7/27 Frederik Ramm frede...@remote.org Ich habe auf http://download.geofabrik.de/**osm-before-redaction/http://download.geofabrik.de/osm-before-redaction/ einen Satz Datenauszuege aus der Zeit vor dem Redaction-Bot bereitgestellt. Danke. Von welchem Tag sind die Daten? ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
Re: [Talk-de] Geofabrik-Downloads fuer prae-Bot-Daten
Hi, On 29.07.2012 23:30, Robert S. wrote: Danke. Von welchem Tag sind die Daten? 4. Juli! Bye Frederik -- Frederik Ramm ## eMail frede...@remote.org ## N49°00'09 E008°23'33 ___ Talk-de mailing list Talk-de@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-de
[Talk-it] taggare maxspeed
Ho trovato spesso delle strade statali e non con i seguenti cartelli di indicazione di velocità prima 50 orari poi 70 poi dopo 50metri 30 poi subito 50 poi 90 poi 70 poi 40 poi 70 poi 50 ecc nell'arco di 1 km e magari con strada mappata giustamente secondo i canoni italiani con 70 orari.. per questo motivo mi chiedo ha senso mappare le strade con maxspeed in italia dove ogni 20 metri cambiano cartello e in italia lo sappiamo da 0 a 130 sono valide tute le possibilità 10,20,30,40,50 ecc o è meglio tenere per convenzione i 50,70,90,130 senza mappare maxspeed se non nelle vicenanze magari di un velox? Io propongo questa seconda chance, leggendo poi che per 80% dei casi i segnali stradali sono errati e datati e da sostituire per le statistiche italiane, meglio tenere le convenzioni ufficiali del codice della strada senza mappare maxspeed che ne pensate? ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] taggare maxspeed
Il 29/07/2012 17:00, beppebo...@libero.it ha scritto: Ho trovato spesso delle strade statali e non con i seguenti cartelli di indicazione di velocità prima 50 orari poi 70 poi dopo 50metri 30 poi subito 50 poi 90 poi 70 poi 40 poi 70 poi 50 ecc nell'arco di 1 km e magari con strada mappata giustamente secondo i canoni italiani con 70 orari.. per questo motivo mi chiedo ha senso mappare le strade con maxspeed in italia dove ogni 20 metri cambiano cartello e in italia lo sappiamo da 0 a 130 sono valide tute le possibilità 10,20,30,40,50 ecc o è meglio tenere per convenzione i 50,70,90,130 senza mappare maxspeed se non nelle vicenanze magari di un velox? Teoricamente dovresti mappare tutte le velocità marcate. Se no tanto vale non mapparne nessuna. Mi rendo conto che è un lavoro enorme e spesso inutile, ma mappare scientemente un dato errato (maxspeed 70 dove è 50) solo perché è più semplice è controproducente. L'unica eccezione possono essere i limiti di velocità di breve durata (diciamo anche poche settimane) causa cantiere, ma già un limite causa cantiere pluriennale val la pena essere mappato (l'aurelia tra Civitavecchia e Tarquinia è passata recentemente da 90 a 60 causa cantiere - che deve ancora aprire - per l'adeguamento autostradale del tratto che durerà anni) Maurizio ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] taggare maxspeed
2012/7/29 beppebo...@libero.it beppebo...@libero.it: che ne pensate? Vedo la tua domanda e rilancio: se io mappo il limite di velocità prendendo nota mentre vado da A a B, OSM considera lo stesso limite anche da B ad A. O no? (Se la risposta fosse sì, direi che è una bella cavolata...) PS: proprio per i dubbi che hai tu e per quest'altro che ho io, da un po' di tempo metto il maxspeed solo dentro i centri abitati. -- Cià Cristiano / Sky One Home: http://www.skyone.it (itinerari in moto e non solo) Pensieri: http://blog.skyone.it ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] 2028 nodi nel percorso 29132578 (coastline Italia)...
Salve ragazzi, mi sono imbattuto oggi in questo errore Violazione delle capacità delle API, editando la costa a sud di Bari (inserendo le numerosissime grotte marine presenti nel mio paese d'origine ed editando la linea di costa). Leggendo http://wiki.openstreetmap.org/wiki/IT:Elements qui dice di spezzare il percorso, inserendolo in una relazione. Ho provato a spezzarlo, e nel farlo JOSM mi avverte che una relazione di appartenenza è stata copiata in tutte le strade. Verificare l'operazione e correggere dove necessario. Cercando di caricare i dati, JOSM mi segnala due warnings: Tipo di relazione sconosciuto: Landmass (Italia, 2503 membri, incompleto) e Nel multipoligono è presente un elemento che non è un percorso, incompleto. Cosa devo fare per poter continuare e caricare i dati immessi? Come elimino gli avvertimenti in questione? -- View this message in context: http://gis.19327.n5.nabble.com/2028-nodi-nel-percorso-29132578-coastline-Italia-tp5718971.html Sent from the Italy General mailing list archive at Nabble.com. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] 2028 nodi nel percorso 29132578 (coastline Italia)...
dovrebbe bastare spezzare la linea, l'api consente segmenti con al massimo 2000 punti. il primo warning dice che non conosce il tipo landmass (questo è un problema di josm :) ) e non hai scaricato tutti gli elementi della relazione, il secondo che nella relazione ci dev'essere un nodo inserito, quando sono consentite solo way. ciao, stefano Il giorno 29/lug/2012 18:16, Jeawrong jeawithl...@tin.it ha scritto: Salve ragazzi, mi sono imbattuto oggi in questo errore Violazione delle capacità delle API, editando la costa a sud di Bari (inserendo le numerosissime grotte marine presenti nel mio paese d'origine ed editando la linea di costa). Leggendo http://wiki.openstreetmap.org/wiki/IT:Elements qui dice di spezzare il percorso, inserendolo in una relazione. Ho provato a spezzarlo, e nel farlo JOSM mi avverte che una relazione di appartenenza è stata copiata in tutte le strade. Verificare l'operazione e correggere dove necessario. Cercando di caricare i dati, JOSM mi segnala due warnings: Tipo di relazione sconosciuto: Landmass (Italia, 2503 membri, incompleto) e Nel multipoligono è presente un elemento che non è un percorso, incompleto. Cosa devo fare per poter continuare e caricare i dati immessi? Come elimino gli avvertimenti in questione? -- View this message in context: http://gis.19327.n5.nabble.com/2028-nodi-nel-percorso-29132578-coastline-Italia-tp5718971.html Sent from the Italy General mailing list archive at Nabble.com. ___ 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] taggare maxspeed
Il 29/07/2012 17:00, beppebo...@libero.it ha scritto: Ho trovato spesso delle strade statali e non con i seguenti cartelli di indicazione di velocità prima 50 orari poi 70 poi dopo 50metri 30 poi subito 50 poi 90 poi 70 poi 40 poi 70 poi 50 ecc nell'arco di 1 km e magari con strada mappata giustamente secondo i canoni italiani con 70 orari.. Stai descrivendo un caso peggiore. Anch'io di recente mi sono messo a mappare i limiti di velocità, e certe volte è impegnativo stare dietro a tutti i cartelli... però se la strada è fatta così è quella che va mappata. In questo caso come in ogni aspetto della mappatura, si tagga quello che praticamente si riesce a fare, se qualcosa richiede troppo tempo o risorse lo si rimanda a tempi migliori o si lascia ad un altro mappatore che è più pratico, oppure ha una videocamera sulla macchina, o cose del genere. Io propongo questa seconda chance, leggendo poi che per 80% dei casi i segnali stradali sono errati e datati e da sostituire per le statistiche italiane, In che senso? -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] taggare maxspeed
Il 29/07/2012 17:54, Sky One ha scritto: se io mappo il limite di velocità prendendo nota mentre vado da A a B, OSM considera lo stesso limite anche da B ad A. O no? Se usi la chiave maxspeed sì. Se quando rilevi i limiti non sei sicuro che un certo limite valga nei due sensi, oppure sai per certo che il limite è diverso nei due sensi, devi usare le chiavi maxspeed:forward e maxspeed:backward. -- Giacomo Boschi ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] taggare maxspeed
-Original Message- From: Sky One [mailto:sky...@skyone.it] Sent: domenica 29 luglio 2012 17:54 To: beppebo...@libero.it; openstreetmap list - italiano Subject: Re: [Talk-it] taggare maxspeed Vedo la tua domanda e rilancio: se io mappo il limite di velocità prendendo nota mentre vado da A a B, OSM considera lo stesso limite anche da B ad A. O no? Si. Se i limiti sono diversi nei due versi (ma anche solo se devi limitare l'indicazione ad un solo verso perché non conosci il limite nel verso opposto), si usano le chiavi maxspeed:forward (valido per il verso con cui la way è tracciata in OSM) e maxspeed:backward (per il verso opposto). Le velocità da mappare sono solo quelle indicate dal codice (implicita a seconda del tipo di strada oppure imposta dalla segnaletica, ove presente). E' un lavoraccio, e spesso si ottengono risultati inconsistenti perché la segnaletica è caotica, ma non è compito nostro correggerne le manchevolezze. Proprio perché è difficile ricostruire quale sia la velocità massima corretta per un tratto di strada, suggerisco di mappare anche la segnaletica, con nodi in corrispondenza dei cartelli (accanto alla strada nella direzione di marcia) e i tag ufficiosi: traffic_sign=maxspeed + maxspeed=xy (sarebbe utile anche mappare i cartelli di fine limite di velocità, o specificare se un cartello di limite di velocità ha la freccia che indica che conferma un valore già valido nel tratto di strada precedente. Che tag si potrebbero usare?). Inoltre è utile indicare la fonte del limite di velocità indicato: - se imposti esplicitamente dalla segnaletica: source:maxspeed=sign - se implicito nel tipo di strada, indicare il tipo di strada, esempio: maxspeed=50 + source:maxspeed= IT:urban maxspeed=130 + source:maxspeed= IT: motorway maxspeed=90 + source:maxspeed= IT: rural maxpeed=110 + source:maxspeed=IT:trunk Ricordo anche che i cartelli di limite di velocità valgono solo fino al primo incrocio. Se nel completare la mappa si aggiungono delle strade che incrociano una strada su cui sono già taggati dei limiti espliciti di velocità, bisognerebbe cercare di controllare se valgono sia prima che dopo l'incrocio. Potrebbe infatti succedere che il limite in realtà cessi dall'incrocio in avanti, ma il mappatore li aveva involontariamente estesi al tratto successivo perché l'incrocio non era mappato). Si, è' un vero lavoraccio! Ciao, Alberto ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] 2028 nodi nel percorso 29132578 (coastline Italia)...
Il 29/07/2012 18:43, sabas88 ha scritto: dovrebbe bastare spezzare la linea, l'api consente segmenti con al massimo 2000 punti. il primo warning dice che non conosce il tipo landmass (questo è un problema di josm :) ) e non hai scaricato tutti gli elementi della relazione, il secondo che nella relazione ci dev'essere un nodo inserito, quando sono consentite solo way. Il nodo in questione dovrebbe essere Roma, con il ruolo di capitale... Maurizio. ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
Re: [Talk-it] taggare maxspeed
On 2012-07-29 at 17:00:04 +0200, beppebo...@libero.it wrote: Ho trovato spesso delle strade statali e non con i seguenti cartelli di indicazione di velocità prima 50 orari poi 70 poi dopo 50metri 30 poi subito 50 poi 90 poi 70 poi 40 poi 70 poi 50 ecc nell'arco di 1 km e magari con strada mappata giustamente secondo i canoni italiani con 70 orari.. per questo motivo quando i cartelli sono in ordine effettivamente hanno un senso (ad esempio 110 - 90 - 70 - 50 alla fine di un autostrada, dalle nostre parti); in questo caso ammetto che stare a mappare tutti i passaggi è noioso, non so se valga la pena mettere solo il limite finale (magari a metà tratto di decelerazione), soprattutto se si è in auto da soli e si sa di non riuscire ad essere precisi nel rilevare gli esatti punti di cambio del limite. Allo stesso modo mi è capitata una strada con limite 50, meno di un km con limite a 70, serie di incroci/rotonde con conseguente limite a 50 e poi di nuovo limite a 70 per un tratto significativo. In questo caso ero tentata di ignorare il primo pezzetto di limite a 70, ma alla fin fine l'ho mappato. In ogni caso, se qualcun'altro (o ripassandoci con qualcuno sul sedile passeggero che prenda i POI) sistema con maggiore dettaglio, è sicuramente una miglioria. (tra l'altro, in teoria i canoni italiani da 70 km/h di default dovrebbero essere relativamente rari: strade urbane di scorrimento, che quindi se non ricordo male devono anche essere a due corsie e carreggiate separate; da queste parti sono molto più frequenti le strade extraurbane secondarie piene di incroci e con limite abbassato a 70 con opportuni cartelli.) mi chiedo ha senso mappare le strade con maxspeed in italia dove ogni 20 metri cambiano cartello e in italia lo sappiamo da 0 a 130 sono valide tute le possibilità 10,20,30,40,50 ecc o è meglio tenere per convenzione i 50,70,90,130 senza mappare maxspeed se non nelle vicenanze magari di un velox? Gli autovelox esistono anche mobili, e poi non è che i limiti vadano rispettati solo in quei casi. Se un limite non è temporaneo per lavori ed è valido su una parte appena appena significativa di strada va sicuramente segnato anche se è un numero strano tipo 40, 60 o 80, perché no? Per gli altri casi, eviterei categoricamente di segnare un limite più alto di quello reale: se un navigatore ti dice che stai superando il limite perche' crede che tu debba andare a 50km/h (e invece per 500 metri puoi andare a 70km/h) non è un grosso problema, se ti dice che puoi andare a 90km/h e invece lì c'è un limite a 50km/h è molto più grave. Io propongo questa seconda chance, leggendo poi che per 80% dei casi i segnali stradali sono errati e datati e da sostituire per le statistiche italiane, meglio tenere le convenzioni ufficiali del codice della strada senza mappare maxspeed la convenzione ufficiale del codice della strada è che valga il limite di velocità segnato dai cartelli qualunque cosa questi dicano (e solo in caso di assenza dei cartelli ci siano dei default). La storia che i segnali stradali siano errati è una mezza leggenda metropolitana e al massimo serve per farsi annullare multe in sede di ricorso basandosi su violazioni di forma, anche quando in realtà si è in torto o quasitorto. -- Elena ``of Valhalla'' ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-it] Numeri civici e autorizzazioni
Qualche giorno fa ho inoltrato ad alcuni comuni limitrofi la richiesta di avere i numeri civici e relativa autorizzazione a inserire i dati su OSM. Il comune di Altivole (TV) mi ha risposto fornendo solo i dati (shape file). Posso dare per implicita l'autorizzazione oppure bisogna avere una autorizzazione esplicita? Nel secondo caso, basta una email o serve un cartaceo scannerizzato? Io sarei maggiormente propenso per l'autorizzazione implicita visto che la richiesta di autorizzazione era presente nella stessa email in cui chiedevo i dati. Stefano Fraccaro ___ Talk-it mailing list Talk-it@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-it
[Talk-se] Mer Bing satellitdata
Hej. Jag har precis varit på Öland för lite semester. Tidigare har det inte funnits användbara Bing-data för Öland, men nu verkar detta finnas. Tänkte bara tipsa om detta för er som mappar på Öland. Det finns lite olika sidor för att se täckning av Bing data. Dom jag använder är: http://ant.dev.openstreetmap.org/bingimageanalyzer/ och http://mvexel.dev.openstreetmap.org/bing/ Mvh Christian ___ Talk-se mailing list Talk-se@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-se
[Talk-at] footway in der argentinierstraße
hallo! bei meinen aufräumarbeiten im 4. bin ich über folgendes gestolpert: da lag unter der argentinierstraße [1] dieser way [2] mit den folgenden eigenschaften (btw: nicht vom bot angefasst!): footway:right.incline = -5% footway:right.sloped_curb = 2 footway:right.smoothness = good footway:right.surface = asphalt footway:right.width = 2.5 ich kann zwar wenig damit anfangen, aber für mich sieht das so aus, als würde da ein footway näher beschrieben werden, der eigentlich nirgends getaggt ist. gehörten diese eigenschaften nicht besser an die argentinierstraße rangehängt? bzw: wenn schon als eigener way (der dann aber mEn auch neben der straße liegen müsste), fehlt dann nicht zumindest ein highway=footway oder ähnliches? lasst bitte mal eure meinungen dazu hören! danke lg [1] http://www.openstreetmap.org/browse/way/28978894/history [2] http://www.openstreetmap.org/browse/way/105450608/history -- christian user:grimnirson ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On 07/29/2012 12:16 PM, Christian Hauer wrote: da lag unter der argentinierstraße [1] dieser way [2] mit den folgenden eigenschaften (btw: nicht vom bot angefasst!): footway:right.incline = -5% footway:right.sloped_curb = 2 footway:right.smoothness = good footway:right.surface = asphalt footway:right.width = 2.5 [...] gehörten diese eigenschaften nicht besser an die argentinierstraße rangehängt? Auf jeden Fall an die Argentinierstraße drangehängt und nicht als eigener Footway. Ich halte den getrennten Radweg schon für übermäßig detailliert, es sollte imo auf keinen Fall einreißen auch noch Fußwege (d.h. Gehsteige) getrennt von der Straße zu erfassen. Das ganze Ding mitsamt Gehsteigen und der Parkspur und dem Radweg ist die Argentinierstraße und sollte imo auch als ein Ding in der Datenbank liegen. Ob das jetzt wirklich ein Way mit lauter lane-Properties ist oder mehrere Wege in einer Relation ist mir eigentlich erstmal egal, aber es sollte möglich sein den ganzen Verkehrsweg als die eine Straße zu identifizieren, die er ist. Aber das ist schon OT. Langer Rede kurze Sinn: Kopier die Tags an die Straße und lösch den komischen Way darunter. lg, Norbert ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
Schönen guten Tag! Der gehört eindeutig mit der Straße vereint. Auf die schnelle bin ich mir nicht sicher, ob er so richtig ist, ich meine, es müsste 'sideway' statt 'footway' heißen, aber da kann ich mich täuschen. Heute (29. Juli) um 12:16 schrieb Christian Hauer: hallo! bei meinen aufräumarbeiten im 4. bin ich über folgendes gestolpert: da lag unter der argentinierstraße [1] dieser way [2] mit den folgenden eigenschaften (btw: nicht vom bot angefasst!): footway:right.incline = -5% footway:right.sloped_curb = 2 footway:right.smoothness = good footway:right.surface = asphalt footway:right.width = 2.5 ich kann zwar wenig damit anfangen, aber für mich sieht das so aus, als würde da ein footway näher beschrieben werden, der eigentlich nirgends getaggt ist. gehörten diese eigenschaften nicht besser an die argentinierstraße rangehängt? bzw: wenn schon als eigener way (der dann aber mEn auch neben der straße liegen müsste), fehlt dann nicht zumindest ein highway=footway oder ähnliches? lasst bitte mal eure meinungen dazu hören! danke lg [1] http://www.openstreetmap.org/browse/way/28978894/history [2] http://www.openstreetmap.org/browse/way/105450608/history -- Gruß, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-at] Althof Retz
hallo! ich bin gestern beim durchsehen der karte über folgendes gestolpert: http://www.openstreetmap.org/?lat=48.758039lon=15.949998zoom=18layers=M abgesehen davon, dass der letzte bearbeiter die building=yes-tags rausgeschmissen hat, hat er auf jedes einzelne polygon des komplexes ein tourism=hotel sowie den namen gelegt. ich denke, dass ganze gehört in eine relation zusammengefasst, nur frag ich mich, welchen typ man dafür verwenden sollte. ich ja hätte am ehesten zu einem multipolygon mit lauter outer-rollen tendiert, nachdem ich es ab nicht besser weiß, wollte ich mal eure meinung hören, bevor ich den herrn anschreib. danke! -- lg christian user:grimnirson ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] Althof Retz
Hi, Ich würde die Gebäude nur mit building=yes taggen und dann alles mit einer site-Relation zusammenfassen. Dort kommen dann auch die sonstigen Tags wie tourism=hotel und der Name hin. Vg, Martin Am 29.07.2012 um 14:51 schrieb Christian Hauer xni...@gmail.com: hallo! ich bin gestern beim durchsehen der karte über folgendes gestolpert: http://www.openstreetmap.org/?lat=48.758039lon=15.949998zoom=18layers=M abgesehen davon, dass der letzte bearbeiter die building=yes-tags rausgeschmissen hat, hat er auf jedes einzelne polygon des komplexes ein tourism=hotel sowie den namen gelegt. ich denke, dass ganze gehört in eine relation zusammengefasst, nur frag ich mich, welchen typ man dafür verwenden sollte. ich ja hätte am ehesten zu einem multipolygon mit lauter outer-rollen tendiert, nachdem ich es ab nicht besser weiß, wollte ich mal eure meinung hören, bevor ich den herrn anschreib. danke! -- lg christian user:grimnirson ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
Servus! Heute (29. Juli) um 15:22 meinte Stefan Tauner: Zu genau gibt's nicht. Mag sein. Dafür gibt es Dinge, die von Einigen als Erhöhung der Genauigkeit gesehen werden (typisches Beispiel Gehsteigmapping), die in Wirklichkeit Informationsvernichtung sind. Beispiel: Nehmen wir an, die Hausnummer 45 liegt gegenüber der 44. solange der Gehsteig Teil der Straße ist, berechnet das Fußgängerroutingprogramm einen Weg der Länge Null. Bei eigens gemappten Gehsteigen muss das Routingprogramm erst einmal einen Weg finden, und der wird dann sein: gehen sie nach rechts bis zur nächsten Querstraße, gehen sie dort ca. 10 m links, biegen sie dort wieder links ab und gehen sie das ganze Stück zurück. Offensichtlich liefert der 'genauer' gezeichnete Gehsteig also idiotische Ergebnisse! Und komm mir keiner damit, dann müssen eben die Routingprogramme das können, der nicht eine Implementierung der Lösung dieses gordischen Knotens mitbringt. -- Mit freundlichen Grüßen, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On Sun, 29 Jul 2012 16:27:01 +0200 Boris Cornet bor...@osm-at.org wrote: Heute (29. Juli) um 15:22 meinte Stefan Tauner: Zu genau gibt's nicht. Mag sein. Dafür gibt es Dinge, die von Einigen als Erhöhung der Genauigkeit gesehen werden (typisches Beispiel Gehsteigmapping), die in Wirklichkeit Informationsvernichtung sind. informationsvernichtung ist ein wenig das falsche wort, finde ich. wenn man die annahme hat, daß eine straße samt verkehr, geparkte autos und grünstreifen kein hindernis darstellen, dann verkomplizieren zusätzliche wäys natürlich diverse anwendungen, weil nicht benötigte information hinzukommt. nur ist diese annahme richtig...? Beispiel: Nehmen wir an, die Hausnummer 45 liegt gegenüber der 44. solange der Gehsteig Teil der Straße ist, berechnet das Fußgängerroutingprogramm einen Weg der Länge Null. Bei eigens gemappten Gehsteigen muss das Routingprogramm erst einmal einen Weg finden, und der wird dann sein: gehen sie nach rechts bis zur nächsten Querstraße, gehen sie dort ca. 10 m links, biegen sie dort wieder links ab und gehen sie das ganze Stück zurück. Offensichtlich liefert der 'genauer' gezeichnete Gehsteig also idiotische Ergebnisse! für rollstuhlfahrer und kinderwägen oder an stark befahrenen straßen mit geregelten übergängen ist das durchaus das richtige ergebnis, genauso wie es mit nur einem way berechnet das falsche wäre (unter der voraussetzung, daß sich überhaupt jemand 10m im freien routen lassen will :) Und komm mir keiner damit, dann müssen eben die Routingprogramme das können, der nicht eine Implementierung der Lösung dieses gordischen Knotens mitbringt. natürlich beinhaltet es einen mehraufwand, aber um dein irrwitziges beispiel zu lösen, muß man nur die anfangs beschriebene voraussetzung wieder herstellen, daß straßen kein hindernis für fußgänger sind. also zb. die ways anhand der relationen im preprocessing wieder zusammenfügen (nicht ganz trivial, aber im besprochenen rahmen vollständig lösbar ohne große verrenkungen). wenn man dein beispiel an eine kreuzung versetzt bei der 2 straßen überquert werden müssen und nur zum teil gereglte zebrastreifen vorhanden sind, schaut die sache schon ganz anders aus... und, man darf bei der ganzen diskussion auch nicht vergessen, daß osm keine routingdatenbank ist. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On 07/29/2012 03:22 PM, Stefan Tauner wrote: On Sun, 29 Jul 2012 13:02:18 +0200 Norbert Wenzel norbert.wenzel.li...@gmail.com wrote: Das ganze Ding mitsamt Gehsteigen und der Parkspur und dem Radweg ist die Argentinierstraße und sollte imo auch als ein Ding in der Datenbank liegen. Ob das jetzt wirklich ein Way mit lauter lane-Properties ist oder mehrere Wege in einer Relation ist mir eigentlich erstmal egal, aber es sollte möglich sein den ganzen Verkehrsweg als die eine Straße zu identifizieren, die er ist. Genau. Aber wenn unterschiedliche, aber quasi-parallel verlaufende Wege detailliert genug gemappt sind und eine Vielzahl von Attributen aufweisen, die verschieden sind und man sie auch in der Realität klar unterscheiden kann, ist es wesentlich sinnvoller ihnen eigene logische Entitäten in der DB zu geben und sie dafür auf einer anderen Ebene zu aggregieren (z.B. mit Relationen). Ja, wir sind natürlich OT aber wie ich geschrieben hab, bin ich zur Not auch damit einverstanden, die Details in Relationen zu verpacken. Auch wenn das den Aufwand für jede Auswertungssoftware ordentlich in die Höhe schraubt. Nur so wie die Radwege derzeit gehandhabt werden ist es einfach Murks. Denn die werden einfach so annähernd parallel gezeichnet ohne jede Verknüpfung in der DB zur eigentlichen Straße. Dadurch geht Information verloren nur damit der Radweg am Luftbild genau über dem Bild liegt. Und so Details hinzufügen und dabei (und dabei sind wir uns ja offensichtlich einig) wichtige Überblicksinfos (das alles ist die XY-Straße) zu zerstören ist einfach unnötig, aber derzeit leider gern gehandhabte Praxis. Solange es keine Mappingvariante gibt die bisher erhalten Informationen erhält *und* diese neuen aufnimmt, seh ich dieses Tagging als schädlich an und revertier es nur nicht, weil mir mein Blutdruck wichtiger ist als OSM. lg, Norbert PS: Und ich bin mir sicher man kann den Detailgrad beim Mapping auch so hoch treiben, dass es auch dir zuviel wird. Von Datenkonsumenten die mit den Datenwulst arbeiten müssen ganz zu schweigen. ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
hallo, ich wollte mit meiner frage da keinen flamewar lostreten ...;) Am 2012-07-29 17:07, schrieb Stefan Tauner: ..., daß straßen kein hindernis für fußgänger sind. also zb. die ways anhand der relationen im preprocessing wieder zusammenfügen (nicht ganz trivial, aber im besprochenen rahmen vollständig lösbar ohne große verrenkungen). ohne dass ich jetzt der große experte wäre (nona, sonst hätt ich ja nicht blöd gefragt;) ): mir erscheint doch es einfacher, aus einem way die sachen wegzulassen, als zuerst mehrere ways zusammenzuführen. sprich: ist das navi im rollstuhl-/kinderwagen-/whatever-modus, so kann es ja getrost die highways ignorieren und nur nach den sideway-tags und den fußgänger-übergängen routen. wird es von einem normalen fußgänger benutzt, kann es ja auch die highways miteinbeziehen. nur denke ich mir, dass es für die software einfacher sein dürfte, einfach vorhandene eigenschaften zu ignorieren, als zuerst irgendetwas zusammenzusetzen, wo dann das gleiche ergebnis rauskommen, als hätte man es gleich gesammelt gemappt. man darf bei der ganzen diskussion auch nicht vergessen, daß osm keine routingdatenbank ist. das stimmt schon. aber - zumindest für mich - ist routing ein bedeutender teil, und ich denke, so wirds auch anderen gehen. bei mir wars immerhin das thema, das mich persönlich zu osm gebracht hat ... zum eigentlichen thema: in der paniglgasse war die gleiche konstellation vorhanden. hab das mal zusammengeführt. vielleicht mag mal wer drüberschauen, bevor ich mich an die argentinierstraße mache ... http://www.openstreetmap.org/browse/changeset/12536146 -- lg christian user:grimnirson ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On Sun, 29 Jul 2012 17:16:04 +0200 Norbert Wenzel norbert.wenzel.li...@gmail.com wrote: Denn die werden einfach so annähernd parallel gezeichnet ohne jede Verknüpfung in der DB zur eigentlichen Straße. Dadurch geht Information verloren nur damit der Radweg am Luftbild genau über dem Bild liegt. wie sieht deine (und eure) meinung in dem zusammenhang mit parkstraßen aus? gibts für die überhaupt ein geeignetes* tagging wie für parallelverlaufende radwege? ich denke da an sowas wie am ring oder der nordbahnstraße, auf die treffen mMn die selben argumente zu. -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
Guten Tag! Heute (29. Juli) um 17:29 tippte Stefan Tauner: On Sun, 29 Jul 2012 17:16:04 +0200 Norbert Wenzel norbert.wenzel.li...@gmail.com wrote: Denn die werden einfach so annähernd parallel gezeichnet ohne jede Verknüpfung in der DB zur eigentlichen Straße. Dadurch geht Information verloren nur damit der Radweg am Luftbild genau über dem Bild liegt. wie sieht deine (und eure) meinung in dem zusammenhang mit parkstraßen aus? gibts für die überhaupt ein geeignetes* tagging wie für parallelverlaufende radwege? ich denke da an sowas wie am ring oder der nordbahnstraße, auf die treffen mMn die selben argumente zu. Also ich denke, Parkstraßen kann man wohl mit Fug und Recht als eigene Fahrbahnen bezeichnen. Es gibt wohl auch welche die eigenen Gehsteige haben, oder? Beim Tagging ist wohl highway=service service=parking_aisle angebracht. -- Mit freundlichen Grüßen, Boris ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
wie sieht deine (und eure) meinung in dem zusammenhang mit parkstraßen aus? Also ich denke, Parkstraßen kann man ... ich les es schon dreimal und verstehs nicht ... was sind parkstraßen? redet ihr vielleicht von nebenfahrbahnen? lg christian ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On 29.07.2012 19:27, Stefan Tauner wrote: On Sun, 29 Jul 2012 19:14:50 +0200 Christian Hauerxni...@gmail.com wrote: wie sieht deine (und eure) meinung in dem zusammenhang mit parkstraßen aus? Also ich denke, Parkstraßen kann man ... ich les es schon dreimal und verstehs nicht ... was sind parkstraßen? redet ihr vielleicht von nebenfahrbahnen? ja, das dürfte wohl die korrekte bezeichnung sein! tschuldigung. eigentlich find ich parkstraße ja passender... von fahren kann dort ja kaum die rede sein ;) Nebenfahrbahnen sind baulich von der Hauptfahrbahn getrennt = als eigenen Way mappen. highway=service ist klar, service=parking_aisle würde ich aber nicht angeben, weil eher für Parkplätze gedacht. An jene, die keinen Führerschein haben: Nebenfahrbahnen darf man nur dann befahren, wenn man vor hat dort zu halten oder zu parken. Ausname: Radfahrer. Darum: vehicle=destination + bicycle=yes Weil es sich eigentlich um einen eigenen Straßentyp handelt, wär ein eigener Tag dafür wünschenswert (service=irgendwas), der oneway=yes + vehicle=destination + bicycle=yes bereits impliziert, damit man es nicht überall explizit setzen muss und damit bei Gesetzesänderungen nicht alles umgetaggt werden muss. Noch was: Wenn ein Einbahnschild steht, ist es keine Nebenfahrbahn! Sondern normal highway=residential. Da der Ring als Beispiel genannt wurde... Dort gibt es soche Schein-Nebenfahrbahnen. Der Unterschied ist erstens, dass man durchfahren darf. Und zweitens, besonders tückisch, dass andere Vorrangregeln gelten. Am Luftbild sieht man nicht, ob eine Einbahntafel steht. Da hilft nur hingehen und nachschauen... -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
Am 2012-07-29 20:16, schrieb Friedrich Volkmann: highway=service ist klar, service=parking_aisle würde ich aber nicht angeben, weil eher für Parkplätze gedacht. seh ich auch so und deswegen fragte ich, was ihr meint. denn mit einer parking_aisle hat eine nebenfahrbahn sicher nix zu tun ... achtung! jetzt folgt etwas haarspalterei ... ;) Ausname: Radfahrer. Darum: vehicle=destination + bicycle=yes jein. § 8. Fahrordnung auf Straßen mit besonderen Anlagen. (1) Radfahrer dürfen in Nebenfahrbahnen auch fahren, wenn kein Radfahrstreifen, Radweg oder Geh- und Radweg vorhanden ist. Weil es sich eigentlich um einen eigenen Straßentyp handelt, wär ein eigener Tag dafür wünschenswert (service=irgendwas), genaugenommen ist es keine eigene straße, sondern eigentlich nur eine weitere Fahrbahn auf der selben straße. Noch was: Wenn ein Einbahnschild steht, ist es keine Nebenfahrbahn! Sondern normal highway=residential. Da der Ring als Beispiel genannt wurde... Dort gibt es soche Schein-Nebenfahrbahnen. Der Unterschied ist erstens, dass man durchfahren darf. Und zweitens, besonders tückisch, dass andere Vorrangregeln gelten. muß ich wieder widersprechen. es ist eine nebenfahrbahn, nur ergibt sich halt aus den verkehrszeichen etwas anderes. zu dem thema nebenfahrbahnen empfohlen: https://www.ris.bka.gv.at/Dokumente/Bundesnormen/NOR12155394/NOR12155394.html Am Luftbild sieht man nicht, ob eine Einbahntafel steht. Da hilft nur hingehen und nachschauen... oder auf wien.at nachschauen (soferns halt um eine wiener nebenfahrbahn geht ... ;) ) um jetzt mal noch was konstruktives dazu zu sagen: ich finde diese diskussion ein wenig theoretisch. ich würde das ganze etwas pragmatischer angehen. in der argentinierstraße oder ähnlichen standardstraßen, wo der gehweg direkt an die straße angepickt ist und parallel verläuft, bin ich persönlich für einen einzelnen way. beim ring siehts natürlich etwas anders aus, weil teilweise signifikante abstände zwischen der fahrbahn und den div anderen wegen sind, die wege oft von der hauptfahrbahn unabhängige, eigene verläufe haben usw. soweit meine ansicht. lg christian ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On 2012-07-29 21:02, Christian Hauer wrote: achtung! jetzt folgt etwas haarspalterei ... ;) Ausname: Radfahrer. Darum: vehicle=destination + bicycle=yes jein. § 8. Fahrordnung auf Straßen mit besonderen Anlagen. (1) Radfahrer dürfen in Nebenfahrbahnen auch fahren, wenn kein Radfahrstreifen, Radweg oder Geh- und Radweg vorhanden ist. und? alle anderen müssen schieben oder zu- oder abfahren... Wo siehst du das jein? Abgesehen davon sind diese Konglomerat-Straßen (Prater Hauptallee ist imho ein noch schlimmeres Beispiel als der Ring) sowieso ein Horror egal ob detailverliebtes Micromapping aller Spuren oder das Packen in die Tags. Die Spurmapping-Diskussion ist auch im Sand verlaufen, oder? LG, Stefan ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On 29.07.2012 21:02, Christian Hauer wrote: achtung! jetzt folgt etwas haarspalterei ... ;) Ausname: Radfahrer. Darum: vehicle=destination + bicycle=yes jein. § 8. Fahrordnung auf Straßen mit besonderen Anlagen. (1) Radfahrer dürfen in Nebenfahrbahnen auch fahren, wenn kein Radfahrstreifen, Radweg oder Geh- und Radweg vorhanden ist. Wieder ein Beweis, dass Juristen nicht Deutsch können. Der Satz kann verschiedenes bedeuten, je nachdem, welches Wort man betont, aber nichts davon kann gemeint sein. Jedenfalls sprechen komplizierte Regelungen (Ausnahmen von Ausnahmen) um so mehr für einen Speziellen Täg, der das alles zusammenfasst. Weil es sich eigentlich um einen eigenen Straßentyp handelt, wär ein eigener Tag dafür wünschenswert (service=irgendwas), genaugenommen ist es keine eigene straße, sondern eigentlich nur eine weitere Fahrbahn auf der selben straße. Du kannst gern Fahrbahntyp dazu sagen. Im OSM-Sinne ist es dann sowieso ein Service-Typ. es ist eine nebenfahrbahn, nur ergibt sich halt aus den verkehrszeichen etwas anderes. Die A2 ist ein wunderbarer Radweg, nur ergibt sich halt aus den Verkehrszeichen etwas anderes. :-) Am Luftbild sieht man nicht, ob eine Einbahntafel steht. Da hilft nur hingehen und nachschauen... oder auf wien.at nachschauen (soferns halt um eine wiener nebenfahrbahn geht Woran kann man da die richtigen Nebenfahrbahnen von den falschen unterscheiden? -- Friedrich K. Volkmann http://www.volki.at/ Adr.: Davidgasse 76-80/14/10, 1100 Wien, Austria ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
Re: [Talk-at] footway in der argentinierstraße
On Sun, 29 Jul 2012 23:08:17 +0200 Friedrich Volkmann b...@volki.at wrote: Woran kann man da die richtigen Nebenfahrbahnen von den falschen unterscheiden? das frag ich mich nicht nur bei satellitenbildern. du hast die einbahnschilder angesprochen... findet sich das im gesetzestext irgendwo? ich hab nur die definition in §2 gefunden: Nebenfahrbahn: jede neben einer Hauptfahrbahn verlaufende, von dieser jedoch getrennte Fahrbahn einer Straße -- Kind regards/Mit freundlichen Grüßen, Stefan Tauner ___ Talk-at mailing list Talk-at@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-at
[Talk-ca] canvec import in ontario
Hello, I'd like to import some canvec data for the area just north of Plevna, Ontario, Canada (NTS 031F02), which has not been imported and for the most part is completely blank. I have downloaded the most recent canvec 10 data and it looks like the import is easy enough to do using the provided osm files and the josm editor (I've done many edits in the past with josm). I imported a tile (NTS 031F02.0.0.0) before realizing that there were import guidelines, and I shouldn't just go ahead without first consulting the community. So, I'd just like to make sure it's ok to proceed. I will use a separate account for the imports as per the guideline. Is there anything else I should know or do before proceeding? Thanks, Jesse Davis ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Fixme Files
Oups, you are right Richard. I should have revised my notes. highway=turning_circle, was used in OSM to tag a dead-end node on a way. Pierre - Mail original - De : Richard Weait rich...@weait.com À : Bruno Remy bremy.qc...@gmail.com Cc : talk-ca@openstreetmap.org talk-ca@openstreetmap.org Envoyé le : Samedi 28 juillet 2012 23h02 Objet : Re: [Talk-ca] Fixme Files On Sat, Jul 28, 2012 at 10:49 PM, Bruno Remy bremy.qc...@gmail.com wrote: By the way is there a best-practice for roundabout? Circle ways? Or a single runabout node ? I always have been confused with those items... Roundabout a circular way, tagged as junction=roundabout (+ highway=$classification), is a circular way, which joins multiple linear ways. A roundabout has a central reservation unsuitable for driving. http://wiki.openstreetmap.org/wiki/Tag:junction%3Droundabout mini-roundabout a node tagged as highway=mini_roundabout joins multiple linear ways but is smaller and has no central reservation. the mini-roundabout is often a painted circle in an intersection. http://wiki.openstreetmap.org/wiki/Tag:highway%3Dmini_roundabout Turning circle. A node tagged, highway=turning_circle, is a wide area in a dead-end road to allow a vehicle to turn around to the direction they came from. http://wiki.openstreetmap.org/wiki/Turning_circle ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
[Talk-ca] Disgardable NHN and NRN tags
This is based on http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008830.html, a recent talk-us@ discussion about TIGER tags. Parts of this message are a copy/paste from there. Some people may not even be aware of this but JOSM silently discards the created_by tag if it exists on any object you change and upload to the API. This tag was deemed unnecessary and counterproductive a long time ago and this is just a way of cleaning it out of the database as people edit. Not sure if Potlatch does anything like this. I think some of the tags from the GeoBase NHN and NRN imports can be silently dropped too. I think the following can be safely dropped: geobase:datasetName geobase:uuid accuracy:meters waterway:type sub_sea:type Any thoughts? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Disgardable NHN and NRN tags
I'd keep the accuracy:meters around. I've used that for other things (mainly denoting how accurate my gps is in obtaining geodetic survey markers, or what the accuracy is based on number of sample points being averaged). Wouldn't want JOSM to be wiping those out. I think the ways tagged with sub_sea would need to be deleted, not just the tag itself. These tend to be hydrological topology connectors under lakes that show how rivers are connected. The entire way should be deleted to bring it in line with the rest of OSM. Not too sure about the waterway:type tag. Might be used in other places for other things? Can't think of anything stopping us from getting rid of geobase:* tags. Canvec imports don't have this, so it's inconsistent across the country, and it's probably not used anywhere else. Adam On Sun, Jul 29, 2012 at 5:43 PM, Steve Singer st...@ssinger.info wrote: On Sun, 29 Jul 2012, Paul Norman wrote: This is based on http://lists.openstreetmap.org/pipermail/talk-us/2012-July/008830.html, a recent talk-us@ discussion about TIGER tags. Parts of this message are a copy/paste from there. I think the following can be safely dropped: geobase:datasetName geobase:uuid I agree. When I started the geobase road imports it predated the ability to add changeset tags or comments. A lot of my reasoning for having those tags was to be able to traceback objects to their original Geobase objects so we could come up with a way of updating OSM with future versions of the Geobase data. These tags have never (to my knowledge) been used for this and I doubt they would be very useful for this purpose if anyone tried to do so. accuracy:meters waterway:type sub_sea:type Any thoughts? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-ca] Disgardable NHN and NRN tags
From: Adam Dunn [mailto:dunna...@gmail.com] Sent: Sunday, July 29, 2012 5:57 PM To: Steve Singer Cc: Paul Norman; Toby Murray; talk-ca@openstreetmap.org Subject: Re: [Talk-ca] Disgardable NHN and NRN tags I'd keep the accuracy:meters around. I've used that for other things (mainly denoting how accurate my gps is in obtaining geodetic survey markers, or what the accuracy is based on number of sample points being averaged). Wouldn't want JOSM to be wiping those out. Why not accuracy instead? But ya, if you're using it then it'll need to be kept. I think the ways tagged with sub_sea would need to be deleted, not just the tag itself. These tend to be hydrological topology connectors under lakes that show how rivers are connected. The entire way should be deleted to bring it in line with the rest of OSM. Most of them need converting to waterway=stream (or other tags as appropriate) and sub_sea deleting. A lot of them are small ponds or streams where there would normally be a way. Not too sure about the waterway:type tag. Might be used in other places for other things? Taginfo shows only the imported values - I doubt anyone is using this. Can't think of anything stopping us from getting rid of geobase:* tags. Canvec imports don't have this, so it's inconsistent across the country, and it's probably not used anywhere else. The ones I listed were from BC - are there others elsewhere that also need removing? ___ Talk-ca mailing list Talk-ca@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ca
Re: [Talk-cz] import budov
Já jsem pro hromadný import, případně následně pro vytvoření robota na údržbu. Minimálně u adresních bodů. MK - Original Message - From: hanoj [mailto:eha...@gmail.com] To: OpenStreetMap Czech Republic [mailto:talk-cz@openstreetmap.org] Sent: Sat, 28 Jul 2012 22:35:08 +0200 Subject: Re: [Talk-cz] import budov Ja bych nadhodil nekolik otazek treba pro adresni body: * Kolik je adresnich bodu? 2.500.000 * Kolik mapperu se bude ucastnit takove prace? Prvni desitky. * Jak dlouho to bude trvat? ... * Jaka cast dat by mela byt mappery pridavana tam kde nikdy nebyla? Vetsina. * Jak budou uzivatele hodnotit (ne)kvalitu dat jiz v OSM? Na zaklade dat CUZK a u par stovek bodu ze znalosti z terenu kde bydli.Tezko ale suplovat: http://www.cuzk.cz/GenerujSoubor.ashx?NAZEV=10-POROVNANIADRES Opravdu je individualni prace na vetsine uzemi republiky cesta, jak data RUIAN dostat do OSM? h.anoj Dne 27. července 2012 17:17 Miroslav Šulc fordf...@fordfrog.com napsal(a): v souvislosti s tím co píšeš mě napadlo udělat to komplet jako josm plugin. tj. serverová část by zůstala tak jak jsem psal, ale všechno ostatní by se dělalo přímo z josm pluginu. ten by si stáhl data přes api ode mě ze serveru z aktuální databáze rúian, provedl by porovnání s datovou vrstvou z osm a vyhodil by nějaké info o rozdílech v osm a v rúian s tím, že mapper by si vybíral varianty a potvrzoval je, případně by sáhnul přímo do osm vrstvy a udělal úpravy tam. při uploadu změn do osm by se pak zapsalo i info ke mně na server o provedení importu. do pluginu by se pak dala přidávat funkcionalita dle potřeby. ff Dne 27.7.2012 14:18, Jan Bilak napsal(a): Otázka je, jak by měla vypadat ta připravená data. V případě importu nových věcí tak, kde žádné nebyly, je to celkem primitivní. Ale mnohem náročnější bude import do míst, kde již nějaká data jsou. Tam bude třeba něco starého odstranit, něco modifikovat, něco přidat... Lze v OSM formátu postihnout nějak všechny tyto typy změn (odstranění, modifikace, přidání nových objektů)? A pokud lze, je možné to pak nějak rozumně vizualizovat, aby to člověk mohl projít a rozhodovat tohle je ok, tohle zamítnu a zůstane při starém, tohle bude ještě trochu jinak... pomocí stávajících nástrojů? Nevím, jaké jsou možnosti. Pokud nic vhodné stávajícího není, tak bych to viděl spíše na interaktivní aplikaci, která zobrazí ty rozdíly ve vhodné podobě, u každé umožní se rozhodnout, zda ponechat stará data, nová data, automaticky zmergovat nebo ručně upravit. Ruční úpravu by ta aplikace přímo nepodporovala, protože by to bylo příliš náročné (vlastně by bylo třeba vytvořit obdobu editoru jako JOSM), ale poznačilo by to nutnost ruční editace do dat nějakými tagy, aby výsledek, který z aplikace vypadne, bylo možné otevřít např. v JOSM a ručně provést potřebné úpravy. Např. u adresních bodů by bylo podle mě vhodné, aplikace provedla nějaké inteligentní matchování adresních bodů v OSM a RUIAN, zobrazovala původní a nový bod vizuálně propojený šipkou, jinak vyznačené body, které jsou pouze v OSM a naopak jinak vyznačené body, které jsou pouze v RUIAN. Uživatel by mohl vždy zvolit, zda ponechat novou nebo starou polohu bodu (zde by bylo možné i volit vlastní polohu - jde o primitivní úkon) atd. Nakonec by aplikace vytvořila OSM patch, který by obsahoval požadované úpravy včetně vhodně zmergovaných tagů (ty by možná bylo třeba také kontrolovat v aplikaci) atd. U budov to bude samozřejmě výrazně složitější. Obecně čistě ručního importu se celkem obávám. Dat je vetší než malé množství. Honza Dne 27. července 2012 13:41 Miroslav Šulc fordf...@fordfrog.com napsal(a): Dne 27.7.2012 13:20, Jan Bilak napsal(a): Ahoj, teď z toho nechápu, zda si aplikaci představuješ jen jako evidenční nebo zda aplikace má provádět vlastní import (resp. s ním výrazně pomáhat). aplikace pouze připraví data z rúian, samotný import provede mapper. tj. aplikace pro import připraví data, ale nebude import provádět, ten se bude dělat ručně. i kdybychom (pokud vůbec, to vyplyne z ručních importů) v budoucnu uvažovali o nějaké automatizaci, tak v prvním kroku se to stejně musí udělat ručně, abychom věděli, nakolik je rúian spolehlivý zdroj, jaké problémy lze očekávat apod. pro kontinuální práci s daty z rúian je pak potřeba ta evidenční část. Tedy za zásadní považuji porovnání současných OSM dat s daty RUIAN a následné provedení změn (posuny stávajících bodů, opravy tagů, zachování stávajících tagů, doplnění chybějících tagů, ...). Samozřejmě s tím, že proces bude pod manuální kontrolou člověka, který bude import provádět (tedy nikoli plně automatický, ale poloautomatický). O těchto funkcích se v popisu nezmiňuješ. vycházel jsem hlavně z importu budov tam, kde je nemáme, to je asi ta nejjednodušší varianta. co se týče importu budov do míst, kde už nějaké jsou, nebo importu adresních bodů, tak se přiznám, že
Re: [Talk-cz] Pěkná kupka práce
Oprava chyb po odmítačích: - Vidochov (oprava silnice) - Mostek (oprava využití krajin, kompletní předělání zničeného lesa okolo obce) - Železnice (oprava drobných detailů smazaných BOTem) - Jičín (drobné opravy) - Pustějov - Nový Jičín (oprava roztržených silnic) - oprava silnice 46421, 191, 27 (E 53), 190, 145, 14516, 185, 1422, - Bílov (opravy rozpojených silnic) - Litochovice/Marčovice (spojovací silnice) - Předslavice/Všechlapy (spojovací silnice) - koleje č. 1435 - okolí Rovenska pod Troskami (chybějící vodní nádrže, drobné cesty) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] Zásahy BOTa - nutné a provedené opravy
Ahoj, moc se tady na TALKu nevyznám a tak doufám, že nezakládám duplicitní téma. Ale ohledně chyb způsobených BOTem, jedná se mi o to, zda bychom toto téma mohli založit jako seznam míst, kde jsme provedli opravy poškozených částí a zároveň když víme a nemáme čas napsat chybná místa, aby se na to někdo mohl podívat Tady je můj seznam míst, kde jsem už provedl redakci a opravil chyby (rozpojené silnice, jejich chybějící části, srovnání silnic po smazání některých jejich bodů). Snad jsou na těch místech všechny a správně, myslím si o sobě, že jsem celkem důkladný, ale přehlédnutí nevylučuji, přece jen je to někdy nepřehledné... Škoda že nejde nějak vyfiltrovat pouze chyby v rozdělení silnic. Inspektor ukazuje vše možné, já třeba neřeším PowerLine, což jsou tam nejčervenější hadi a silnice typu Track taky zatím nedoplňuji důkladně. - Vidochov (oprava silnice) - Mostek (oprava využití krajin, kompletní předělání zničeného lesa okolo obce) - Železnice (oprava drobných detailů smazaných BOTem) - Jičín (drobné opravy) - Pustějov - Nový Jičín (oprava roztržených silnic) - oprava (zarovnání) silnice 46421, 191, 27 (E 53), 190, 145, 14516, 185, 1422, 141 (obec Bavorov), 271 - Bílov (opravy rozpojených silnic) - Litochovice/Marčovice (spojovací silnice) - Předslavice/Všechlapy (spojovací silnice) - koleje č. 1435 - Vodňany (vodní nádrže) - Vodňanské Svobodné Hory (drobné opravy okolních cest) - Horní Jiřetín (rebuild smazaných cest) - Litvínov (opravy a doplnění roztržených a umazaných silnic) - Chomutov (drobné doplnění smazaných uliček) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zásahy BOTa - nutné a provedené opravy
Opravené cesty je možné přímo v OSM Inspectoru odstranit ze zobrazení. Je potřeba kliknout na červený bod nebo linii a pak v pravém sloupci na ikonku odpadkového koše. Takto se dá celkem přehledně evidovat co už je opraveno a postupně mapu odčervenit. TT 2012/7/29 Michal Tauchman michal.tauch...@gmail.com Ahoj, moc se tady na TALKu nevyznám a tak doufám, že nezakládám duplicitní téma. Ale ohledně chyb způsobených BOTem, jedná se mi o to, zda bychom toto téma mohli založit jako seznam míst, kde jsme provedli opravy poškozených částí a zároveň když víme a nemáme čas napsat chybná místa, aby se na to někdo mohl podívat Tady je můj seznam míst, kde jsem už provedl redakci a opravil chyby (rozpojené silnice, jejich chybějící části, srovnání silnic po smazání některých jejich bodů). Snad jsou na těch místech všechny a správně, myslím si o sobě, že jsem celkem důkladný, ale přehlédnutí nevylučuji, přece jen je to někdy nepřehledné... Škoda že nejde nějak vyfiltrovat pouze chyby v rozdělení silnic. Inspektor ukazuje vše možné, já třeba neřeším PowerLine, což jsou tam nejčervenější hadi a silnice typu Track taky zatím nedoplňuji důkladně. - Vidochov (oprava silnice) - Mostek (oprava využití krajin, kompletní předělání zničeného lesa okolo obce) - Železnice (oprava drobných detailů smazaných BOTem) - Jičín (drobné opravy) - Pustějov - Nový Jičín (oprava roztržených silnic) - oprava (zarovnání) silnice 46421, 191, 27 (E 53), 190, 145, 14516, 185, 1422, 141 (obec Bavorov), 271 - Bílov (opravy rozpojených silnic) - Litochovice/Marčovice (spojovací silnice) - Předslavice/Všechlapy (spojovací silnice) - koleje č. 1435 - Vodňany (vodní nádrže) - Vodňanské Svobodné Hory (drobné opravy okolních cest) - Horní Jiřetín (rebuild smazaných cest) - Litvínov (opravy a doplnění roztržených a umazaných silnic) - Chomutov (drobné doplnění smazaných uliček) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] Zásahy BOTa - nutné a provedené opravy
Tomáš Tichý t.tichy@... writes: Takto se dá celkem přehledně evidovat co už je opraveno a postupně mapu odčervenit. Jsem vůl, tohle jsem přehlédl. Já používal Keep Right, takže k Inspektoru jsem se dostal až teď. Tak teď abych to prošel co jsem dělal a odznačil, ať se nám to hezky vybarvuje zpátky do normálu... :-) ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Ahoj, u širších silnic nelze dle EU norem udělat přechod pro chodce bez prostředního ostrůvku (oddělujícího protisměrné pruhy), na kterém by se zastavili, vydechli si a nabrali sil na překonání další části nebezpečné vozovky. Proto se dnes kolem křižovatek, které potřebují i přechody pro chodce, dělají takové malé, úzké, krátké a nízké celodlážděné ostrůvky se sešikmenými hranami, takže takový ostrůvek jde v pohodě přejet vozidlem (i neHumrem). Mám za to, že takové ostrůvky do OSM nepatří, proto je nemapuju a když na ně narazím, mám chuť je zrušit, cestu narovnat zpět a překomplikovanou křižovatku tak zásadně zjednodušit. Naopak pokud je ostrov delší (stovky metrů), porostlý trávou či jinou zašpiněnou zelení a má poctivý ostrý vysoký obrubník, o který bych si roztrhl pneumatiku jak nic, tak takový do mapy IMHO patří, protože v tom místě U-turn opravdu neudělám. Prosím opravte mě, pokud se mýlím. A jestli je tu Kraken nebo Zubozrout, tak se chystám opravit to rozdvojení tř. Tomáše Bati u křižovatky mezi 51. a 61. budovou, co máte asi na svědomí (dle historie změn, moc ji neumím používat, tak kdyžtak sory). Díky, Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Mám za to, že takové ostrůvky do OSM nepatří, proto je nemapuju a když na ně narazím, mám chuť je zrušit, cestu narovnat zpět a překomplikovanou křižovatku tak zásadně zjednodušit. *** +1 Naopak pokud je ostrov delší (stovky metrů), porostlý trávou či jinou zašpiněnou zelení a má poctivý ostrý vysoký obrubník, o který bych si roztrhl pneumatiku jak nic, tak takový do mapy IMHO patří, protože v tom místě U-turn opravdu neudělám. *** pravděpodobně se jedná o směrově rozdělenou komunikaci, tedy souhlas. h. h. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Kraken tu je, ale na svedomi to nema :D Jinak take si myslim, ze by to melo byt jako jedna cesta :) 2012/7/29 hanoj eha...@gmail.com: Mám za to, že takové ostrůvky do OSM nepatří, proto je nemapuju a když na ně narazím, mám chuť je zrušit, cestu narovnat zpět a překomplikovanou křižovatku tak zásadně zjednodušit. *** +1 Naopak pokud je ostrov delší (stovky metrů), porostlý trávou či jinou zašpiněnou zelení a má poctivý ostrý vysoký obrubník, o který bych si roztrhl pneumatiku jak nic, tak takový do mapy IMHO patří, protože v tom místě U-turn opravdu neudělám. *** pravděpodobně se jedná o směrově rozdělenou komunikaci, tedy souhlas. h. h. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Kdyz uz jsme u tech zmen, co si myslite o tej ceste 49 http://www.openstreetmap.org/?lat=49.20233lon=17.55873zoom=16layers=M Jsou tam oddelene smery a 4 pruhy takze by to podle tejto tabulky http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/roads_tagging#Basic_view_on_the_class_of_ways melo byt jako trunk, ale vzhledem k tomu, ze to je takovy kusek, skoro za mestem a jeste semafor mam sto chuti tam mrdnout primary, mozem se ridit napsanymi pouckami, nebo pouzit zdravy rozum :D 2012/7/29 Tomáš Kratina t.krat...@gmail.com: Kraken tu je, ale na svedomi to nema :D Jinak take si myslim, ze by to melo byt jako jedna cesta :) 2012/7/29 hanoj eha...@gmail.com: Mám za to, že takové ostrůvky do OSM nepatří, proto je nemapuju a když na ně narazím, mám chuť je zrušit, cestu narovnat zpět a překomplikovanou křižovatku tak zásadně zjednodušit. *** +1 Naopak pokud je ostrov delší (stovky metrů), porostlý trávou či jinou zašpiněnou zelení a má poctivý ostrý vysoký obrubník, o který bych si roztrhl pneumatiku jak nic, tak takový do mapy IMHO patří, protože v tom místě U-turn opravdu neudělám. *** pravděpodobně se jedná o směrově rozdělenou komunikaci, tedy souhlas. h. h. ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Tomáš Kratina píše v Ne 29. 07. 2012 v 16:41 +0200: Kraken tu je, ale na svedomi to nema :D Jinak take si myslim, ze by to melo byt jako jedna cesta :) bezva, tu Baťovku teda s gustem narovnám, pak se chystám zjednodušit svou starou křižovatku u vily T. Bati (odbočka na bývalou Aralku) a nakonec zvažuju něco podniknout s tou velkou křižovatkou Pod Babou (pod JS), kterou jsem kdysi nakreslil takto složitě kvůli Navitu (který objížděl bokem semafory) a teď si říkám, že bych neměl být měkký jako Google, který rozdvojuje široké cesty jen aby se nemusel babrat s pravidly pro odbočování na křižovatkách... Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] úzký nízký ostr?vek u k?i?ovatky do mapy nepat?í
Tomáš Kratina píše v Ne 29. 07. 2012 v 22:27 +0200: Kdyz uz jsme u tech zmen, co si myslite o tej ceste 49 http://www.openstreetmap.org/?lat=49.20233lon=17.55873zoom=16layers=M Jsou tam oddelene smery a 4 pruhy takze by to podle tejto tabulky http://wiki.openstreetmap.org/wiki/WikiProject_Czech_Republic/roads_tagging#Basic_view_on_the_class_of_ways melo byt jako trunk, ale vzhledem k tomu, ze to je takovy kusek, skoro za mestem a jeste semafor mam sto chuti tam mrdnout primary, mozem se ridit napsanymi pouckami, nebo pouzit zdravy rozum :D Ta cesta vede od křižovatky u Lídlu u nemocnice až do křižovatky v Otrokovicích-Kvítkovicích - nějakých 15 km - a drtivou většinu je to Primary, tak proč by to ten kousek v polích mělo být jinak... nechal bych Primary. To mi připomíná, že pochybuju o správnosti propojení dvou oddělených směrů u Intersparu v Prštném. Jsou to dvě jednosměrné Primary, k nim se z boku připojuje Residential a propojuje tím Residentialem i oba oddělené směry spolu: http://www.openstreetmap.org/?lat=49.219822883606lon=17.641698718071zoom=18 A teď mi tamtudy OsmAnd odmítl routovat a místo toho mi nabídl U-turn o kousek dál, kde se tř. T. Bati spojuje ve 4 společné pruhy. Zvažuju, že tu propojku těch směrů v křizovatce (kterou jsem původně myslím taky dělal já) změním na Primary. Obecně formulovaný dotaz: pokud vedou dva oddělené směry silnicí typu X a z boku se k nim připojuje silnice typu Y, neměla by být ta propojka mezi oběma X směry taky typu X? Petr ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
On 28.7.2012 23:15, Miroslav Šulc wrote: možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme. Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
Zdravím, metainformace o tom, že se něco nemá importovat z RUIAN, protože je to tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace o tom, odkud konkrétně ta spolehlivější informace pochází. Honza PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé, protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo neodpovídá. Dne 30. července 2012 0:59 Lukas Kohout l...@luko.name napsal(a): On 28.7.2012 23:15, Miroslav Šulc wrote: možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme. Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
On 30.7.2012 1:04, Jan Bilak wrote: Zdravím, metainformace o tom, že se něco nemá importovat z RUIAN, protože je to tam špatně, by podle mě chtělo mít přímo v OSM. A to včetně informace o tom, odkud konkrétně ta spolehlivější informace pochází. Existuje k tomuto účelu nějaký tag zjištěno při procházce se psem? :) Honza PS: Doplňování čp. podle čísla na popelnici nemusí být moc spolehlivé, protože občas někdo popelnici prodá/koupí, ukradne, ... a číslo neodpovídá. Obecně máš asi pravdu. U nás je systém nálepek, které jsou vázané na část obce, č.p. a každý rok se vydávají nové. Bez nálepky popelnici nevyvezou. Cizí nálepka je tedy prakticky vyloučena (musela by být někoho z vesnice). Navíc č.p. sedí do číselné řady v celé ulici. LuKo Dne 30. července 2012 0:59 Lukas Kohoutl...@luko.name napsal(a): On 28.7.2012 23:15, Miroslav Šulc wrote: možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme. Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
Dne 30.7.2012 00:59, Lukas Kohout napsal(a): On 28.7.2012 23:15, Miroslav Šulc wrote: možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme. Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů mezi rúian a osm, kterou mám v plánu udělat. k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých rúian neví? jinak někde na osm wiki jsem četl o tagu bot nebo tak nějak (teď to nemůžu najít). podle mě automaticky spravované adresní body by měly tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde. takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže případné změny (kterých taky asi bude minimum) by se daly zvládat ručně, pokud bude potřeba je do osm zanést. LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz smime.p7s Description: Elektronicky podpis S/MIME ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
Re: [Talk-cz] import budov
On 30.7.2012 2:20, Miroslav Šulc wrote: Dne 30.7.2012 00:59, Lukas Kohout napsal(a): On 28.7.2012 23:15, Miroslav Šulc wrote: možná nejlepší řešení by bylo adresní body naimportovat/zaktualizovat automaticky, akorát případy, kdy už adresní bod existuje a je od toho v rúian vzdálený víc než x jednotek by se řešily poloautomaticky. možná by nebylo špatné napsat si nějaký testovací skript, který by zjistil, jak moc se aktuální data v osm liší od rúian. z toho by se pak dalo ledaco vyčíst. až se mi doimportují osm data do db, tak to můžu zkusit napsat a uvidíme, co tu vlastně řešíme. Zdravím, navrhuji udělat možnost vyřadit oblast z automatického importu/aktualizace. V naší vesnici jsou některé adresní body chybně umístěné, některé chybí úplně. Asi bych nebyl nadšený, kdyby mi je nějaký bot stále dokola automaticky přesouval/mazal (zrovna dnes jsem doplňoval jedno č.p. podle nálepky na popelnici, což je možné jen v neděli večer :) ) chybně umístěné znamená co přesně? posunuté o kolik metrů? podle my bě skript neměl měnit body, které jsou od sebe vzdáleny víc jak x metrů (tj rúian vs osm), ale měl by je někam vypsat. tyhle by se pak museli zkontrolovat ručně. kolik jich bude, by mělo vyplynout z analýzy rozdílů mezi rúian a osm, kterou mám v plánu udělat. k těm chybějícím bodům? znamená to, že tam máte nějaká čp, o kterých rúian neví? Materiály ke zkoumání: http://maps.fordfrog.com/?lat=50.05843lon=15.19497zoom=18layers=0B0FTF (nástroj špatně zpracovává permalink, tedy stejný link pro orientaci: http://www.openstreetmap.org/?lat=50.05843lon=15.19497zoom=18 http://www.openstreetmap.org/?lat=50.05843lon=15.19497zoom=18) - Do pozornosti doporučuji čísla 125, 126, 127, 133, 162 (ty 3 rozestavěné domy u hlavní jsou již minimálně rok obydlené, zítra je obejdu se psem) a ve střední části vesnice pak 16, 7, 9, 10 - tam rúian označuje čísla (zbořených) stodol. Naopak ve vedlejší obci je předchozí import nějak rozházený, něco tam i chybí a tam by změna podle rúian znamenala značné zlepšení: http://maps.fordfrog.com/?lat=50.05772lon=15.21386zoom=18layers=0B0FTF jinak někde na osm wiki jsem četl o tagu bot nebo tak nějak (teď to nemůžu najít). podle mě automaticky spravované adresní body by měly tenhle tag mít. pokud by pak někdo bod přesunul, protože je umístěný špatně, tak by mu ten tag smazal a tím pádem by skript ten bod přestal aktualizovat, max by někam vypsal změny pro daný bod, pokud k nim dojde. takových bodů bude v porovnání s těmi cca třemi miliony minimum, takže případné změny (kterých taky asi bude minimum) by se daly zvládat ručně, pokud bude potřeba je do osm zanést. LuKo ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz ___ Talk-cz mailing list Talk-cz@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-cz
[forum-osm-fr]bloqu� suite a l'imporation du cadastre ( 71000 objets)
Le message suivant de : ## Bonjour à Tous, Cela fait 6 mois que j'importe les petites et moyennes communes de ma zone. J'ai vu qu'il y avait de plus en plus de contributeur, et sachant que c'est bien plus agréable de travailler sur un zone ou les bâtiments du cadastre ont été importé, j'ai proposé au contributeur de mon entourage s'il voulait que j'importe leur commune. En effet, l?importation décrite ici : http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents n'est pas à la portée du premier venu et demande un peu de pratique (génération du fichier, simplification, nettoyage avant import, récupération des tag sur les bâtiments déjà tracé, suppressions de ceux-ci, importation dans OSM) Donc tout allez bien jusqu?à ce que j'importe une commune qui a 71000 objets Je n'ai eu aucun problèmes techniques si ce n'est le temps passé . Et ce matin, je me retrouve Bloqué !!! C'est en fait un avertissement (En anglais !Super! ) qui me débloque à la simple lecture. 1 / il faut créer un autre compte pour l'importation - je ne suis pas d'accord, ce n'est pas un import 100% automatique, j'ai réalisé un travail avec mes mains et mon cerveau, je ne vois pas pourquoi je devrais prendre un autre compte !!! 2/ un modérateur (Anglais ) me contacte et me demande ce que je fais si l'upload échoue. - comme écrit dans le WiKi, je fais par lot de 500 objets, mais cela ne semble pas répondre a la question, qu'il me repose sans cesse. (S'il a la réponse il a qu'a me la dire ...) Donc voila, je copie colle nos échanges afin que certain d'entre-vous me prennent pas une douche froide en contribuant a ce fabuleux projet ( J'ai toujours pas la réponse a mon dernier message, je vous ferais suivre) [quote]Àpnorman Small Objet Re: Revert plans Date29 juillet 2012 à 05:42 On 2012-07-29 05:16:13 UTC pnorman wrote: On 2012-07-29 05:08:50 UTC guiguid wrote: [color=#FF] On 2012-07-29 01:53:42 UTC pnorman wrote: What were your plans for fixing http://www.openstreetmap.org/browse/changeset/12527766 if the upload got interrupted?[/color] [color=#00BF00] Hi pnorman, I only upload big changeset by 500 objects. So using 142 upload requests for this 71000 objects. As you can see, this time the complete changeset was done in 3 times : http://www.openstreetmap.org/browse/changeset/12527766 about 100 x 500 objects upload interrupt http://www.openstreetmap.org/browse/changeset/12528388 about 40 x 500 objects upload interrupt http://www.openstreetmap.org/browse/changeset/12528743 about 10 x 500 objects but without need of fixing anything. have nice day Guillaume[/color] [color=#FF]With that plan if you get your connection interrupted and a response gets lost you can be left with 50k nodes in the database and you can't continue since JOSM doesn't know where to continue from. I've seen it happen multiple times. How would you fix this?[/color] [color=#00BF40] Sorry Pnorman, but I don't understand JOSM doesn't know where to continue from, I'm not a computer Ingenier ... to be clear, I'm importing French Cadastre http://wiki.openstreetmap.org/wiki/Import/Catalogue of my area. http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais this is leagal : http://wiki.openstreetmap.org/wiki/WikiProject_Cadastre_Fran%C3%A7ais/Conditions_d%27utilisation I use the semi-automatic technic described here : http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents It never talks about reverting (only uploading by 500 objects technic) It never talks about dedicated account. In my area there are bigger import of French Cadastre, I don't know how it was done. So I don't know why you continuouly ask me my plans for fixing an hypotetic interrupted upload. As I've folowed all wiki instructions given in http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents So I'm very disappointed by your remarks. If you have the solution, and contact writer of http://wiki.openstreetmap.org/wiki/WikiProject_France/Cadastre/Import_semi-automatique_des_b%C3%A2timents And explain how to process. (sorry for my bad English) Guillaume.[/color][/quote] a été posté sur le forum http://forum.openstreetmap.fr/viewforum.php?f=5 Une réponse par mail sur l'adresse d'expédition n'arrivera nulle part Une réponse à la liste ne sera pas transmise au forum, ce qui n'empêche pas une concertation sur la liste avant de recopier la/les meilleurs réponses sur le forum. Notez qu'il n'est pas necessaire d'avoir un compte sur le forum pour répondre. -- Les questions sur ce robot de transfert forum-liste peuvent être posées à
Re: [OSM-talk-fr] Nom des établissements scolaires
Le 28/07/2012 23:25, Vincent de Chateau-Thierry a écrit : Bonsoir, Le 28/07/2012 17:09, Agnès Rambaud a écrit : Le 23/07/2012 20:18, Christian Quest a écrit : Eventuellement Osmose ? http://osmose.openstreetmap.fr/map/?item=8030level=1,2,3 Justement, tiens, c'est pile chez moi ça. Je suppose par ici : http://osmose.openstreetmap.fr/map/?zoom=17lat=45.33871lon=5.97513layers=BFF0FTTitem=8030level=1,2,3 ? oui, c'est bien ça ;) Et je vois qu'en plus, c'est un peu la zone sur le collège en particulier : - y'a le name collège Icare sur une partie des bâtiments (mais pas la cantine par exemple, bien qu'elle fasse partie du périmètre) - il y est aussi sur l'emprise extérieure (l'aire délimitant l'emprise du collège) - et il y est encore une fois sur les données à intégrer. De mon point de vue, c'est au moins deux fois de trop non ? Alors ça serait quoi la règle pour rendre tout cela un peu plus harmonieux ? Pour ma part, je trouvais plus logique d'avoir les informations sur l'aire de l'emprise du collège - qui comprend tous les bâtiments plutôt que sur un point posé sur le bâtiment. Mon idée serait donc de compléter les tags présents sur l'aire avec ceux à intégrer, et supprimer ce point (ou ne pas l'importer, j'ai pas encore très bien pigé comment ça marche ce système d'intégration). On dirait bien qu'entre temps tu as suivi ton idée, pas de souci. Pour les points à intégrer, il faut en effet faire son marché parmi les tags qu'ils offrent, et ne pas créer de doublon, comme tu l'as noté. Ainsi : - emmener dans JOSM un point à intégrer, - puis prendre certains de ses tags, - les appliquer à un existant (point ou polygone) - enfin supprimer le point nouvel objet est une manip tout à fait normale. Les infos du point sont intégrées, pas le point lui-même. Merci pour les explications détaillées. C'est bien clair. Et question subsidiaire : quand on a une source terrain et une source officielle genre le ministère, on peut garder les deux sources ? (non parce qu'à force d'importer des trucs, va plus rien rester de ce que j'ai mis moi ;-) Le point-virgule est utile ici pour séparer les valeurs de source, par exemple : survey;data.gouv.fr:Ministère de l'Éducation nationale, de la Jeunesse et de la Vie associative - 05/2012 Survey, c'est l'équivalent d'observation, c'est ça ? vincent Agnès ___ 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] Nom des établissements scolaires
Le 29 juillet 2012 11:26, Agnès Rambaud agnesramb...@free.fr a écrit : Survey, c'est l'équivalent d'observation, c'est ça ? Ce sont nos relevés sur le terrain. survey: Geog (map) (of land) levé m topographique; source: http://www.wordreference.com/enfr/survey -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
Le 28/07/2012 08:05, Stéphane Henriod a écrit : .. Nous avons acheté et mis en ligne une image haute résolution de la ville de Khorog. Bonjour ! Je trouve l'idée intéressante, et, ayant un peu contribué à ce projet je cherche à présent qui est ce Nous ? la page citée pointe sur les projets HOT, mais dans l'autre sens, les projets HOT ne le référencent pas. Le contributeur japonais indique Hot #44 ; où est décris ce projet ? Merci ! Hélène ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] les mosquées de france
Bonjour, Pour information, @logisima a développé un outil pour géolocaliser des points sur fond de carte OSM à partir de simples csv (équivalent batchgeo.com pour OSM), contributeurs bienvenus. Un outil que l'on va promouvoir sur Nantes pour (enfin) répondre à la problématique d'usage d'OSM par les non devs :) Voir la démo: http://csvmap.logisima.com/carte/b41f8df7-273f-46b8-95e8-888a0af90d82 Peut-être un bon outil pour inciter certains sites à migrer. Claire @libertic Le 28 juillet 2012 09:28, Christian Quest cqu...@openstreetmap.fr a écrit : Si le positionnement des mosquées a été fait à l'aide d'un service offert par Google, je crains que l'on ne tombe dans la notion de produits dérivé. On en a parlé plus d'une fois. Voici un extrait des condition d'utilisation actuelles de Google Maps: http://www.google.com/intl/fr_fr/help/terms_maps.html Les données de géocodage qui s'appliquent au contenu cartographique de Google Maps sont fournies sous couvert d'une licence Navteq North America LLC (NAVTEQ) et/ou Tele Atlas North America, Inc. (TANA) et/ou d'autres tiers. Elles font l'objet d'une protection du copyright et des autres droits de propriété intellectuelle détenus par ou concédés sous licence à NAVTEQ, TANA et/ou lesdits tiers. L'utilisation de ces informations est régie par un accord de licence. Vous pouvez être tenu pour responsable de toute copie ou divulgation non autorisée de ces informations. En utilisant Google Maps, vous acceptez d'étendre cet accord à NAVTEQ et TANA. Sauf spécification contraire définie dans les termes de la licence octroyée par Google, vous n'êtes pas autorisé à utiliser Google Maps avec quelque produit, système ou application que ce soit, installé dans/ou connecté à/ou en communication avec des véhicules ou toute application de navigation routière, de géo-positionnement, de routage, de guidage routier en temps réel, de gestion d'un parc de véhicules ou tout système similaire. En gros, on est lié par des accords dont on ne connait même pas vraiment la nature, et on n'a pas le droit de faire grand chose. -- Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest ___ 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] Tag d'une intersection avec priorité à droite ?
2012/7/27 panierAvide panierav...@laposte.net: S'il n'existe aucun tag approprié, quelle serait la meilleure solution ? Quelqu'un connait un logiciel de routage qui signale les priorités ? Pieren ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
[OSM-talk-fr] Données de la Communauté de Commune de Concarneau Cornouaille (CCCC)
Bonjour, Je vais vous parler de mes vacances... si si... mais pas que... un peu d'OSM aussi ;-) Je suis arrivé à Concarneau il y a une semaine avec une motivation supplémentaire par rapport aux années précédentes : cartographier mon lieu de vacances. Lorsque je suis revenu de ma première sortie en course à pied, avec trace GPS et force photos des barrières, chemins, boîte aux lettres..., je me suis précipité sur mon JOSM histoire de mettre à jour ou de créer de nouveaux objets... et là c'est le drame. Impossible d'ajouter quoi que ce soit... tout y était... pire, en mieux que ce que j'aurais fait !! Après quelques recherche pour trouver le responsable de tout ça je suis tombé sur la page de documentationhttp://wiki.openstreetmap.org/wiki/WikiProject_France/Donn%C3%A9es_de_la_Communaut%C3%A9_de_Communes_de_Concarneau_Cornouaillede l'import des données. Tout est détaillé sur la manière utilisée pour importer les données... génial (Merci Marc Sibert). Sur le terrain les données sont détaillées et de très bonne qualité. Bref tout ça pour dire que c'est du très bon boulot tout ça. Deux questions pour ceux qui auront le courage de lire le message jusqu'au bout : - Savez vous si la utilise les données d'OSM (et donc les contributions) pour alimenter son SIG. - Quid de la mise à jour des données qui proviennent de la Communauté de commune ? Comment est-ce géré, même process que l'import de base ? Voilà. @+++ ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
Bonjour Hélène j'ai vu que vous avez participé très rapidement et efficacement, merci! Ce nous est presque un peu abusif pour l'instant ;-) je m'explique... J'ai habité et travaillé plus de 2 ans dans la région et, bien que maintenant de retour en Suisse, j'ai gardé beaucoup de liens, et une envie de continuer à faire 2-3 choses que j'espère utiles. Le Tadjikistan est un pays très exposé aux catastrophes naturelles et souffre d'un manque chronique de données sptatiales et de cartes (qui sont critiques, tant pour la prévention que pour la réponse aux catastrophes). Mon idée (avec l'aide de 2-3 amis et ex-collègues là-bas) est d'utiliser le cas de Khorog pour démontrer à quel point le crowdsourcing (et plus spécifiquement OSM) peut offrir des solutions rapides, efficaces et de qualité pour créer et mettre à disposition les données nécessaires dans le cadre de projet de DRR (Disaster Risk Reduction). Une fois que la ville sera cartographiée, j'essaierai de faire quelques simulations d'analyse de risques, en croisant les données OSM (bâtiments, routes) avec d'autres données libres (population, DEM...). Une fois ces simulations réalisées, j'essaierai d'aller les vendre chez différents acteurs sur place. (NB: pas vendre financièrement... car je ne compte retirer absolument aucun intérêt financier de ce projet!). Les tragiques évènements de cette semaine m'ont juste fait accélérer le processus car il est probable que les activités humanitaires de ces prochains jours / semaines nécessiteront les données que vous avez généreusement contribué à créer. C'est pour cela que le nous est abusif: je ne suis ni ne représente une organisation ou association formelle, mais juste un petit groupe de personnes croyant aux bienfaits de certaines nouvelles technologies pour le monde humanitaire... En ce qui concerne HOT, c'est bien juste, ce projet n'est pas officiellement un projet HOT, mais va dans la même direction et a été développé avec le soutien et les conseils de divers membres actifs. Le tasking manager par exemple, que j'utilise pour coordonner ce projet, est un produit de HOT. D'une façon générale, ce projet s'inscrit dans: http://wiki.openstreetmap.org/wiki/Tajikistan (ou il y a des infos si vous voulez mapper des zones encore plus reculées du Tadjikistan!) et dans http://wiki.openstreetmap.org/wiki/OpenHazardMap J'espère que j'ai répondu à vos questions, mais n'hésitez pas si vous en avez d'autres! :-) Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info 2012/7/29 Hélène PETIT h...@free.fr Le 28/07/2012 08:05, Stéphane Henriod a écrit : .. Nous avons acheté et mis en ligne une image haute résolution de la ville de Khorog. Bonjour ! Je trouve l'idée intéressante, et, ayant un peu contribué à ce projet je cherche à présent qui est ce Nous ? la page citée pointe sur les projets HOT, mais dans l'autre sens, les projets HOT ne le référencent pas. Le contributeur japonais indique Hot #44 ; où est décris ce projet ? Merci ! Hélène __**_ 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] Tag d'une intersection avec priorité à droite ?
Le 29 juillet 2012 22:08, Pieren pier...@gmail.com a écrit : 2012/7/27 panierAvide panierav...@laposte.net: S'il n'existe aucun tag approprié, quelle serait la meilleure solution ? Quelqu'un connait un logiciel de routage qui signale les priorités ? A ma connaissance je n'ai jamais vu que l'indication des stops et des cédez-le-passage, ainsi que des rond-points pour la priorité à gauche, et les feux, les zones de non-dépassement, les zones de rabattement, les changements de voie interdits, et les rues à circulation alternée. Pour le reste rien n'est annoncé sur les navigateurs pour toutes les autres intersections où la priorité à droite s'applique par défaut. [OT: note pour raller] ces circulations alternées, pas toujours avec une priorité affichée dans un sens ou l'autre, et sans feux non plus. Par exemple dans la plupart des rues résidentielles à Niort, que tu dois connaître, où on fait maintenant du slalom partout entre les stationnements à droite ET à gauche dans une rue à double sens où il n'y a pas de place pour stationner des deux côtés, ni pour curculer sur deux voies, et pas toujours non plus de place pour se mettre en attente, ce qui oblige parfois à faire des marches arrière ! Ce qui n'est pas affiché non plus sur les navigateurs commerciaux avec leurs mises à jour : Tomtom, Mio Navman, Via Michelin, Garmin, ni même sur Google Maps en mode connecté, car nombre de ces rues ont été récemment aménagées ainsi exprès pour emm...der les automobilistes... et même les conducteurs de bus : dans ma rue déjà 3 bus accidentés qui ont soit accroché un panneau signalant l'îlot, soit se sont plantés sur les plots métalliques, soit ont défoncé les ailes de véhicules garés sur ces nouveaux emplacements de stationnement gênants et dangereux, créés en même temps qu'on ferme les autres parkings. Et pourtant de nouvelles rues continuent à être aménagées comme ça un peu partout... ça fait les affaires des carrossiers, mais pas des assurances qui maintenant montent leurs tarifs ou refusent la prise en charge de ces accrochages ! Si tu as visité le nouveau parking souterrain de la Brêche, là aussi les plots séparant les énormes allées latérales pour piétons, aux extrémités des allées où on est obligé de tourner à 180 degrés en parcourant toutes les allées, étaient défoncés dès le premier jour à cause du rayon de braquage imposé beaucoup trop serré. Pas moyen de tourner sans casse si on n'utilise pas une marche arrière en contrebraquant. Là aussi, pas de priorité puisque les véhicules ont un chemin unique de l'entrée à la sortie qui fait ces zig-zags sur plusieurs niveaux. Quand on y entre, il ne faut plus être pressé de ressortir à cause d'un véhicule coincé dans le passage. Mais bon, dans cette région (aussi dans la majeure partie de la Vendée), les conducteurs ne savent pas ce qu'est une priorité, ne mettent jamais les clignotants, forcent l'entrée dans tous les rond-points, il ne faut pas s'étonner que l'on aménage pour qu'il n'y ait plus aucune priorité à respecter... Mais ils peuvent rouler pendant 20 kilomètres à 60 km/h sur une route toute droite sans dépassement limitée à 90 km/h et freiner encore à l'approche d'un radar... Mais toujours pas de cligno non plus quand ils dépassent un vélo ou un piéton qui marche le long de la voie. Ils conduisent tous comme s'ils étaient à vélo (les cyclistes non plus ne signalent pas leur intention de tourner à gauche, ils changent de file sans prévenir, les piétons ne regardent pas non plus pour traverser, il ne faut pas avoir besoin de la voiture dans le coin, mais ça ne les gène pas de ne jamais sortir de chez eux). [/OT: note pour raller] ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
Le 29 juillet 2012 22:42, Stéphane Henriod s...@henriod.info a écrit : A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier J'aime bien la citation, car c'est ce qui me motive d'abord quand je voyage ou me balade : je n'aime pas prévoir à l'avance ce que je vais faire ou voir. Je me dis juste que je n'y pas encore allé ou pas depuis longtemps. Je ne fixe pas non plus de durée obligatoire quelque part. J'aime bien juste voir ce qu'il y a autour au moment où j'arrive. L'intérêt du voyage c'est le voyage lui-même, le fait qu'on sort de chez soi (même si on s'y sent bien), et le plaisir aussi de rentrer... Et pas besoin de voir grand chose, c'est de voir et entendre les gens qui y vivent (ou qui y viennent) qui est le plus intéressant. Le cocooning est une épidémie moderne rampante que personne ne veut soigner, quand on ne voit pas qu'on s'enferme dans sa propre prison virtuelle. ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
[mode hors-sujet ON] Content que cette citation t'aie plue! Si ce n'est pas encore fait, je te recommande vivement les bouquins de Nicolas Bouvier, qui sont à 200% dans cet esprit... Ceux d'Ella Maillart aussi d'ailleurs... [mode hors-sujet OFF] Et le Tadjikistan est un pays merveilleux pour voyager sans planifier et pour se laisser surprendre... Mais pour en profiter à fond, tu seras quand même parfois content d'avoir des bonnes cartes... alors n'hésite pas à nous donner un coup de main si tu as le temps et l'envie ;-) Stéphane -- Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux -- Albert Einstein A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier Photos de voyages, photos de montagne: http://www.henriod.info 2012/7/29 Philippe Verdy verd...@wanadoo.fr Le 29 juillet 2012 22:42, Stéphane Henriod s...@henriod.info a écrit : A journey does not need reasons. Before long, it proves to be reason enough in itself. One thinks that one is going to make a journey, yet soon it is the journey that makes or unmakes you. -- Nicolas Bouvier J'aime bien la citation, car c'est ce qui me motive d'abord quand je voyage ou me balade : je n'aime pas prévoir à l'avance ce que je vais faire ou voir. Je me dis juste que je n'y pas encore allé ou pas depuis longtemps. Je ne fixe pas non plus de durée obligatoire quelque part. J'aime bien juste voir ce qu'il y a autour au moment où j'arrive. L'intérêt du voyage c'est le voyage lui-même, le fait qu'on sort de chez soi (même si on s'y sent bien), et le plaisir aussi de rentrer... Et pas besoin de voir grand chose, c'est de voir et entendre les gens qui y vivent (ou qui y viennent) qui est le plus intéressant. Le cocooning est une épidémie moderne rampante que personne ne veut soigner, quand on ne voit pas qu'on s'enferme dans sa propre prison virtuelle. ___ 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] Données de la Communauté de Commune de Concarneau Cornouaille (CCCC)
Le 29 juillet 2012 22:15, Eric Pommereau eric.pommer...@gmail.com a écrit : Deux questions pour ceux qui auront le courage de lire le message jusqu'au bout : Savez vous si la utilise les données d'OSM (et donc les contributions) pour alimenter son SIG. Quid de la mise à jour des données qui proviennent de la Communauté de commune ? Comment est-ce géré, même process que l'import de base ? Visiblement il y a quelqu'un (ou plusieurs personnes) de la (ou dans un des services municipaux impliqués dans le projet de la ) qui participe de concert ici dans OSM et dans le SIG. Qui corrige des tas de trucs, jusque même les fautes d'orthographe sur les noms bretons pas évidents pour tout le monde. Si on avait une telle implication des communautés de communes ailleurs, ce serait le paradis : - Il y a des gros manques en Haute-Normandie, pourtant qui est très peuplée et ne manque pas de moyens en comparaison de la Basse-Normandie mieux lotie ; - et aussi en Champagne-Ardenne et les arrière-pays lorrain et corse, des régions qui manquent de moyens, se dépeuplent et ressemblent dans OSM à des déserts qui semblent n'intéresser pas grand monde ; - aussi dans le Nord et en Alsace à cause de la grande densité d'informations qu'il faudrait avoir mais qui sont compliquées à ajouter dans OSM où il faudrait plus de monde, mais leurs communes sont relativement petites en surface et très nombreuses, ça fait peut-être que c'est compliqué pour les mettre d'accord entre elles au sein de leurs CC). Pour ces zones mal loties, il faudrait trouver plus d'implication des départements ou des régions, voire une aide de la part des services géographiques nationaux ou de l'UE (ou même des collaborations techniques avec les SIG d'autres régions ou les assos et services des villes jumelées). ___ Talk-fr mailing list Talk-fr@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
Le 28/07/2012 08:05, Stéphane Henriod a écrit :
L'image est accessible en TMS ici:
http://humadat.alwaysdata.net/tms/khorog/{zoom}/{x}/{-y}.jpg
http://humadat.alwaysdata.net/tms/khorog/%7Bzoom%7D/%7Bx%7D/%7B-y%7D.jpg
[Comment ajouter une image TMS dans JOSM:
http://josm.openstreetmap.de/wiki/Help/Preferences/Imagery ]
j'arrive pas a voir l'image, il me met systematiquement Erreur:
http://humadat.alwaysdata.net/tms/khorog/2 chiffres/des
chiffres/des chiffres.jpg
j'ai essaye en zoomant ou dezoomant
j'ai essaye de virer le - avant y
j'ai essaye les 2 adresses donnees (celle avec les accolades et celle
avec les %7B et %7D)
rien n'y fait
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr
Re: [OSM-talk-fr] Aidez à mettre sur OSM des zones vierges du Tadjikistan
Tu es bien dans JOSM? Avec Potlatch, j'ai pas réussi non plus...
Pour moi ça marche correctement dans JOSM, avec l'URL suivante:
http://humadat.alwaysdata.net/tms/khorog/tiles/{zoom}/{x}/{-y}.jpg
(le - est nécessaire... Je ne sais plus le pourquoi du comment, mais je
crois que c'est parce que JOSM ne regarde pas les coordonnées dans le même
sens que le standard TMS... mais peut-être qu'un spécialiste peut me
corriger si c'est faux?)
Là je vais me coucher, mais dis moi si ça ne fonctionne toujours pas et
j'essayerai de regarder demain!
merci de ton intérêt!
Stéphane
--
Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux
-- Albert Einstein
A journey does not need reasons. Before long, it proves to be reason
enough in itself. One thinks that one is going to make a journey, yet soon
it is the journey that makes or unmakes you. -- Nicolas Bouvier
Photos de voyages, photos de montagne: http://www.henriod.info
2012/7/29 hamster hams...@suna.fdn.fr
Le 28/07/2012 08:05, Stéphane Henriod a écrit :
L'image est accessible en TMS ici:
http://humadat.alwaysdata.net/**tms/khorog/{zoom}/{x}/{-y}.jpghttp://humadat.alwaysdata.net/tms/khorog/%7Bzoom%7D/%7Bx%7D/%7B-y%7D.jpg
http://humadat.alwaysdata.**net/tms/khorog/%7Bzoom%7D/%**
7Bx%7D/%7B-y%7D.jpghttp://humadat.alwaysdata.net/tms/khorog/%7Bzoom%7D/%7Bx%7D/%7B-y%7D.jpg
[Comment ajouter une image TMS dans JOSM:
http://josm.openstreetmap.de/**wiki/Help/Preferences/Imageryhttp://josm.openstreetmap.de/wiki/Help/Preferences/Imagery]
j'arrive pas a voir l'image, il me met systematiquement Erreur:
http://humadat.alwaysdata.net/**tms/khorog/http://humadat.alwaysdata.net/tms/khorog/2
chiffres/des chiffres/des chiffres.jpg
j'ai essaye en zoomant ou dezoomant
j'ai essaye de virer le - avant y
j'ai essaye les 2 adresses donnees (celle avec les accolades et celle avec
les %7B et %7D)
rien n'y fait
__**_
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] Aidez à mettre sur OSM des zones vierges du Tadjikistan
PS: je vais peut-être dire un truc débile, mais l'image qui est référencée
par le lien ci dessous couvre uniquement la ville de
Khoroghttp://www.openstreetmap.org/?lat=37.4914lon=71.5517zoom=14layers=Mau
Tadjikistan. Ca veut dire que, si tu es actuellement, dans JOSM,
n'importe où ailleurs dans le monde, il te répondra qu'il ne trouve pas les
tiles correspondantes.
Et désolé si ce conseil à 0.02€ était trop évident...
--
Le mot progrès n'aura aucun sens tant qu'il y aura des enfants malheureux
-- Albert Einstein
A journey does not need reasons. Before long, it proves to be reason
enough in itself. One thinks that one is going to make a journey, yet soon
it is the journey that makes or unmakes you. -- Nicolas Bouvier
Photos de voyages, photos de montagne: http://www.henriod.info
2012/7/29 hamster hams...@suna.fdn.fr
Le 28/07/2012 08:05, Stéphane Henriod a écrit :
L'image est accessible en TMS ici:
http://humadat.alwaysdata.net/**tms/khorog/{zoom}/{x}/{-y}.jpghttp://humadat.alwaysdata.net/tms/khorog/%7Bzoom%7D/%7Bx%7D/%7B-y%7D.jpg
http://humadat.alwaysdata.**net/tms/khorog/%7Bzoom%7D/%**
7Bx%7D/%7B-y%7D.jpghttp://humadat.alwaysdata.net/tms/khorog/%7Bzoom%7D/%7Bx%7D/%7B-y%7D.jpg
[Comment ajouter une image TMS dans JOSM:
http://josm.openstreetmap.de/**wiki/Help/Preferences/Imageryhttp://josm.openstreetmap.de/wiki/Help/Preferences/Imagery]
j'arrive pas a voir l'image, il me met systematiquement Erreur:
http://humadat.alwaysdata.net/**tms/khorog/http://humadat.alwaysdata.net/tms/khorog/2
chiffres/des chiffres/des chiffres.jpg
j'ai essaye en zoomant ou dezoomant
j'ai essaye de virer le - avant y
j'ai essaye les 2 adresses donnees (celle avec les accolades et celle avec
les %7B et %7D)
rien n'y fait
__**_
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
[OSM-ja] [ODbL] 8月4日のOSC京都での発表とスライド資料に関して(Re: 7/29(日)ODbL勉強会開催のお知らせ（予告）→正式告知)
とし＠帰りの新幹線の中からです。 本日のODbL勉強会の資料です。 プレゼン資料 http://www.slideshare.net/higa4/20120729-odbl ライセンス対訳 https://docs.google.com/a/osmf.jp/file/d/0BxvlrTvfS0RAN01oZ1dJa3g0aUU/edit?pli=1 清野さんはじめ、関西OSMの皆さん： 8月4日のOSC京都でのOSMセミナー枠ですが、今日29日の ODｂL勉強会の報告と言いますか、 * 7月29日のODbL 勉強会でこれこれこういう話があって、 * これこれこういう議論が交わされた 事を、セミナー枠の中でお話させて頂けないかと思っています。 時間は、大体20分くらいを頂けたらと考えているのですが、 セミナー枠での時間20分ほど頂けませんでしょうか？ 東さん： 8月4日のOSC京都でのセミナー枠で、上記スライドを使わせて 頂けませんでしょうか？ ... ODｂLは、今後私達の活動にとって重要なもので、その中で特に 「データベース権」と言うのは日本には馴染みのない概念ですので、 今後も様々な議論が出ると思います。 今日の勉強会で、私自身まだ ODbL の理解が至らないなと思いました。 日本の各地方のOSMer が ODbL について理解を進め、愉しく地図を 作ることが出来れば :-) と思っています。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [ODbL] 8月4日のOSC京都での発表とスライド資料に関して(Re: 7/29(日)ODbL勉強会開催のお知らせ（予告）→正式告知)
清野です。 としさん、ありがとうございます。 ぜひともよろしくお願い致します。 本日の勉強会は僕も参加したくてできませんでしたので、 僕自身もぜひ聞きたいです。 時間は何分でも結構です。 何卒よろしくお願い致します。 2012年7月29日 21:18 TANAKA Toshihisa tosih...@netfort.gr.jp: とし＠帰りの新幹線の中からです。 本日のODbL勉強会の資料です。 プレゼン資料 http://www.slideshare.net/higa4/20120729-odbl ライセンス対訳 https://docs.google.com/a/osmf.jp/file/d/0BxvlrTvfS0RAN01oZ1dJa3g0aUU/edit?pli=1 清野さんはじめ、関西OSMの皆さん： 8月4日のOSC京都でのOSMセミナー枠ですが、今日29日の ODｂL勉強会の報告と言いますか、 * 7月29日のODbL 勉強会でこれこれこういう話があって、 * これこれこういう議論が交わされた 事を、セミナー枠の中でお話させて頂けないかと思っています。 時間は、大体20分くらいを頂けたらと考えているのですが、 セミナー枠での時間20分ほど頂けませんでしょうか？ 東さん： 8月4日のOSC京都でのセミナー枠で、上記スライドを使わせて 頂けませんでしょうか？ ... ODｂLは、今後私達の活動にとって重要なもので、その中で特に 「データベース権」と言うのは日本には馴染みのない概念ですので、 今後も様々な議論が出ると思います。 今日の勉強会で、私自身まだ ODbL の理解が至らないなと思いました。 日本の各地方のOSMer が ODbL について理解を進め、愉しく地図を 作ることが出来れば :-) と思っています。 ではこれにて。 ___ 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] [ODbL] 8月4日のOSC京都での発表とスライド資料に関して(Re: 7/29(日)ODbL勉強会開催のお知らせ（予告）→正式告知)
とし＠帰宅しましたです。 清野さん、ありがとうございます。時間ですが、話15分＋質問5分で 20分頂けたらと思っています。どうぞよろしくお願いします。 ではこれにて。 2012年7月29日 21:25 Yoichi SEINO say.n...@gmail.com: 清野です。 としさん、ありがとうございます。 ぜひともよろしくお願い致します。 本日の勉強会は僕も参加したくてできませんでしたので、 僕自身もぜひ聞きたいです。 時間は何分でも結構です。 何卒よろしくお願い致します。 2012年7月29日 21:18 TANAKA Toshihisa tosih...@netfort.gr.jp: とし＠帰りの新幹線の中からです。 本日のODbL勉強会の資料です。 プレゼン資料 http://www.slideshare.net/higa4/20120729-odbl ライセンス対訳 https://docs.google.com/a/osmf.jp/file/d/0BxvlrTvfS0RAN01oZ1dJa3g0aUU/edit?pli=1 清野さんはじめ、関西OSMの皆さん： 8月4日のOSC京都でのOSMセミナー枠ですが、今日29日の ODｂL勉強会の報告と言いますか、 * 7月29日のODbL 勉強会でこれこれこういう話があって、 * これこれこういう議論が交わされた 事を、セミナー枠の中でお話させて頂けないかと思っています。 時間は、大体20分くらいを頂けたらと考えているのですが、 セミナー枠での時間20分ほど頂けませんでしょうか？ 東さん： 8月4日のOSC京都でのセミナー枠で、上記スライドを使わせて 頂けませんでしょうか？ ... ODｂLは、今後私達の活動にとって重要なもので、その中で特に 「データベース権」と言うのは日本には馴染みのない概念ですので、 今後も様々な議論が出ると思います。 今日の勉強会で、私自身まだ ODbL の理解が至らないなと思いました。 日本の各地方のOSMer が ODbL について理解を進め、愉しく地図を 作ることが出来れば :-) と思っています。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [ODbL] 8月4日のOSC京都での発表とスライド資料に関して(Re: 7/29(日)ODbL勉強会開催のお知らせ（予告）→正式告知)
としさん 資料はどうぞお使いください。 ただ、本日の議論を踏まえて差し替え版を作るつもりです。 でき次第差し替える予定ですが、いつできるかまだよくわからないのでosc関西で、どの版を使うかはお任せします。 東 2012年7月29日日曜日 TANAKA Toshihisa tosih...@netfort.gr.jp: とし＠帰宅しましたです。 清野さん、ありがとうございます。時間ですが、話15分＋質問5分で 20分頂けたらと思っています。どうぞよろしくお願いします。 ではこれにて。 2012年7月29日 21:25 Yoichi SEINO say.n...@gmail.com: 清野です。 としさん、ありがとうございます。 ぜひともよろしくお願い致します。 本日の勉強会は僕も参加したくてできませんでしたので、 僕自身もぜひ聞きたいです。 時間は何分でも結構です。 何卒よろしくお願い致します。 2012年7月29日 21:18 TANAKA Toshihisa tosih...@netfort.gr.jp: とし＠帰りの新幹線の中からです。 本日のODbL勉強会の資料です。 プレゼン資料 http://www.slideshare.net/higa4/20120729-odbl ライセンス対訳 https://docs.google.com/a/osmf.jp/file/d/0BxvlrTvfS0RAN01oZ1dJa3g0aUU/edit?pli=1 清野さんはじめ、関西OSMの皆さん： 8月4日のOSC京都でのOSMセミナー枠ですが、今日29日の ODｂL勉強会の報告と言いますか、 * 7月29日のODbL 勉強会でこれこれこういう話があって、 * これこれこういう議論が交わされた 事を、セミナー枠の中でお話させて頂けないかと思っています。 時間は、大体20分くらいを頂けたらと考えているのですが、 セミナー枠での時間20分ほど頂けませんでしょうか？ 東さん： 8月4日のOSC京都でのセミナー枠で、上記スライドを使わせて 頂けませんでしょうか？ ... ODｂLは、今後私達の活動にとって重要なもので、その中で特に 「データベース権」と言うのは日本には馴染みのない概念ですので、 今後も様々な議論が出ると思います。 今日の勉強会で、私自身まだ ODbL の理解が至らないなと思いました。 日本の各地方のOSMer が ODbL について理解を進め、愉しく地図を 作ることが出来れば :-) と思っています。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] [ODbL] 8月4日のOSC京都での発表とスライド資料に関して(Re: 7/29(日)ODbL勉強会開催のお知らせ（予告）→正式告知)
東さん： としです。 2012年7月29日 23:13 Shu Higashi s_hig...@mua.biglobe.ne.jp: としさん 資料はどうぞお使いください。 ただ、本日の議論を踏まえて差し替え版を作るつもりです。 でき次第差し替える予定ですが、いつできるかまだよくわからないのでosc関西で、どの版を使うかはお任せします。 資料、ありがとうございます。差し替え版についても了解しましたです。 ではこれにて。 ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [OSM-ja] 「OpenStreetMap北陸」開設のお知らせ
遅くなりましたが、宇野さん、ようこそosmへ。 北陸はまだ描かれていないところが多いようなので、やり甲斐がありそうですね。 ぜひマッピングを楽しんでください。 東 2012年7月29日日曜日 虹プロ 2gpros...@gmail.com: 初めまして、福井の宇野(unotecjapan)と申します。 つい先ほど、「OpenStreetMap北陸」というGoogleGroupを開設いたしましたので、 ご報告させていただきます。 http://groups.google.co.jp/group/OSM-Hokuriku 私のOSMでの活動暦ですが・・・ OSMのことを知ったのが一昨日。 昨日OpenStreetMapセミナー 名古屋に初参加。 本日のOpenStreetMapワークショップ IN 名古屋#3でのハンズオンが初マッピングと、これ以上ないくらい新米中の新米です。 都市部と比較しての北陸地区の未整備ぶりを嘆き、若輩もいいところですがコミュニティを開設いたしました。 私の実家を道路が貫いていたのもショックでした・・・(直しました) 9月頃に北陸地区でマッピングパーティーを開催することを目標に、まずは布教活動から始めていこうと思っております。 そして何よりも、コミュニティを立ち上げたものの企画倒れで終わらないことですね。 ちなみに8/3-4に行われるOSC京都ですが、8/3は参加出来ませんが、8/4には別のグループのプロジェクトで顔を出す予定です。 是非OSMのブースにも足を運び勉強させていただきたいと思っておりますので、よろしくお願い致します。 宇野泰行(Yasuyuki Uno) 2gpros...@gmail.com OpenStreetMap HN:unotecjapan twitter:@unotecjapan ___ Talk-ja mailing list Talk-ja@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-ja
Re: [Talk-us] Discardable TIGER tags
Ok well so far I see no opposition to deleting tiger:upload_uuid. I might go ahead and work on some code for this. Other than that we have some votes for keeping tiger:county, tiger:zip and tiger:separated although I personally still have it in for tiger:separated :) Any thoughts on tiger:source? I'm not quite sure what the value represents so I'm still on the fence about it. Toby ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
[Talk-us] Kern County Import Cleanup
I happened to be looking at Kern County and noticed two problems with the imports that seem to be systemic over the area. The first is classification of empty areas as landuse=residential (e.g. http://www.openstreetmap.org/browse/relation/540695 http://www.openstreetmap.org/browse/way/53993995) I'd suggest deleting these as no landuse appears to appropriate here The second is a similar issue, mountainside areas in landuse=farm (e.g. http://www.openstreetmap.org/?lat=35.26lon=-118.47zoom=14) While doing this cleanup I would suggest removing attribution, description, kern:Comb_Zn, kern:Zn_Cd1 and setting source=Kern_County_GIS The appropriate solution for most of the ways/multipolygons seems to be to delete them, but I'll leave this to you since you're familiar with the extents of the upload. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Kern County Import Cleanup
At 2012-07-29 00:30, Paul Norman wrote: While doing this cleanup I would suggest removing attribution, description, kern:Comb_Zn, kern:Zn_Cd1 and setting source=Kern_County_GIS There might be some objects that have been edited, so you'll want to add ;Kern_County_GIS if there is an existing source tag. Are they all http://www.co.kern.ca.us/gis/Files/CountyZoning.zip;, or were there multiple types of data involved? Maybe append the year and month of the file that was imported to the value, too (e.g. Kern_County_GIS_Zones_200810). I'm all for shortening/abbreviating values that are not meant to be rendered (well, I'd be ok with some abbreviation in names, too, but that's a different issue :) ). In particular, it seems a needless waste of space to have these long descriptive source values repeated on every object of an import. It makes more sense to me to document a source on the wiki page for the source tag and use a reasonable abbreviation for it. For example, in one particular excerpt (of source values with commas), the source value EarthScope (http://www.earthscope.org),International Solar Information Solutions (http://www.isi-solutions.org),OpenTopography (http://www.opentopography.org) appears on at least 4000 objects instead of something more reasonable like EarthScope;ISIS;OpenTopo. Defining source values in the wiki would also give one a chance to document details, like the date of the data, research on copyright status, etc. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] [Imports] Kern County Import Cleanup
At 2012-07-29 01:04, Toby Murray wrote: And then we end up with things that are off by 15-20 meters and look crappy: http://www.openstreetmap.org/?lat=34.95455lon=-118.16858zoom=16layers=M It looks like the landuses are shifted by about 28m at 126 degrees from Bing z19 dated 05/08/2010-08/31/2010, but I don't have a ref for the accuracy of Bing exactly there. In this area: http://www.openstreetmap.org/?lat=35.04427lon=-118.163429zoom=18layers=M south of Mojave airport, the landuses are shifted about 8m at 80 degrees. They also appear rotated very slightly - maybe -1 degree. This is relative to Bing z19 5/7/2010-06/21/2010. FAA runway coordinates at MHV show that the imagery is shifted less than 1m from reality. At the interface between the two sets of imagery (around 35.0024 lat), there is a shift of 0-2m between them. Also, my and other GPX tracks along SR-14 also suggest the imagery is accurate. So, it's not clear why some of the landuses are shifted by so much, while others are not. -- Alan Mintz alan_mintz+...@earthlink.net ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Highway ref again.
When it comes to Interstates multiplexing, I think we should list first the one that the exit numbers are for on the highway. Some examples would be as follows: ref=I 76;I 70 on the PA Turnpike since I-76 is the main route and all the exits along there use I-76's mileage.ref=I 77;I 74 in NC since I-77's mileage is used for the mile markers.ref=I 77;I 64 in WV since the entire WV Turnpike is I-77 (and all exits are in I-77 mileage) and I-64 is just visiting. If both Interstates are going in the same direction and share the mileage since they both entered the state at the same time (I-20 and I-59 in AL), I-20 would go first there since it's the lower numbered route. James Date: Fri, 27 Jul 2012 09:34:24 -0700 To: alan_mintz+...@earthlink.net; Talk-us@openstreetmap.org From: techl...@techlady.com Subject: Re: [Talk-us] Highway ref again. Alan, I think you've identified another area where clarity is needed: What order should be used when entering multiple refs. I tend to do it with interstates first, then US routes, then state routes, within each group by number, low to high. However, a definite rule would be helpful. Charlotte ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Post bot cleanup
On Thu, Jul 19, 2012 at 4:50 AM, Phil! Gold phi...@pobox.com wrote: * Toby Murray toby.mur...@gmail.com [2012-07-19 00:42 -0500]: Any other common problems that people have seen? The most common problem I see is a missing way. But all the nodes are there sitting in space. I've also tried: http://tools.geofabrik.de/osmi/?view=redactionbot To identify missing ways to fix... but so far the tool has nothing but false positives. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
On Thu, Jul 19, 2012 at 9:06 AM, Richard Fairhurst rich...@systemed.netwrote: Depends whether you visit LA I guess ;) , but assuming you do, let's roll up our sleeves and fix it. I don't think that one self-proclaimed viking deciding not to agree to the new licence completely damns OSM! An unfortunate part of all this is that ' self-proclaimed vikings' who declined the are lumped in with people who simply changed their email address and are unreachable and unresponsive. I rather think the non-responders could have been a separate category, and their data could have been kept. The license bot damage will take decades to recover from. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Fwd: Re: Post bot cleanup
Bryce Nesbitt wrote: I rather think the non-responders could have been a separate category, and their data could have been kept. Doesn't fly legally, sadly. You can't say I'm ignoring any rights on this item just because the rights-holder hasn't responded to my e-mails. That said, I did once live near a tiny village (population 41) that claimed to be Twinned with Paris on the basis that they'd written to Paris asking for a twinning, and received no reply. I guess that's a similar idea. http://en.wikipedia.org/wiki/Whitwell,_Rutland The license bot damage will take decades to recover from. Not at all. OSM has only existed since 2004, and the redaction affected 1% of the database globally. At a very conservative estimate it's 29 days' work (8*365*0.01); in reality, we _already_ have more nodes in the database than we did before the redaction started. Such is the rate at which the map is growing. cheers Richard ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Here's my 2 cents on the mentioned tiger tags, fwiw: tiger:cfcc - As I understand, its original purpose was to classify different highway types, but once the appropriate OSM tags [derived in part from this tag, and then also from whatever other sources, imagery, personal visit, etc] have been added to the way, this tag doesn't serve any purpose. See: http://wiki.openstreetmap.org/wiki/TIGER_to_OSM_Attribute_Map#Roads If someone wants to see the history of the way, they can check the history with that tag. Also, in my experience the CFCC from 2007 were often incorrect, especially for highway=residential ways that should be marked highway=unclassified, tertiary, secondary, primary, or service. Tiger:separated - After reading tiger:separated=yes in the link above, doesn't that mean the way should be mapped in OSM as two separate ways ? If it's already mapped as 2 separate ways, then delete the tag. Tiger:tlid - Could be removed. I've had newbies ask me at mapping parties what it means, I haven't been able to answer them. I haven't seen any use for its inclusion at this point. tiger:upload_uuid: Could be removed. I haven't seen any use for its inclusion at this point, was useful in past, as Toby mentioned. -will ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Personally, I think there should be a tag to differentiate between a one-way road and half of a divided road; yes, a human can look at the map and make that determination instantly, but a computer requires some advanced analysis. (I can imagine some extra-nice rendering could benefit from this information…) Though I don't think such a tag belongs in tiger: namespace, the presence of tiger:separated is a half-decent hint for now. On the other hand, tiger:separated=no can go. The only use case I can imagine for keeping tiger:cfcc is if one is frustrated at the inconsistent application of different highway values, and would rather render by CFCC instead. However, it would make a lot more sense just to render directly from the most recent TIGER data in that case. To conclude, tiger:cfcc can go. PS I find it very annoying that replies don't go back to the list by default ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
Re: [Talk-us] Discardable TIGER tags
Hi, Sorry to be late to chip in. I would keep CFCC. It's a good tag to have both to be able to generate statistics (how much of original TIGER class mapping remains intact?) as well as for reference; I find the CFCC classification is usually good - even if the mapping onto OSM k/v is sometimes unfortunate. In itself a reason to keep them, we may decide to bulk-retag based on cfcc in the future. Unlikely, but fathomable. The uuid can co as far as I am concerned. The tlid as well. County can be discarded under the assumption that we have nationwide county-or-equivalent boundaries (I actually don't know if that's the case, for Utah it looks complete). The zipcodes don't have an equivalent in OSM right now, and are useful for geocoding, so I'd say leave those untouched. The separated taga I have never found to be useful or reliable. My vote would be to remove those as well. Looking forward to a leaner planet! Martijn PS I find it very annoying that replies don't go back to the list by default You should check your email client settings. Sometimes posters explicitly set a reply-to field though - in that case, your reply will go to the person's email directly. I always do reply-all when replying to lists. ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us -- martijn van exel http://oegeo.wordpress.com ___ Talk-us mailing list Talk-us@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-us
