Re: [OSM-talk] Changing WIKI username

[SwiftFast]

On Fri, 2017-09-22 at 22:32 +0100, Andy Mabbett wrote:
> On 22 September 2017 at 22:08, SwiftFast  wrote:
> 
> > Is it possible to change my Wiki username?
> 
> It should be - email me off-list and I'll take a look (maybe
> tomorrow).

Thanks!

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Adding wikidata tags to the remaining objects with only wikipedia tag

[Eugene Alvin Villar]

On Thu, Sep 21, 2017 at 9:22 PM, Martin Koppenhoefer  wrote:

> This is one of the fields (fundamental to OSM), where wikidata is just a
> mess: distinction of geographically localized communities and
> administrative territorial entities.
>
> Just a few examples:
> https://www.wikidata.org/wiki/Q123705 neighbourhood is a subclass of
> "human settlement" and "community". So far so good, but then it is also
> "part of municipality"?
> https://www.wikidata.org/wiki/Q2983893 quarter is a subclass of
> neightbourhood and administrative territorial entity. And it is an instance
> of "designation for an administrative territorial entity".
> https://www.wikidata.org/wiki/Q486972 human settlement looks OK at a
> glance
> https://www.wikidata.org/wiki/Q515 city is a subclass of "human
> settlement", "administrative territorial entity" and "political territorial
> entity" (are these AND or OR?).
> https://www.wikidata.org/wiki/Q3957 town is a subclass of "human
> settlement". It is "part of a country". It was also a subclass of political
> territorial entity until today [1]
> https://www.wikidata.org/wiki/Q532 village is a subclass of "rural
> settlement" and part of "rural area".
> https://www.wikidata.org/wiki/Q14788575 rural settlement is an instance
> of "designation for an administrative territorial entity" and a subclass of
> "human settlement"
> etc.
>
> Take the town example: it has been for some years a subclass of political
> territorial entity and isn't anymore since today. There are tens of
> thousands of objects that are all instances of towns according to wikidata.
> With one edit all of them have lost their "political territorial entity"
> status.
>

I wouldn't worry too much about these very generic classes of human
settlements or administrative areas. It would be better to focus our
attention on the actual Wikidata items on settlements and administrative
areas of each country, like Waldhufendorfs in Germany (
https://www.wikidata.org/wiki/Q351190) or comunes in Italy (
https://www.wikidata.org/wiki/Q747074). These national subclasses should
then be classified as subclasses of whichever appropriate generic
settlements or administrative areas there are.

So I doubt that tens of thousands of towns in Wikidata suddenly lost their
political territorial entity status. I would think that some of them are
still classified as such because of a different path up the ontology tree.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[talk-latam] sotm 2017 vídeos y presentaciones

[Marco Antonio]

@nyampire en twitter dice que actualizó el programa de sotm2017 con los vídeos
y las presentaciones

https://twitter.com/nyampire/status/911064129430892544

el accesp http://2017.stateofthemap.org/program

hay mucho por ver, y revisar

abrazos,

Marco Antonio
@51114u9

___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

Re: [Talk-it] itWikiCon a Trento

[Dario Crespi]

Perfetto! Allora ti conto tra i confermati. Il tuo sarà il primo workshop
dopo il benvenuto (a meno di modifiche alla bozza di programma). Poi ce ne
saranno altre 4: al momento sono "storia contemporanea e Wikipedia" e
workshop base sui bot dalle 16.00 alle 17.00 e "Wikipedia for Refugees" e
"Wikisource: basi per la contribuzione" dalle 17.00 alle 18.00 (ma attendo
ancora conferma da parte di alcuni speaker.

Grazie e a presto!

Dario

Il giorno 22 settembre 2017 15:50, Maurizio Napolitano 
ha scritto:

> 2017-09-22 14:44 GMT+02:00 Dario Crespi :
> > Ciao Maurizio,
> >
> > grazie. Guarda, noi abbiamo già abbozzato un programma e OSM è caduto
> > proprio il venerdì (al momento dalle 14.30 alle 15.30) in contemporanea
> con
> > una sessione sul gender gap. 50 minuti possono essere sufficienti?
>
> mi adatto a qualsiasi esigenza.
> Considera che io posso esserci solo venerdì e vorrei anche godermi la
> conferenza
> per quel giorno in cui ci sarò :)
>
>
> PS:
> Sulla questione gender gap e mappe forse vi interessa questo
> "giochino" fatto a suo tempo su toponomastica al femminile a Trento
> http://labmod.org/maps/dudesmaptrento/
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] FOSS4G-IT 2018

[Luca Delucchi]

2017-09-21 16:10 GMT+02:00 Maurizio Napolitano :
> Ciao Marco

ciao,

> scrivo anche qui perchè poi sulla ML di GFOSS.it sono stato più chiaro.
>
> Intanto risolvo la questione sul comitato scientifico:
> non avevo proprio visto l'elenco, probabilmente mi sono fatto
> ingannare dallo spazio di schermo dello smartphone.
> Se lo vedevo non lo mettevo nemmeno in discussione.
>
> Quello che invece volevo capire è se, la giornata dedicata a OSM
> accetta contributi come quelli definiti nella descrizione della
> conferenza che mi sembrano molto legati al riuso dei dati o della
> mappa attraverso software libero o se si poteva presentare anche
> argomenti che vanno in altri ambiti come sociologia, economia e
> giurisprudenza.
>
> Es.
> - analisi della comunità di osm
> - esempi di modelli di business basati su osm
> - compatibilità di licenze
>
> Argomenti che erano presenti in osmit.
>

e anche l'anno scorso a genova... per esempio si è parlato
dell'accordo CAI/Wikimedia che non è molto scientifico... il comitato
serve prevalentemente per valutare che le proposte siano afferenti
agli argomenti e vedere se è meglio che una proposta venga fatta come
presentazione orale o poster, solo le proposte veramente off topic
solitamente vengono respinte

> Tutto qui.
>
> my2cents
>

-- 
ciao
Luca

www.lucadelu.org

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-de] landuse=residential an Node

[dktue]

Am 22.09.2017 um 22:28 schrieb mmd:

Am 22.09.2017 um 22:03 schrieb dktue:

Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
mit Overpass-Turbo bewerkstelligen kann?



Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
mit der nächsten Version:

http://overpass-turbo.eu/s/rTF


Super, vielen Dank!

Dann ist Deutschland nun frei von

 - Nodes mit landuse=residential
 - Nicht geschlossenen ways mit landuse=residential

Viele Grüße
Daniel

___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [OSM-talk] Changing WIKI username

[Andy Mabbett]

On 22 September 2017 at 22:08, SwiftFast  wrote:

> Is it possible to change my Wiki username?

It should be - email me off-list and I'll take a look (maybe tomorrow).

-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] Aggiornamento codici ISTAT in Sardegna.

[Paolo F]

2017-09-22 16:01 GMT+02:00 Martin Koppenhoefer :

>
>
> sent from a phone
>
> > On 22. Sep 2017, at 11:16, Paolo F  wrote:
> >
> > Avrei gia' pronto uno script per provvedere ad un'aggiornamento
> automatico del tag "ref:ISTAT".
>
>
> ci puoi descrivere come funziona lo script, in particolare se tiene conto
> di eventuali modifiche che hanno fatto gli utenti.
> Grazie,
>

E' uno script in python che utilizza il modulo osmapi.
In pratica legge il file csv  di ISTAT e cerca in una tabella in un db il
vecchio codice; se esiste una differenza tra il vecchio codice e quello
nuovo effettua una chiamata API RelationGet utilizzando l'id dell'oggetto,
modifica la struttura relativa ai tags ed effettua una chiamata
RelationUpdate. Non viene effettuata nessuna modifica sulle geometrie.
In pratica tra la chiamata Get e quella Update il tempo e' veramente basso;
e' vero che l'operazione termina con la chiusura del changeset (pensavo ad
un unico changeset!) e il tempo complessivo e' inferiore ai 2 minuti (test
effettuati senza fare l'update, naturalmente!). La possibilità che ci sia
qualcuno che effettua una modifica nel frattempo esiste, ma credo che la
probabilità sia decisamente bassa.

Ciao, Paolo


> Ciao, Martin
>
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[OSM-talk] Changing WIKI username

[SwiftFast]

Is it possible to change my Wiki username?

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-de] landuse=residential an Node

[mmd]

Am 22.09.2017 um 22:03 schrieb dktue:
> 
> Jetzt würde ich gerne nicht-geschlossene ways finden, an denen
> landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das
> mit Overpass-Turbo bewerkstelligen kann?
> 


Dieses Feature ist noch nicht offiziell freigegeben und kommt irgendwann
mit der nächsten Version:

http://overpass-turbo.eu/s/rTF


-- 



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-us] I-69 east west vs north south

[Bill Ricker]

On Fri, Sep 22, 2017 at 7:55 AM, Josh Lee  wrote:
> While it might be uncommon for two-digit Interstate highways to change
> their directions, it's quite common for three-digit ones to do so, and
> it shouldn't be treated any differently.

And there's a case where it was supposed to be a 3-digit Ring
interstate but got the 2-digit by default, due to cancellation of
other segments.  MA SR-128 (as relocated to freeway) would have been
one of three I-x95 rings, if i-95 had gone through Boston (unbuilt)
with an Inner Ring (unbuilt), as planned. Instead, I-93 (planned to
end at Boston) was extended south, along US-3 freeway, and then
perversely around MA-128 to where I-95 departs ring MA-128 south.
 At that junction, a car traveling MA-128 S counter-clockwise from
Gloucester end to Braintree end will shift from I-95 S / MA-128 S /
US-1 N  to I-93 N / MA-128 S / US-1 N, while compass says they're
still going South-East!
http://www.openstreetmap.org/way/76850961
   (US-1 used to go straight through, on Metro.Dist.Comm. Parkways, a
diagonal arterial across Olmsted's Emerald Necklace, but the US Route
1 was relocated to the freeways recently, so US-1 runs S along MA-128N
a couple exits further than i-93 S. There is a rumor that one US-1
shield remains on the old route. AFAIK old-one isn't even signed ALT
or 1A or Old 1 :-(  )

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-de] landuse=residential an Node

[dktue]

Super, vielen Dank!

Jetzt würde ich gerne nicht-geschlossene ways finden, an denen 
landuse=residential getaggt ist -- kann mir jemand sagen, wie ich das 
mit Overpass-Turbo bewerkstelligen kann?


Viele Grüße
dktue


Am 22.09.2017 um 21:16 schrieb Tom Pfeifer:

Fein.
Habe mir die Restposten angeschaut, es sind dort urbane bzw. ländliche 
Siedlungsstrukturen zu erkennen, zu denen der Name gemappt wurde, da 
eignet sich place=hamlet bzw. place=neighbourhood,

insbesondere wenn der landuse ohnehin schon als Fläche gemappt war.

Repariert.

On 22.09.2017 20:30, dktue wrote:

Hallo,

ich habe die Fälle nun bundesweit händisch und einzeln korrigiert, 
benötige aber Unterstützung für die letzten fünf verbliebenen Nodes [1].


Kann das mal jemand gegen prüfen und gegebenenfalls korrigieren?

Viele Grüße
Daniel

[1] http://overpass-turbo.eu/s/rTx



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] landuse=residential an Node

[Tom Pfeifer]

Fein.
Habe mir die Restposten angeschaut, es sind dort urbane bzw. ländliche Siedlungsstrukturen zu 
erkennen, zu denen der Name gemappt wurde, da eignet sich place=hamlet bzw. place=neighbourhood,

insbesondere wenn der landuse ohnehin schon als Fläche gemappt war.

Repariert.

On 22.09.2017 20:30, dktue wrote:

Hallo,

ich habe die Fälle nun bundesweit händisch und einzeln korrigiert, benötige aber Unterstützung für 
die letzten fünf verbliebenen Nodes [1].


Kann das mal jemand gegen prüfen und gegebenenfalls korrigieren?

Viele Grüße
Daniel

[1] http://overpass-turbo.eu/s/rTx



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-de] landuse=residential an Node

[dktue]

Hallo,

ich habe die Fälle nun bundesweit händisch und einzeln korrigiert, 
benötige aber Unterstützung für die letzten fünf verbliebenen Nodes [1].


Kann das mal jemand gegen prüfen und gegebenenfalls korrigieren?

Viele Grüße
Daniel

[1] http://overpass-turbo.eu/s/rTx

Am 07.09.2017 um 21:00 schrieb Rainer:
Habe mir gerade mal mit der Overpassabfrage ein paar angeschaut. Die 
Fälle sind alle etwas verschieden. Wenn man sie sich einzeln anschaut 
und korrigiert, finde ich es in Ordnung. JOSM meckert ja gleich an 
diesen Punkten.


Grüße,
Rainer

Am 07.09.2017 20:16, schrieb dktue:

Hallo,

oh, ich wollte gar nicht weltweit löschen, sondern nur bundesweit. 
Das hatte ich nicht geschrieben. In Deutschland gibt es genau 27 
solcher Nodes [1]. Die gehe ich einfach von Hand durch und erzeuge 
gegebenenfalls aus dem Luftbild die Fläche, die eigentlich gemeint ist.


Viele Grüße
Daniel

[1] http://overpass-turbo.eu/s/rxD

Am 07.09.2017 um 18:59 schrieb Martin Koppenhoefer:
Am 7. September 2017 um 18:52 schrieb Tom Pfeifer 
:



Ja, ich habe Einwände.
landuse=residential gibt es 5026x auf einer Node, im Vergleich zu 
4,2 Mio

Flächen.
Die Nodes sind weltweit verteilt.

All diese Nodes beinhalten die Aussage, dass sich dort ein 
Siedlungsgebiet

befindet.
Für ein Löschen dieses Tags gibt es überhaupt keinen Grund, schon gar
nicht "auf einen Rutsch" (=mechanical edit[1]).

Wenn du etwas verbessern möchtest, lade das Gebiet einer solchen 
Node, in

einer Gegend, in der du den Bebauungs-Stil von Wohngebieten kennst und
anhand des Luftbildes einschätzen kannst, und zeichne den Umriss des
Wohngebiets. Die Node kannst du im Umring verwenden. [2]



+1
prinzipiell müsste man bei einem weltweiten Edit auch international
anfragen, nicht nur auf der deutschen Liste.

Gruß,
Martin
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de



___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

[Talk-us] I 85 Express Lane (Atlanta, Georgia)

[Jack Burke]

Howdy folks,

I'm looking for advice on how to tag properly a complex lane condition.

I 85 northeast of Atlanta (both NB and SB) has an express lane[1][2] that
extends for many miles (sample section located here:
https://osm.org/go/ZSAYLN0I0-?m= ).  The lane is not barrier separated from
the normal traffic lanes; a solid double white paint stripe is the legal
"barrier" for the lane, with dashed sections every few miles representing
the "entrance/exit" section (visible in Mapillary imagery for the above
linked segment).

Legally allowed to use the lane are:
* vehicles with electronic toll cards (PeachPass [GA], SunPass [FL],
QuickPass [NC]), except those in the prohibited categories
* vehicles with 3 or more occupants, with or without a toll card
* motorcycles, with or without a toll card
* emergency vehicles (ambulances, etc.)
* Alternative fuel vehicles WITH the special AFV license plate (does not
include hybrids), with or without a toll card

Specifically prohibited from the lane are:
* vehicles with more than 2 axles
* vehicles with more than 6 wheels

So, it is both a toll lane and[3] an HOV lane.


To add to the fun, at GA 316, there is an express-lane-only on/off ramp set.

Someone has added the following FIXME tag to the relevant section of I 85:
 "add separated HOT lanes, adjust lane count"


My questions are:

* Should this lane be drawn as a separate way?  Legally, you cannot enter
or exit the lane except at the designated sections, so drawing it
separately makes things simpler for routers.  If it's drawn separately, a
pair of motorway_link roads would need to be added at several places (the
dashed-stripe sections).  The Lanes wiki page[4] seems to say that it
should be drawn separately:  "If one or more lanes of the road are
restricted to high-occupancy vehicles (typically vehicles with 2+
occupants, although this varies by jurisdiction). Most useful if
entrance/egress is permitted at any point along the route; if entering or
exiting the HOV lane(s) is only permitted at certain locations, modeling
the HOV lane(s) as separate ways is preferable."  (Even though that says
HOV, the same reasoning appears relevant for toll.)  Does everyone concur
with this construction?

* How should access tags be set?  Assume for the discussion that the
express lane is NOT drawn separately (the current case); it is easy to
visualize how the tags would look if it's drawn separately.  Right now,
there is only a "hov:lanes=designated|yes|yes|yes|yes|yes" tag.
Considering that tolled non-HOV vehicles can use the lane, should that tag
be left or removed?  If it's left, then
"access:lanes=no|yes|yes|yes|yes|yes"[5],
"motorcycle:lanes=designated|yes|yes|yes|yes|yes",
"afv:lanes=designated|yes|yes|yes|yes|yes" and probably
"hgv:lanes=no|yes|yes|yes|yes|yes" should be added.  Just how do you tag
access restrictions for something that is "Toll OR HOV OR motorcycle OR
AFV"[6]?  (And, do we need a separate HOV tag for high-passenger counts?
HOV:count=3?)


As a separate item, in my spare time, I'm going to try to put together wiki
page proposals for AFV (Alternative fuel vehicle) and PTV (Personal
transportation vechile; i.e., golf carts and similar that can be driven on
public streets) if I can find the time.

Feedback, comments, questions: all are welcome.
--Jack


[1] http://peachpass.com/peach-pass-toll-facilities/about-i-85-express-lanes
[2] https://dps.georgia.gov/i-85-expres-lanes-hot-lanes
[3] A grammatical "and," not a logical one.
[4] https://wiki.openstreetmap.org/wiki/Lanes
[5] https://wiki.openstreetmap.org/wiki/Tag:access%3Ddesignated  in the
"only hov=* vehicles" example.  But perhaps this tag should be left out?
[6] A logical "or," not a grammatical one.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-ca] High resolution Air photos for New Brunswick

[James]

For anyone wanting to contribute to the New Brunswick high res maps, I'm
creating tasks on the osmcanada tasking manager (http://tasks.osmcanada.ca/)

On Fri, Sep 15, 2017 at 9:32 AM, Bernie Connors 
wrote:

> Hello all,
>
>
>
> My apologies if this has already been mentioned on this
> list.  The Esri World Imagery basemap is now available as a background
> image for OpenStreetMap editors.  In New Brunswick the provincial
> government has contributed hundreds of square kilometres of high
> resolution, urban air photos to the Esri World Imagery basemap.  There
> are thousands of buildings and other features that require editing so they
> match the newer, hi-resolution imagery in the Esri World Imagery basemap.
> This area in Fredericton is a good example [1] (start an edit session and
> choose the Esri World Imagery background).  I posted to my blog with a
> few more details [2]
>
>
>
> [1] - http://www.openstreetmap.org/#map=19/45.96139/-66.64951
>
> [2] - http://geobern.blogspot.ca/2017/08/esri-world-imagery-in-o
> penstreetmap.html
>
>
>
> Bernie.
> --
> Bernie Connors
> New Maryland, NB
>
> ___
> Talk-ca mailing list
> Talk-ca@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ca
>
>


-- 
外に遊びに行こう！
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[OSM-talk] Place Tagging Overview Wiki page

[SwiftFast]

There are many places to tag places. (node, way, admin area,
landuse=residential, etc). This confuses me, and I assume it confuses
many others. We need a comprehensive summary covering all cases.

Here's a draft: https://wiki.openstreetmap.org/wiki/Place_tagging_overv
iew . It's likely inaccurate/incomplete. Please help me improve it.

___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

semanarioOSM Nº 374 2017-09-12-2017-09-18

[weeklyteam]

Hola, el semanario Nº 374, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/9476/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

semanarioOSM Nº 374 2017-09-12-2017-09-18

[weeklyteam]

Hola, el semanario Nº 374, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/9476/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cu mailing list
Talk-cu@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cu

semanarioOSM Nº 374 2017-09-12-2017-09-18

[weeklyteam]

Hola, el semanario Nº 374, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/9476/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

semanarioOSM Nº 374 2017-09-12-2017-09-18

[weeklyteam]

Hola, el semanario Nº 374, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/9476/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-latam mailing list
talk-latam@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-latam

semanarioOSM Nº 374 2017-09-12-2017-09-18

[weeklyteam]

Hola, el semanario Nº 374, el sumario de todo lo que está ocurriendo en el 
mundo de openstreetmap está en línea en *español*:

http://www.weeklyosm.eu/es/archives/9476/

¡Disfruta!

semanarioOSM? 
¿Dónde?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
¿Quién?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-co mailing list
Talk-co@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-co

[OSM-talk-fr] Opération libre les 07 et 08 octobre prochain à Peillac-Les Fougerêts

[Louis-Julien de la Bouëre]

Bonjour à toutes et tous,

*La première Opération Libre en Bretagne c’est demain !*

L’équipe d’organisation est sur les rails prête à vous accueillir et les 
habitants sont déjà fortement mobilisés, très curieux et prêts à vous 
accueillir!


*les 07 et 08 octobre prochain à Peillac-Les Fougerêts dans le Morbihan.*

Les deux communes vont bientôt fusionner et l’Opération Libre arrive à 
point nommé ! C’est avant tout une volonté locale initiée par le Conseil 
de Développement du pays et les communes.


*Voici tous les éléments pour nous rejoindre :*
 - le Wiki du Pays de Redon 
 - les infos d’organisation générale 

 - Le pad du pré-programme 
 
(n’hésitez pas à amender)


 - le *lien pour s’inscrire 
*
 - La carte et liste 
 des participants


 - Pour organiser le co-voiturage 

 - Pour organiser votre venue en train 



Nous serons heureux de vous voir ou revoir dans ces belles communes…

*Contactez nous si besoin : *
 - Renseignements et coordination générale localement : Marie-Jo 
Menozzi (Conseil de développement du Pays) marie-jo.meno...@orange.fr
 - Renseignements Coordination/communication des équipes de 
contributeurs-trices : Louis-Julien de la Bouëre Tiriad 
ljbou...@tiriad.org (06 58 79 80 56 en cas de nécessité)


Au plaisir,


--
Louis-Julien de la Bouëre
Association Tiriad
ljbou...@tiriad.org
www.tiriad.org
Portable : 06 58 79 80 56
Twitter : @assotiriad
Skype : tiloul29
OpenStreetMap : http://hdyc.neis-one.org/?Ljbouere
Mapillary : https://www.mapillary.com/app/user/ljbouere

<>___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-ie] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ie mailing list
Talk-ie@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ie

[Talk-GB] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[Talk-ca] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

[Talk-in] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

[Talk-us] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[talk-ph] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk-ph mailing list
talk-ph@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ph

[OSM-talk] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-africa] weeklyOSM #374 2017-09-12-2017-09-18

[weeklyteam]

The weekly round-up of OSM news, issue # 374,
is now available online in English, giving as always a summary of all things 
happening in the openstreetmap world:

http://www.weeklyosm.eu/en/archives/9476/

Enjoy!

weeklyOSM? 
who?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
where?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Daniel Patterson]

OSRM pre-processing is kind of worst-case for disk swapping - it does a lot
of random access, so if you run out of RAM, pages will get continuously
swapped in/out.  The slowdown between RAM-only and swap-on-SSD can be 50x
or more.  The difference between swap on a spinning disk and an SSD is a
good 10x on top of that.

If you can, avoid letting OSRM pre-processing touch swap at all costs -
it's worth renting a big machine on AWS/Google/Azure for a short time to
pre-process the data.

daniel

On Fri, Sep 22, 2017 at 7:14 AM, Sayer, Bryan  wrote:

> Just as a point of reference, you mention that avoiding swapping and just
> using RAM will be much faster. If the swap space is an SSD drive, how much
> does using only RAM speed up contract? That is, what is the difference
> between using say a 7200 rpm SATA drive versus an SSD drive make?
> --
> *From:* Daniel Patterson 
> *Sent:* Friday, September 22, 2017 8:05:56 AM
> *To:* Mailing list to discuss Project OSRM
> *Subject:* Re: [OSRM-talk] Expecting time for osrm-contract for planet
>
> Hi Kieran,
>
>   We don't, but I've done some profiling in the past, Docker itself should
> have negligible impact.
>
>   The two things that might be slowing things down:
>
> 1) The docker images don't bundle jemalloc (http://jemalloc.net/),
> which can speed things up by 10-15%
> 2) osrm-contract is very CPU intensive - the more threads you give it,
> the faster it will run.  Give it more if you can.
>
>  256GB of RAM should be more than enough to avoid swapping, but you might
> want to disable swap to be sure - if it's being used, it will have a huge
> impact on speed.
>
> daniel
>
> On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> Hi Daniel,
>> Can you clarify if you use Docker at Mapbox? What kind of server do you
>> guys have (if not the one described on the wiki page)?
>>
>> Over night, the process has gone to just 75% complete from 65% yesterday
>> - 41 hours in total now, and back to maxing CPU again.
>>
>> Kind regards,
>> Kieran Caplice
>>
>> On 21/09/17 17:17, Daniel Patterson wrote:
>>
>> OSRM supports *two* core routing algorithms - CH and MLD.  The
>> `osrm-contract` tool generates the CH dataset, but you can use the MLD
>> pipeline instead with:
>>
>> osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
>> osrm-partition yourmap.osrm
>> osrm-customize yourmap.osrm
>> osrm-routed -a MLD yourmap.osrm
>>
>> This sequence of tools should be significantly quicker than osrm-contract
>> - the price you pay is that routing requests are about 5x slower (still
>> pretty fast though!).  The reason that MLD exists is for the
>> `osrm-customize` step - it allows you to import traffic data very quickly
>> and update the routing graph (~1 minute for North America).
>>
>> It's hard to say exactly what's going wrong with osrm-contract here -
>> here at Mapbox, we daily run `osrm-contract` over the latest planet with
>> the bicycle profile without a problem, however, Alex and others have
>> reported issues with what seem like hangs on much smaller datasets that
>> we've been unable to reproduce so far.
>>
>> The runtime of osrm-contract is affected by how much hierarchy exists in
>> the data - the more similar the edge speeds (like in foot) and the more
>> edges there are, the slower it gets, often in a non-linear fashion.  The
>> car profile has a very hierarchical structure (many different road speeds),
>> so it fits well into the CH, the construction algorithm  doesn't need to
>> compare as many options.
>>
>> daniel
>>
>> On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice <
>> kieran.capl...@temetra.com> wrote:
>>
>>> We're actually looking for the best of both car and foot, so in my head,
>>> bicycle would be the happy medium (though I could be completely wrong on
>>> this).
>>> Kind regards,
>>> Kieran Caplice
>>>
>>> On 21/09/17 16:53, Alex Farioletti wrote:
>>>
>>> i've run into the same issues, and now i just use metroextracts of the
>>> areas that i need for the bike stuff i do and it reduces the time
>>> significantly
>>>
>>> *Alex Farioletti*
>>> *415.312.1674*
>>> *tcbcourier.com  *
>>>
>>> On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice <
>>> kieran.capl...@temetra.com> wrote:
>>>
 Thanks Daniel.

 I'm using the bicycle profile, so I would expect based on what you've
 said that somewhere up to 36 hours would be likely. However, this is the
 current output, after 25h40m:
 [info] Input file: /data/1505492056/planet-latest.osrm
 [info] Threads: 12
 [info] Reading node weights.
 [info] Done reading node weights.
 [info] Loading edge-expanded graph representation
 [info] merged 2379332 edges out of 152432
 [info] initializing node priorities... ok.
 [info] preprocessing 389797971 (90%) nodes...
 [info] . 10% . 20% . 30% . 40% . 50% . 60%

 It hasn't advanced past 60% in 

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Sayer, Bryan]

Just as a point of reference, you mention that avoiding swapping and just using 
RAM will be much faster. If the swap space is an SSD drive, how much does using 
only RAM speed up contract? That is, what is the difference between using say a 
7200 rpm SATA drive versus an SSD drive make?


From: Daniel Patterson 
Sent: Friday, September 22, 2017 8:05:56 AM
To: Mailing list to discuss Project OSRM
Subject: Re: [OSRM-talk] Expecting time for osrm-contract for planet

Hi Kieran,

  We don't, but I've done some profiling in the past, Docker itself should have 
negligible impact.

  The two things that might be slowing things down:

1) The docker images don't bundle jemalloc (http://jemalloc.net/), which 
can speed things up by 10-15%
2) osrm-contract is very CPU intensive - the more threads you give it, the 
faster it will run.  Give it more if you can.

 256GB of RAM should be more than enough to avoid swapping, but you might want 
to disable swap to be sure - if it's being used, it will have a huge impact on 
speed.

daniel

On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice 
> wrote:

Hi Daniel,

Can you clarify if you use Docker at Mapbox? What kind of server do you guys 
have (if not the one described on the wiki page)?

Over night, the process has gone to just 75% complete from 65% yesterday - 41 
hours in total now, and back to maxing CPU again.

Kind regards,
Kieran Caplice

On 21/09/17 17:17, Daniel Patterson wrote:
OSRM supports *two* core routing algorithms - CH and MLD.  The `osrm-contract` 
tool generates the CH dataset, but you can use the MLD pipeline instead with:

osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
osrm-partition yourmap.osrm
osrm-customize yourmap.osrm
osrm-routed -a MLD yourmap.osrm

This sequence of tools should be significantly quicker than osrm-contract - the 
price you pay is that routing requests are about 5x slower (still pretty fast 
though!).  The reason that MLD exists is for the `osrm-customize` step - it 
allows you to import traffic data very quickly and update the routing graph (~1 
minute for North America).

It's hard to say exactly what's going wrong with osrm-contract here - here at 
Mapbox, we daily run `osrm-contract` over the latest planet with the bicycle 
profile without a problem, however, Alex and others have reported issues with 
what seem like hangs on much smaller datasets that we've been unable to 
reproduce so far.

The runtime of osrm-contract is affected by how much hierarchy exists in the 
data - the more similar the edge speeds (like in foot) and the more edges there 
are, the slower it gets, often in a non-linear fashion.  The car profile has a 
very hierarchical structure (many different road speeds), so it fits well into 
the CH, the construction algorithm  doesn't need to compare as many options.

daniel

On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice 
> wrote:

We're actually looking for the best of both car and foot, so in my head, 
bicycle would be the happy medium (though I could be completely wrong on this).

Kind regards,
Kieran Caplice

On 21/09/17 16:53, Alex Farioletti wrote:
i've run into the same issues, and now i just use metroextracts of the areas 
that i need for the bike stuff i do and it reduces the time significantly

Alex Farioletti
415.312.1674
tcbcourier.com

On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice 
> wrote:

Thanks Daniel.

I'm using the bicycle profile, so I would expect based on what you've said that 
somewhere up to 36 hours would be likely. However, this is the current output, 
after 25h40m:

[info] Input file: /data/1505492056/planet-latest.osrm
[info] Threads: 12
[info] Reading node weights.
[info] Done reading node weights.
[info] Loading edge-expanded graph representation
[info] merged 2379332 edges out of 152432
[info] initializing node priorities... ok.
[info] preprocessing 389797971 (90%) nodes...
[info] . 10% . 20% . 30% . 40% . 50% . 60%

It hasn't advanced past 60% in the last 2-3 hours. It is however maxing CPU and 
using approximately the same amount of RAM since it started.

Kind regards,
Kieran Caplice

On 21/09/17 16:39, Daniel Patterson wrote:
Hi Kieran,

  The contraction time will be slow - many, many hours for the whole planet.  
*Typically* for the car profile it's about 12 hours, but if you use bike or 
foot, or your own profile, it can get a lot bigger.

  If you've messed with the travel speeds, that can have a big effect too.  24 
hours is not unheard of, but whether it's legit will depend a lot on the 
details.

daniel

On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice 
> wrote:
Hi all,

Could anyone give an approx estimate for the time required to run the 

Re: [Talk-it] Aggiornamento codici ISTAT in Sardegna.

[Maurizio Napolitano]

>> On 22. Sep 2017, at 11:16, Paolo F  wrote:
>>
>> Se non vi e' nulla in contrario procederei, mantenendo comunque anche 
>> l'informazione del vecchio codice in un nuovo tag: "old_ref:ISTAT".
>
>
> troveremo ancora tanti documenti in giro con il vecchio codice (probabilmente 
> si)? Se c’è una lista pubblica di vecchi e nuovi codici, direi che non ci 
> serve il vecchio codice (tanto rimane nello storico).

anche io sarei per mettere quello nuovo e basta.

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Aggiornamento codici ISTAT in Sardegna.

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2017, at 11:16, Paolo F  wrote:
> 
> Avrei gia' pronto uno script per provvedere ad un'aggiornamento automatico 
> del tag "ref:ISTAT".


ci puoi descrivere come funziona lo script, in particolare se tiene conto di 
eventuali modifiche che hanno fatto gli utenti.
Grazie,

Ciao, Martin 


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Aggiornamento codici ISTAT in Sardegna.

[Martin Koppenhoefer]

sent from a phone

> On 22. Sep 2017, at 11:16, Paolo F  wrote:
> 
> Se non vi e' nulla in contrario procederei, mantenendo comunque anche 
> l'informazione del vecchio codice in un nuovo tag: "old_ref:ISTAT".


troveremo ancora tanti documenti in giro con il vecchio codice (probabilmente 
si)? Se c’è una lista pubblica di vecchi e nuovi codici, direi che non ci serve 
il vecchio codice (tanto rimane nello storico). 


Ciao, Martin 
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] itWikiCon a Trento

[Maurizio Napolitano]

2017-09-22 14:44 GMT+02:00 Dario Crespi :
> Ciao Maurizio,
>
> grazie. Guarda, noi abbiamo già abbozzato un programma e OSM è caduto
> proprio il venerdì (al momento dalle 14.30 alle 15.30) in contemporanea con
> una sessione sul gender gap. 50 minuti possono essere sufficienti?

mi adatto a qualsiasi esigenza.
Considera che io posso esserci solo venerdì e vorrei anche godermi la conferenza
per quel giorno in cui ci sarò :)


PS:
Sulla questione gender gap e mappe forse vi interessa questo
"giochino" fatto a suo tempo su toponomastica al femminile a Trento
http://labmod.org/maps/dudesmaptrento/

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] tavoli da pic-nic

[Martin Koppenhoefer]

sent from a phone

> On 21. Sep 2017, at 14:47, demon.box  wrote:
> 
> ciao Martin, scusa ma come ci comportiamo quando non c'è nessun nome o
> cartello per l'area picnic ma c'è soltanto 1 tavolo isolato e basta?


puoi mettere il tavolo e basta, oppure decidere che con il tavolo il tutto è 
diventato anche un’area picnic. ;-)


Ciao, Martin 


___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-dk] Dele af København under vand på OSM standardkortet

[Torben Brendstrup]

Jeg ved ikke om det er en renderingsfejl, eller det er et sygt edit, men
det ser pt ud som om Ørestad, Amagerbro og Sydhavnen er sunket.

Er der nogen der ved hvordan det kan fixes, eller ved hvem man skal have
fat i?
___
Talk-dk mailing list
Talk-dk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-dk

Re: [Talk-it] Changeset rimasto aperto

[Simone Saviolo]

Il giorno 22 settembre 2017 14:45, Andrea Albani  ha
scritto:

> Ciao,
>
> guardando i metadati del changeset che riporto estrapolati qui sotto
>
>  created_at="2017-09-22T09:44:02Z"
> *closed_at="2017-09-22T10:44:04Z*" open="false"
> .
>
> si vede che il changeset è ora in stato closed e questo è avvenuto un'ora
> dopo la creazione come riportato da Daniele Forsi.
>
> La cosa strana è che quando ho controllato attorno alle 13, quindi oltre
> due ore dopo la chiusura, era ancora in stato open.
>
> Secondo me c'è stato qualche problema temporaneo di chiamamolo
> "allineamento" lato OSM... o qualcosa che mi sfugge nella meccanica di
> gestione dei changeset.
>

Allo stato attuale direi "problema risolto" :)

Grazie a tutti,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] itWikiCon a Trento

[Dario Crespi]

Ciao Maurizio,

grazie. Guarda, noi abbiamo già abbozzato un programma e OSM è caduto
proprio il venerdì (al momento dalle 14.30 alle 15.30) in contemporanea con
una sessione sul gender gap. 50 minuti possono essere sufficienti?
Altrimenti possiamo aggiungerne altri 50 tra le 16.00 e le 18.00.

Grazie ancora,

Dario

Il giorno 21 settembre 2017 14:32, Maurizio Napolitano 
ha scritto:

> Ciao Dario
>
> > E quindi vi chiedo: qualcuno di voi in quei giorni di novembre sarebbe
> > disponibile a venire a Trento per illustrarci il funzionamento di JOSM?
>
> Per me molto volentieri, solo che posso dare disponibilità solo per la
> giornata di venerdì 17
> In ogni caso sarò presente all'evento (ma sempre per il 17).
>
> Ciao
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Changeset rimasto aperto

[Andrea Albani]

Ciao,

guardando i metadati del changeset che riporto estrapolati qui sotto

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Philip Withnall]

On Fri, 2017-09-22 at 13:16 +0100, Philip Barnes wrote:
> On Fri, 2017-09-22 at 11:28 +0100, James Harrison wrote:
> > 
> > As an aside to this conversation, where are photos most useful for
> > OSM
> > contributions? Just built-up areas or road junctions etc? If we
> > were
> > designing a selector given a bunch of different capture locations,
> > what
> > would produce the most useful images for map editing?
> > 
> 
> Thats a big question, but my view is certainly not just built up
> areas.
> 
> In my view rural junctions with rights of way would be very useful,
> as
> would changes of speed limit, farm/housenames.

I’d say town centres are quite useful to photograph regularly, if you
can get a decent view of the shop fronts, since they change often and
are probably quite useful to a lot of OSM users.

(Another) Philip

signature.asc
Description: This is a digitally signed message part
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[PanierAvide]

+1, taking pictures for Mapillary or OpenStreetCam is not really 
competiting with time for OSM contribution. Moreover, I gave a talk 
about using street-level imagery for contributing to OSM [1] to this 
year State of the Map. Clearly, pictures taken by other people allowed 
me to spend hours contributing remotely, which I could'nt have done 
without this data source (as my city is already pretty well mapped).



> For new contributors, the recommendations feel a bit too focused on
> niche use cases, and not enough on core OSM. When people have a few
> hours or days to spare and want to contribute to OSM, then I would
> almost always recommend that they start mapping in their local area
> using iD or JOSM (depending on computer skills).

Well, we can also add traditionnal OSM editors in the list ;-) But the 
original idea was to make people discover new thematic tools. I think 
when someone introduce you to OSM, the person always mention mainstream 
editors. And if you have any idea of interesting tools for less "niche" 
cases, let me know.



> Something else to consider is that "outside" and "remotely" does not
> cover the entire OSM experience. In fact, the traditional way to
> contribute is to collect data outside, and enter it back at home. Right
> now, that's not an option with your tool.

In fact we already manage tools working in both cases (working both on 
desktop and smartphone, like OSM notes). And for applications needing 
ground data but only working on desktop, even if it's not explicit in 
the app, if you don't have info then you will instinctively go find it 
on the ground. Like OpenBeerMap, it doesn't work well on smartphone, so 
you will mainly use it on desktop. But if you can't remember which beer 
is served on a given pub, the best solution is to go buy some by 
yourself and then input data (be careful of drunk data) :-)



> Hope this mail doesn't come across as too negative! I mostly focussed on
> potential improvements rather than the things that worked fine for me
> (i.e. everything not mentioned here).

No worries, as long as it is constructive, it's good to have the 
feedback ;-)


Regards,

Adrien.

[1] http://my.pavie.info/ftp/p4c-sotm-2017/diapo.pdf



Le 22/09/2017 à 12:11, Jo a écrit :
I don't really mind having Mapillary in there, but if you do, you'd 
have to mention OpenStreetCam as well, of course.


When I go out to survey using making Mapillary pictures, it's true I'm 
not adding data using Vespucci or Walking Papers, but I wouldn't do 
those things anyway.


Making automated picture sequences doesn't really get in the way of 
what I'm actuallly doing, cycling, or walking.


When couch mapping they are often really handy to have and work with, 
so I definitely helps us. Aerial imagery is great, but even at high 
resolution it's not possible to see every detail on it.


Jo

2017-09-22 11:57 GMT+02:00 Tobias Knerr >:


On 21.09.2017 19 :45, PanierAvide wrote:
> http://projets.pavie.info/whatosm/


This may be controversial, but I don't think a guide for people
considering to contribute to OSM should send them away to Mapillary.
They aren't part of OSM proper and arguably compete with us for
volunteer time. Mapillary let us use their images, of course, but they
have that in common with a lot of other orgs that no one would mistake
for being part of the OSM project.

> It can be used by new contributors, but also more experimented
ones, who
> don't know what to do anymore in their neighbourhood.

For new contributors, the recommendations feel a bit too focused on
niche use cases, and not enough on core OSM. When people have a few
hours or days to spare and want to contribute to OSM, then I would
almost always recommend that they start mapping in their local area
using iD or JOSM (depending on computer skills).

Something else to consider is that "outside" and "remotely" does not
cover the entire OSM experience. In fact, the traditional way to
contribute is to collect data outside, and enter it back at home.
Right
now, that's not an option with your tool.

Hope this mail doesn't come across as too negative! I mostly
focussed on
potential improvements rather than the things that worked fine for me
(i.e. everything not mentioned here).

Tobias


 It might be
> interested to show this to people when doing mapping parties. User
> interface works as well on desktop as on smartphone.
>
> This project is open source and is available on this repository :
>
> https://framagit.org/PanierAvide/WhatOSM

>
> You can contribute to it by proposing tools which allow contributing
> more or less directly to OpenStreetMap. Also, if you speak English +
> another language, you can help 

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Philip Barnes]

I certainly prefer to take geo-referenced photos and upload them
through a script rather than use an app that deletes them. I at least
have a backup, and can refer back to find street or shop names that
mapillary has chosen to blur.

I have also discovered that mapillary has its own community, some of
whom set rules such as the car not being visible. I did have a sequence
 I took hidden (now lost) by someone in the mid-west. Its a lot easier
to hide the vehicle if you drive a large pickup.

The sequence was on Furteventura, so not easy to do it again.

Unlike OSM there is no way to contact another user, and the username
didn't match an osm username.

Also using a sequence camera app allows it to run in the background, so
the screen can be used for other stuff such as OSMand or maps.me.
Useful if you are somewhere you have never been before and will
probably never go again.

Phil (trigpoint)

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-cl] Datos cartográficos desde mapas Precenso 2016/Censo2017

[Cristian Alvarez Ocares]

Estimados , una información que puede ser relevante son las comunidades
indigenas en las areas rurales . Esto viene contenido en "Entidades".

Saludos

El sept. 22, 2017 8:53, "Exequiel Gaete Pavez" 
escribió:

> Pero no vienen los nombres de las calles en los archivos del Precenso
> 2016 (seguiré acá la respuesta)
> En relación a las manzanas, recuerdo vi algunas diferencias en algunas
> comunas de la RM (La Pintana), pero eran diferencias muy menores...
>
> Qué otros datos podrían extraerse de ahí? Nombres de distritos censales en
> zonas rurales?
>
>
>
> 2017-09-21 19:12 GMT-03:00 Cristián Serpell :
>
>> Yo igual tendría cuidado de llegar y copiar. Vi algunos casos donde el
>> nombre de una calle se extiende por omisión donde se ve que no tenían el
>> dato, especialmente en zonas de límite urbano - rural. También hay nombres
>> desactualizados (comunas que cambian nombre de calles, especialmente las
>> nuevas que antes se llamaban calle 1, 2, 3, etc.). Siempre hay que usar
>> criterio e intentar validar con la mayor cantidad de fuentes posibles.
>>
>> ___
>> Talk-cl mailing list
>> Talk-cl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cl
>>
>>
>
>
> --
>
> Exequiel Gaete Pavez
> +56 9 9328 7569 <09%209328%207569>
>
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
>
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Marc Gemis]

I use the script "upload_exif.py" which is part of
https://github.com/openstreetcam/upload-scripts for OSC

for Mapillary, I just drop the files on their website (in your account
under uploads, there is an upload button). But they do have scripts as
well, probably https://github.com/mapillary/mapillary_tools




m.

On Fri, Sep 22, 2017 at 1:22 PM, ael  wrote:
> On Fri, Sep 22, 2017 at 09:26:53AM +0200, Marc Gemis wrote:
>>
>> I use a DSLR to take pictures, then georeference them, and then upload
>> them via a Jython script to OpenStreetCam. I use the Mapilary website
>> to upload them there as well. They have scripts to upload pictures as
>> well.
>
> I also do that (use geo tagged photographs) as well as use georeferenced
> dashcam video.  But neither OpenstreetCam nor Mapillary seemed to allow
> me to contribute such material which is generally of far higher quality
> than Smartphone video.  So I, for one, would be interested in the
> details: I didn't find anything on a quick search of the OpenStreetCam
> site.
>
> ael
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Daniel Patterson]

Hi Kieran,

  We don't, but I've done some profiling in the past, Docker itself should
have negligible impact.

  The two things that might be slowing things down:

1) The docker images don't bundle jemalloc (http://jemalloc.net/),
which can speed things up by 10-15%
2) osrm-contract is very CPU intensive - the more threads you give it,
the faster it will run.  Give it more if you can.

 256GB of RAM should be more than enough to avoid swapping, but you might
want to disable swap to be sure - if it's being used, it will have a huge
impact on speed.

daniel

On Fri, Sep 22, 2017 at 2:30 AM, Kieran Caplice 
wrote:

> Hi Daniel,
> Can you clarify if you use Docker at Mapbox? What kind of server do you
> guys have (if not the one described on the wiki page)?
>
> Over night, the process has gone to just 75% complete from 65% yesterday -
> 41 hours in total now, and back to maxing CPU again.
>
> Kind regards,
> Kieran Caplice
>
> On 21/09/17 17:17, Daniel Patterson wrote:
>
> OSRM supports *two* core routing algorithms - CH and MLD.  The
> `osrm-contract` tool generates the CH dataset, but you can use the MLD
> pipeline instead with:
>
> osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
> osrm-partition yourmap.osrm
> osrm-customize yourmap.osrm
> osrm-routed -a MLD yourmap.osrm
>
> This sequence of tools should be significantly quicker than osrm-contract
> - the price you pay is that routing requests are about 5x slower (still
> pretty fast though!).  The reason that MLD exists is for the
> `osrm-customize` step - it allows you to import traffic data very quickly
> and update the routing graph (~1 minute for North America).
>
> It's hard to say exactly what's going wrong with osrm-contract here - here
> at Mapbox, we daily run `osrm-contract` over the latest planet with the
> bicycle profile without a problem, however, Alex and others have reported
> issues with what seem like hangs on much smaller datasets that we've been
> unable to reproduce so far.
>
> The runtime of osrm-contract is affected by how much hierarchy exists in
> the data - the more similar the edge speeds (like in foot) and the more
> edges there are, the slower it gets, often in a non-linear fashion.  The
> car profile has a very hierarchical structure (many different road speeds),
> so it fits well into the CH, the construction algorithm  doesn't need to
> compare as many options.
>
> daniel
>
> On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice <
> kieran.capl...@temetra.com> wrote:
>
>> We're actually looking for the best of both car and foot, so in my head,
>> bicycle would be the happy medium (though I could be completely wrong on
>> this).
>> Kind regards,
>> Kieran Caplice
>>
>> On 21/09/17 16:53, Alex Farioletti wrote:
>>
>> i've run into the same issues, and now i just use metroextracts of the
>> areas that i need for the bike stuff i do and it reduces the time
>> significantly
>>
>> *Alex Farioletti*
>> *415.312.1674*
>> *tcbcourier.com  *
>>
>> On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice <
>> kieran.capl...@temetra.com> wrote:
>>
>>> Thanks Daniel.
>>>
>>> I'm using the bicycle profile, so I would expect based on what you've
>>> said that somewhere up to 36 hours would be likely. However, this is the
>>> current output, after 25h40m:
>>> [info] Input file: /data/1505492056/planet-latest.osrm
>>> [info] Threads: 12
>>> [info] Reading node weights.
>>> [info] Done reading node weights.
>>> [info] Loading edge-expanded graph representation
>>> [info] merged 2379332 edges out of 152432
>>> [info] initializing node priorities... ok.
>>> [info] preprocessing 389797971 (90%) nodes...
>>> [info] . 10% . 20% . 30% . 40% . 50% . 60%
>>>
>>> It hasn't advanced past 60% in the last 2-3 hours. It is however maxing
>>> CPU and using approximately the same amount of RAM since it started.
>>>
>>> Kind regards,
>>> Kieran Caplice
>>>
>>> On 21/09/17 16:39, Daniel Patterson wrote:
>>>
>>> Hi Kieran,
>>>
>>>   The contraction time will be slow - many, many hours for the whole
>>> planet.  *Typically* for the car profile it's about 12 hours, but if you
>>> use bike or foot, or your own profile, it can get a lot bigger.
>>>
>>>   If you've messed with the travel speeds, that can have a big effect
>>> too.  24 hours is not unheard of, but whether it's legit will depend a lot
>>> on the details.
>>>
>>> daniel
>>>
>>> On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice <
>>> kieran.capl...@temetra.com> wrote:
>>>
 Hi all,

 Could anyone give an approx estimate for the time required to run the
 osrm-contract on planet data on a 12 thread, 256 GB RAM, SSD machine?

 The osrm-extract process finished in 232 minutes, but the contract has
 now been running solid for 24 hours, and appears to be stuck at 60% on
 "preprocessing nodes". All 12 cores are generally maxed out, and the
 process is using nearly 90 GB of RAM.

 This is the second time I've run 

Re: [Talk-us] I-69 east west vs north south

[Josh Lee]

While it might be uncommon for two-digit Interstate highways to change
their directions, it's quite common for three-digit ones to do so, and
it shouldn't be treated any differently.

Some examples of changing direction, all of which are mapped as a
single relation for the state they're in, with cardinal directions for
the roles.

I-275 (Cincinnati)
I-270 (Columbus)
I-465 (Indianapolis)
I-495 (Washington, D.C.)

None of these have separate relations for the opposite directions,
just a single relation for the whole highway in that state.

Some other examples:

- I-64 in Virginia. South of I-264, it loses East/West signage (this
fact is not currently mapped in OSM)
- US 98 in Florida changes from EW to NS and back to EW (this fact is
not currently mapped in OSM).
- Ohio SR 104 changes from North/South to East/West near I-71, just
south of Columbus (mapped as cardinal directions for roles).

On Fri, Sep 22, 2017 at 1:32 AM, Bill Ricker  wrote:
> He seems to be correct, using the (not usable for mapping but usable
> to inform discussion) G-Streetview, I do indeed see signage as
> described, which defies commonly understood version of Fed standards.
> Not just BUSINESS route, not just when cotracking i-94, but actual
> green, solo "WEST 69 MILE 198" with red white and blue shield.
>
> Do we know if whether there is a Fed exemption, the Feds actually
> acknowledge that I-69 actually E-W beyond a certain point, and so can
> be E-W here?  Or if  the State of Michigan is defying Federal
> standards in the interest of being understandable? After the Feds
> threatened to pull our block grant $$ if we didn't renumber our exits
> their way, I'm amazed they're letting this slide when they could just
> rename the E-W section I-369 E-W  and it'd be a compliant extension of
> a N-S route. Perhaps the bureaucracy can be reasonable. [I spent a few
> years with DOT, not in Highway. Nice folks really.]
>
> (Probably not the only exception. There are 1xx/2xx/3xx/4xx that don't
> fit the spur/loop rule too.)
>
>
> (Frankly, I'm surprised any of 69's escutcheon route markers remain
> unstolen, like the 420 mile markers that keep wandering off.)
>
> So back to original question(s) --
> - who should fix the E-W section of I-69 to be E-W
> - how - split relation? relation of relation?
> - from where ?  At what point does signage change to E-W ?
>[and for mapping purposes no I'm NOT going to suggest we get that
> from a copyright source like StreeView, that needs free & open ground
> truth. ]
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us

___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-cl] Datos cartográficos desde mapas Precenso 2016/Censo2017

[Exequiel Gaete Pavez]

Pero no vienen los nombres de las calles en los archivos del Precenso
2016 (seguiré acá la respuesta)
En relación a las manzanas, recuerdo vi algunas diferencias en algunas
comunas de la RM (La Pintana), pero eran diferencias muy menores...

Qué otros datos podrían extraerse de ahí? Nombres de distritos censales en
zonas rurales?



2017-09-21 19:12 GMT-03:00 Cristián Serpell :

> Yo igual tendría cuidado de llegar y copiar. Vi algunos casos donde el
> nombre de una calle se extiende por omisión donde se ve que no tenían el
> dato, especialmente en zonas de límite urbano - rural. También hay nombres
> desactualizados (comunas que cambian nombre de calles, especialmente las
> nuevas que antes se llamaban calle 1, 2, 3, etc.). Siempre hay que usar
> criterio e intentar validar con la mayor cantidad de fuentes posibles.
>
> ___
> Talk-cl mailing list
> Talk-cl@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cl
>
>


-- 

Exequiel Gaete Pavez
+56 9 9328 7569
___
Talk-cl mailing list
Talk-cl@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cl

Re: [Talk-GB] OpenStreetCam or Mapillary?

[ael]

On Fri, Sep 22, 2017 at 09:26:53AM +0200, Marc Gemis wrote:
> 
> I use a DSLR to take pictures, then georeference them, and then upload
> them via a Jython script to OpenStreetCam. I use the Mapilary website
> to upload them there as well. They have scripts to upload pictures as
> well.

I also do that (use geo tagged photographs) as well as use georeferenced
dashcam video.  But neither OpenstreetCam nor Mapillary seemed to allow
me to contribute such material which is generally of far higher quality
than Smartphone video.  So I, for one, would be interested in the
details: I didn't find anything on a quick search of the OpenStreetCam
site.

ael


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Simon Poole]

While we would probably all love to be able to our hands on some
Hollywood magic (I just have s many photos that are just a tiny bit
too blurry to decipher  :-)) I suspect Marc was referring to reverting
back to the original non-blurred images, removing blurs added for
privacy reasons,

Simon


Am 22.09.2017 um 10:50 schrieb David Woolley:
> On 22/09/17 08:26, Marc Gemis wrote:
>
>> OSC's unblurring
>> functionality still does not work. So some signs might be unreadable
>> due to that
>
> De-convolution is only a miracle technology in TV forensics fiction.
> Whilst, with a carefully chosen scene and a very circular lens
> aperture it can make big improvements, you should still aim to take
> photographs that don't need it.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb




signature.asc
Description: OpenPGP digital signature
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Marc Gemis]

Then I would go with Wikipedia, you can more or less chose any open
license you want for the pictures.
Those pictures will show up next to Mapillary and OSC photo's on
http://projets.pavie.info/pic4carto/index.html

As to what is interesting:

we map:

* landuse
* POIs (shops, hotels, ...)
* destination signs
* traffic signs with max speed, weight, height
* bus stops
* etc. etc. etc. etc. etc. etc

so any picture with such info is welcome. But it really depends on
what one wants to map.

regards

On Fri, Sep 22, 2017 at 12:28 PM, James Harrison
 wrote:
>
> On 21/09/17 22:33, Simon Poole wrote:
>>
>>
>> while I don't have any first hand knowledge specifically about the
>> UK,  but continental Europe has a largish number of companies that do
>> that kind of photographic asset management professionally (and which
>> seem to have an at least half working business model because they
>> still exist). The results of the surveys they do tend to not be open
>> to the general public for privacy reasons and so on, but getting our
>> hands on that kind of material would be great. Naturally these kind of
>> things tend to be "slightly" more expensive than using a smart phone
>> camera.
>>
>
> I work for a company which is starting to do moderately large-scale
> survey work including 30MP georeferenced 90% sphere image capture in
> rural areas (generally in South/Midlands England). Not asset management,
> so we take photos everywhere in our areas of interest, which are usually
> villages and strung-out houses around them.
>
> While sharing every picture is probably unthinkable due to volume of
> data and other concerns, if a consensus as to a useful place to put some
> panoramic images emerges (and that has an API/licensing model we can
> work with) I'll certainly push for us to release what we can to OSM
> contributors if it would be useful.
>
> As an aside to this conversation, where are photos most useful for OSM
> contributions? Just built-up areas or road junctions etc? If we were
> designing a selector given a bunch of different capture locations, what
> would produce the most useful images for map editing?
>
> Cheers,
> James
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Changeset rimasto aperto

[Simone Saviolo]

Il giorno 22 settembre 2017 12:15, Daniele Forsi  ha
scritto:

> Il 22 settembre 2017 11:59, Simone Saviolo ha scritto:
>
> > Però il changeset è ancora aperto: cosa devo fare?
>
> la cosa più semplice è non fare niente perché verrà chiuso
> automaticamente dopo un'ora
>

Penso che farò questa, perché...


> oppure nel menu File di JOSM c'è una voce per vedere un elenco dei
> tuoi changeset aperti e scegliere quale chiudere


In teoria l'ho già fatto: quando ho ricaricato il changeset mi ha detto che
l'avrebbe caricato sul changeset numero X già aperto. Ma in pratica me ne
ha aperto uno nuovo...

Ciao,

Simone
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-us] Whole-US Garmin Map update - 2017-09-20

[Dave Hansen]

These are based off of Lambertus's work here:

http://garmin.openstreetmap.nl

If you have questions or comments about these maps, please feel
free to ask.  However, please do not send me private mail.  The
odds are, someone else will have the same questions, and by
asking on the talk-us@ list, others can benefit.

Downloads:

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-09-20

Map to visualize what each file contains:


http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-09-20/kml/kml.html


FAQ



Why did you do this?

I wrote scripts to joined them myself to lessen the impact
of doing a large join on Lambertus's server.  I've also
cut them in large longitude swaths that should fit conveniently
on removable media.  

http://daveh.dev.openstreetmap.org/garmin/Lambertus/2017-09-20

Can or should I seed the torrents?

Yes!!  If you use the .torrent files, please seed.  That web
server is in the UK, and it helps to have some peers on this
side of the Atlantic.

Why is my map missing small rectangular areas?

There have been some missing tiles from Lambertus's map (the
red rectangles),  I don't see any at the moment, so you may
want to update if you had issues with the last set.

Why can I not copy the large files to my new SD card?

If you buy a new card (especially SDHC), some are FAT16 from
the factory.  I had to reformat it to let me create a >2GB
file.

Does your map cover Mexico/Canada?

Yes!!  I have, for the purposes of this map, annexed Ontario
in to the USA.  Some areas of North America that are close
to the US also just happen to get pulled in to these maps.
This might not happen forever, and if you would like your
non-US area to get included, let me know. 

-- Dave


___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-GB] OpenStreetCam or Mapillary?

[James Harrison]

On 21/09/17 22:33, Simon Poole wrote:
>
>
> while I don't have any first hand knowledge specifically about the
> UK,  but continental Europe has a largish number of companies that do
> that kind of photographic asset management professionally (and which
> seem to have an at least half working business model because they
> still exist). The results of the surveys they do tend to not be open
> to the general public for privacy reasons and so on, but getting our
> hands on that kind of material would be great. Naturally these kind of
> things tend to be "slightly" more expensive than using a smart phone
> camera.
>

I work for a company which is starting to do moderately large-scale
survey work including 30MP georeferenced 90% sphere image capture in
rural areas (generally in South/Midlands England). Not asset management,
so we take photos everywhere in our areas of interest, which are usually
villages and strung-out houses around them.

While sharing every picture is probably unthinkable due to volume of
data and other concerns, if a consensus as to a useful place to put some
panoramic images emerges (and that has an API/licensing model we can
work with) I'll certainly push for us to release what we can to OSM
contributors if it would be useful.

As an aside to this conversation, where are photos most useful for OSM
contributions? Just built-up areas or road junctions etc? If we were
designing a selector given a bunch of different capture locations, what
would produce the most useful images for map editing?

Cheers,
James


___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Changeset rimasto aperto

[Daniele Forsi]

Il 22 settembre 2017 11:59, Simone Saviolo ha scritto:

> Però il changeset è ancora aperto: cosa devo fare?

la cosa più semplice è non fare niente perché verrà chiuso
automaticamente dopo un'ora

oppure nel menu File di JOSM c'è una voce per vedere un elenco dei
tuoi changeset aperti e scegliere quale chiudere

-- 
Daniele Forsi

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Changeset rimasto aperto

[Damjan Gerl]

Guarda in josm che c'è una opzione/comando per chiudere il changeset.

Damjan

-- Original Header ---

From  : "Simone Saviolo" simone.savi...@gmail.com
To  : "openstreetmap list - italiano" talk-it@openstreetmap.org
Cc  : 
Date  : Fri, 22 Sep 2017 11:59:42 +0200
Subject : [Talk-it]  Changeset rimasto aperto

> Ciao a tutti,
> 
> ho caricato un changeset tramite JOSM, e per via di un bug già riportato
> l'upload si è bloccato con un messaggio "postprocessing uplaoded data". Il
> changeset [1] è rimasto aperto, e tramite JOSM l'ho recuperato, caricato
> una seconda volta, poi ho già tolto i duplicati.
> 
> Però il changeset è ancora aperto: cosa devo fare?
> 
> Grazie,
> 
> Simone
> 
> [1] http://www.openstreetmap.org/changeset/52270405#map=15/45.0825/8.1476
> 

___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[Jo]

I don't really mind having Mapillary in there, but if you do, you'd have to
mention OpenStreetCam as well, of course.

When I go out to survey using making Mapillary pictures, it's true I'm not
adding data using Vespucci or Walking Papers, but I wouldn't do those
things anyway.

Making automated picture sequences doesn't really get in the way of what
I'm actuallly doing, cycling, or walking.

When couch mapping they are often really handy to have and work with, so I
definitely helps us. Aerial imagery is great, but even at high resolution
it's not possible to see every detail on it.

Jo

2017-09-22 11:57 GMT+02:00 Tobias Knerr :

> On 21.09.2017 19:45, PanierAvide wrote:
> > http://projets.pavie.info/whatosm/
>
> This may be controversial, but I don't think a guide for people
> considering to contribute to OSM should send them away to Mapillary.
> They aren't part of OSM proper and arguably compete with us for
> volunteer time. Mapillary let us use their images, of course, but they
> have that in common with a lot of other orgs that no one would mistake
> for being part of the OSM project.
>
> > It can be used by new contributors, but also more experimented ones, who
> > don't know what to do anymore in their neighbourhood.
>
> For new contributors, the recommendations feel a bit too focused on
> niche use cases, and not enough on core OSM. When people have a few
> hours or days to spare and want to contribute to OSM, then I would
> almost always recommend that they start mapping in their local area
> using iD or JOSM (depending on computer skills).
>
> Something else to consider is that "outside" and "remotely" does not
> cover the entire OSM experience. In fact, the traditional way to
> contribute is to collect data outside, and enter it back at home. Right
> now, that's not an option with your tool.
>
> Hope this mail doesn't come across as too negative! I mostly focussed on
> potential improvements rather than the things that worked fine for me
> (i.e. everything not mentioned here).
>
> Tobias
>
>
>  It might be
> > interested to show this to people when doing mapping parties. User
> > interface works as well on desktop as on smartphone.
> >
> > This project is open source and is available on this repository :
> >
> > https://framagit.org/PanierAvide/WhatOSM
> >
> > You can contribute to it by proposing tools which allow contributing
> > more or less directly to OpenStreetMap. Also, if you speak English +
> > another language, you can help translating the application :
> >
> > https://www.transifex.com/openlevelup/whatosm/
> >
> > If you have any ideas or suggestions, let me know :-)
> >
> > Regards,
> >
> > Adrien.
> >
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[Tobias Knerr]

On 21.09.2017 19:45, PanierAvide wrote:
> http://projets.pavie.info/whatosm/

This may be controversial, but I don't think a guide for people
considering to contribute to OSM should send them away to Mapillary.
They aren't part of OSM proper and arguably compete with us for
volunteer time. Mapillary let us use their images, of course, but they
have that in common with a lot of other orgs that no one would mistake
for being part of the OSM project.

> It can be used by new contributors, but also more experimented ones, who
> don't know what to do anymore in their neighbourhood.

For new contributors, the recommendations feel a bit too focused on
niche use cases, and not enough on core OSM. When people have a few
hours or days to spare and want to contribute to OSM, then I would
almost always recommend that they start mapping in their local area
using iD or JOSM (depending on computer skills).

Something else to consider is that "outside" and "remotely" does not
cover the entire OSM experience. In fact, the traditional way to
contribute is to collect data outside, and enter it back at home. Right
now, that's not an option with your tool.

Hope this mail doesn't come across as too negative! I mostly focussed on
potential improvements rather than the things that worked fine for me
(i.e. everything not mentioned here).

Tobias


 It might be
> interested to show this to people when doing mapping parties. User
> interface works as well on desktop as on smartphone.
> 
> This project is open source and is available on this repository :
> 
> https://framagit.org/PanierAvide/WhatOSM
> 
> You can contribute to it by proposing tools which allow contributing
> more or less directly to OpenStreetMap. Also, if you speak English +
> another language, you can help translating the application :
> 
> https://www.transifex.com/openlevelup/whatosm/
> 
> If you have any ideas or suggestions, let me know :-)
> 
> Regards,
> 
> Adrien.
> 



___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[Talk-it] Changeset rimasto aperto

[Simone Saviolo]

Ciao a tutti,

ho caricato un changeset tramite JOSM, e per via di un bug già riportato
l'upload si è bloccato con un messaggio "postprocessing uplaoded data". Il
changeset [1] è rimasto aperto, e tramite JOSM l'ho recuperato, caricato
una seconda volta, poi ho già tolto i duplicati.

Però il changeset è ancora aperto: cosa devo fare?

Grazie,

Simone

[1] http://www.openstreetmap.org/changeset/52270405#map=15/45.0825/8.1476
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] OpenStreetCam or Mapillary?

[paul.bivand]

Hi everyone 
I'd have thought that from a TfWM point of view, Mapillary pics going through 
to HERE would be a positive advantage. 
If they want their junction changes to be immediately available and working for 
a wide range of routing providers and self driving vehicles that is. 
Paul


Sent from my Samsung Galaxy smartphone.
 Original message From: Simon Poole  Date: 
21/09/2017  22:33  (GMT+00:00) To: talk-gb@openstreetmap.org Subject: Re: 
[Talk-GB] OpenStreetCam or Mapillary? 

Not commenting directly on the pros and cons, but through their
  cooperation with Here using mapillary for this would make the
  material directly available to a competitor too. Now you can
  consider this a good thing or bad, but in any case it needs to be
  considered.


Slightly OT;


while I don't have any first hand knowledge specifically about
  the UK,  but continental Europe has a largish number of companies
  that do that kind of photographic asset management professionally
  (and which seem to have an at least half working business model
  because they still exist). The results of the surveys they do tend
  to not be open to the general public for privacy reasons and so
  on, but getting our hands on that kind of material would be great.
  Naturally these kind of things tend to be "slightly" more
  expensive than using a smart phone camera.


Simon




Am 21.09.2017 um 20:09 schrieb Brian
  Prangle:



  

  

  Hi everyone



  
  I'm in discussions with Transport for West Midlands to use
  their inspection teams'  time on the street to assist us
  by taking photos with smartphones, which will also help
  them with their asset management and not have to rely on
  outdated data from Google StreetView.

  


Which one of the above is better for us? Or just plain
better?



  
  Regards

  


Brian

  
  

  
  

  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb




  ___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSRM-talk] Expecting time for osrm-contract for planet

[Kieran Caplice]

Hi Daniel,

Can you clarify if you use Docker at Mapbox? What kind of server do you 
guys have (if not the one described on the wiki page)?


Over night, the process has gone to just 75% complete from 65% yesterday 
- 41 hours in total now, and back to maxing CPU again.


Kind regards,
Kieran Caplice

On 21/09/17 17:17, Daniel Patterson wrote:
OSRM supports *two* core routing algorithms - CH and MLD.  The 
`osrm-contract` tool generates the CH dataset, but you can use the MLD 
pipeline instead with:


osrm-extract -p profiles/bicycle.lua yourmap.osm.pbf
osrm-partition yourmap.osrm
osrm-customize yourmap.osrm
osrm-routed -a MLD yourmap.osrm

This sequence of tools should be significantly quicker than 
osrm-contract - the price you pay is that routing requests are about 
5x slower (still pretty fast though!).  The reason that MLD exists is 
for the `osrm-customize` step - it allows you to import traffic data 
very quickly and update the routing graph (~1 minute for North America).


It's hard to say exactly what's going wrong with osrm-contract here - 
here at Mapbox, we daily run `osrm-contract` over the latest planet 
with the bicycle profile without a problem, however, Alex and others 
have reported issues with what seem like hangs on much smaller 
datasets that we've been unable to reproduce so far.


The runtime of osrm-contract is affected by how much hierarchy exists 
in the data - the more similar the edge speeds (like in foot) and the 
more edges there are, the slower it gets, often in a non-linear 
fashion.  The car profile has a very hierarchical structure (many 
different road speeds), so it fits well into the CH, the construction 
algorithm  doesn't need to compare as many options.


daniel

On Thu, Sep 21, 2017 at 9:03 AM, Kieran Caplice 
> wrote:


We're actually looking for the best of both car and foot, so in my
head, bicycle would be the happy medium (though I could be
completely wrong on this).

Kind regards,
Kieran Caplice

On 21/09/17 16:53, Alex Farioletti wrote:

i've run into the same issues, and now i just use metroextracts
of the areas that i need for the bike stuff i do and it reduces
the time significantly

*Alex Farioletti*
*415.312.1674*
/tcbcourier.com  /

On Thu, Sep 21, 2017 at 8:49 AM, Kieran Caplice
>
wrote:

Thanks Daniel.

I'm using the bicycle profile, so I would expect based on
what you've said that somewhere up to 36 hours would be
likely. However, this is the current output, after 25h40m:

[info] Input file: /data/1505492056/planet-latest.osrm
[info] Threads: 12
[info] Reading node weights.
[info] Done reading node weights.
[info] Loading edge-expanded graph representation
[info] merged 2379332 edges out of 152432
[info] initializing node priorities... ok.
[info] preprocessing 389797971 (90%) nodes...
[info] . 10% . 20% . 30% . 40% . 50% . 60%

It hasn't advanced past 60% in the last 2-3 hours. It is
however maxing CPU and using approximately the same amount of
RAM since it started.

Kind regards,
Kieran Caplice

On 21/09/17 16:39, Daniel Patterson wrote:

Hi Kieran,

  The contraction time will be slow - many, many hours for
the whole planet.  *Typically* for the car profile it's
about 12 hours, but if you use bike or foot, or your own
profile, it can get a lot bigger.

  If you've messed with the travel speeds, that can have a
big effect too.  24 hours is not unheard of, but whether
it's legit will depend a lot on the details.

daniel

On Thu, Sep 21, 2017 at 7:00 AM, Kieran Caplice
> wrote:

Hi all,

Could anyone give an approx estimate for the time
required to run the osrm-contract on planet data on a 12
thread, 256 GB RAM, SSD machine?

The osrm-extract process finished in 232 minutes, but
the contract has now been running solid for 24 hours,
and appears to be stuck at 60% on "preprocessing nodes".
All 12 cores are generally maxed out, and the process is
using nearly 90 GB of RAM.

This is the second time I've run the contract process,
as my SSH connection to the server dropped the first
time and the process wasn't running in a screen etc, so
I assumed after the 40-odd hours it was running for, the
connection drop caused it to hang, but now I'm not so
sure. Were there any files I should maybe have cleared
before trying to run it again?

I'm using 

[Talk-it] Aggiornamento codici ISTAT in Sardegna.

[Paolo F]

Buongiorno lista,
ho notato che diversi comuni della Sardegna (155) hanno cambiato codice
ISTAT come riportato nel sito stesso di ISTAT (
http://www.istat.it/it/archivio/6789).
Avrei gia' pronto uno script per provvedere ad un'aggiornamento automatico
del tag "ref:ISTAT".
Se non vi e' nulla in contrario procederei, mantenendo comunque anche
l'informazione del vecchio codice in un nuovo tag: "old_ref:ISTAT".

Ciao, Paolo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Marc Gemis]

When you attach the smartphone to the front window of your car or on
the bar of a bicycle, there is not much aiming involved. The apps keep
on taking pictures. The pictures that are taken do not contain blurred
sections, only the ones you can access via the website. On Mapillary,
you can indicate which areas you want to be blurred besides the
automatically detected areas, and deblur pieces that should not be
blurred. As they keep the original photo without any blurs somewhere
on their servers, that should not be a problem. No TV magic involved.

Since I prefer full access to the original pictures that I have taken,
I prefer the digital reflex approach. But for destination signs on
motorways and other main roads, OSC/Mapillary might be the only way to
catch those images.

m.

On Fri, Sep 22, 2017 at 10:50 AM, David Woolley
 wrote:
> On 22/09/17 08:26, Marc Gemis wrote:
>
>> OSC's unblurring
>> functionality still does not work. So some signs might be unreadable
>> due to that
>
>
> De-convolution is only a miracle technology in TV forensics fiction. Whilst,
> with a carefully chosen scene and a very circular lens aperture it can make
> big improvements, you should still aim to take photographs that don't need
> it.
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Which tool for OSM, a guide for contribution tools (was WhatOSM)

[PanierAvide]

Hello,

Everyone concerned by naming issues might be interested to know that 
name was changed into "Which tool for OSM ?" in user interface and 
documentation. Also, a clear disclaimer was added into the repository 
README about the absence of link with OSMF. I hope this is enough for 
complying with future trademark policy.


Regards,

Adrien.


Le 21/09/2017 à 19:45, PanierAvide a écrit :

Hi everyone,

As you may know, OSM has a whole set of tools allowing various 
thematic editing and contribution. Every contributor can find 
something to do, however when you are new to this world, you don't 
where these tools are and which one is made for you.


In order to make it easier discovering contribution tools, and find 
the ones according to what you want to work on, I made a little web 
guide named WhatOSM. When answering three questions (level of 
difficulty, available time and if you are indoors/outdoors), you have 
a list of corresponding tools. You can try it here :


http://projets.pavie.info/whatosm/

It can be used by new contributors, but also more experimented ones, 
who don't know what to do anymore in their neighbourhood. It might be 
interested to show this to people when doing mapping parties. User 
interface works as well on desktop as on smartphone.


This project is open source and is available on this repository :

https://framagit.org/PanierAvide/WhatOSM

You can contribute to it by proposing tools which allow contributing 
more or less directly to OpenStreetMap. Also, if you speak English + 
another language, you can help translating the application :


https://www.transifex.com/openlevelup/whatosm/

If you have any ideas or suggestions, let me know :-)

Regards,

Adrien.




___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Gregory]

The relevant background/motives as I understand them...

Both currently aren't too limited on funds & I licensing might allow all
photos/data to be taken for OSM if they did close down.

Mapillary is a startup for the street-level photo viewing technology.
Seemingly other things now like 3D models from point clouds made from photo
pixels. Free for us is good for them because it creates mass data to
demonstrate the tech, or helps find UI needs/desires. It could all turn off
if it's

OpenStreetCam is from Telenav. Free for us is good for them because we then
improve OpenStreetMap which they use. They might be less interested in
keeping historic versions of photos, and less interested in UI (except UI
concerning uploading photos or viewing to edit OSM).


I think I've  given up contributing atm, because I don't know which one I
care about more & I haven't set up an easy process to do both in one go. I
also had issues with Mapillary viewer only supporting the most recent
browsers.

Gregory (LivingWithDragons)

On 22 Sep 2017 8:28 am, "Marc Gemis"  wrote:

> (Second try, the first one went only to Neil)
>
> Slightly off-topic, but answering Neil's questions:
>
> I use a DSLR to take pictures, then georeference them, and then upload
> them via a Jython script to OpenStreetCam. I use the Mapilary website
> to upload them there as well. They have scripts to upload pictures as
> well.
>
> Recently I started using OruxMap and use their photo way points in the
> way you describe for OSM tracker.
>
> back on topic:
> Mapillary is more advanced in the type of objects they can extract
> from a photo. OSC can only do traffic signs. OSC's unblurring
> functionality still does not work. So some signs might be unreadable
> due to that
>
> For walking I still prefer a method that takes less pictures, but
> better framed pictures. I do not have the time to wade through
> hundreds of "useless" pictures of paths.
>
> I'll agree with Simon that the Mapillary-Here deal is something to think
> about.
>
> regards
>
> On Fri, Sep 22, 2017 at 12:24 AM, Neil Matthews 
> wrote:
> > I've tried Mapillary -- not tried OpenStreetCam yet.
> >
> > Comments mostly relate to the Mapillary Android app:
> >
> > Mapillary App drove me nuts until I worked out how to take photos
> > individually when walking, rather than as a continuous sequence - more
> car
> > oriented?
> > Seems to be moderately "fussy" about getting a GPS lock.
> > Takes a long while to upload images over WiFi.
> > Images are removed after loading on WiFi - so can't keep a backup, e.g.
> to
> > upload to a second site.
> > Battery life may be impacted severely.
> > Mapillary has a JOSM plugin.
> >
> > Personally, I think something like running OSM tracker (or a real GPS)
> > and/or using naive Android photo GPS tagging might be good.
> > Find a good scripting mechanism to upload - without using the App?
> Upload to
> > either Mapillary / OpenStreetCam / both?
> > Maybe a battery pack?
> >
> > There's also a thought that you might even want to pick the least
> well-used
> > site -- so that it's easier to find "your own" pictures -- you may find a
> > lot of less relevant shots on popular roads from others (motorists).
> > It may be worth seeing how easy it is to filter them by user or
> time/date on
> > each site.
> >
> > Neil
> >
> >
> > On 21/09/2017 19:09, Brian Prangle wrote:
> >
> > Hi everyone
> >
> > I'm in discussions with Transport for West Midlands to use their
> inspection
> > teams'  time on the street to assist us by taking photos with
> smartphones,
> > which will also help them with their asset management and not have to
> rely
> > on outdated data from Google StreetView.
> >
> > Which one of the above is better for us? Or just plain better?
> >
> > Regards
> >
> > Brian
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> >
> >
> >
> > ___
> > Talk-GB mailing list
> > Talk-GB@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-gb
> >
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[PanierAvide]

Hello,

Thanks for this idea. In fact these videos can have an interesting value 
for mapping. I opened an issue on the repository : 
https://framagit.org/PanierAvide/Pic4Carto.js/issues/33


I'm not very sure yet how to query Wikimedia Commons to retrieve these 
videos, I have to read some docs ! :-)


Regards,

Adrien.


Le 22/09/2017 à 08:12, Oleksiy Muzalyev a écrit :

Good morning Adrien,

I have an idea how to improve it. For example, for this lake 
http://projets.pavie.info/pic4carto/index.html?from=1490466554238#17/46.35173/6.79455

I see three photos from Wikimedia category all right.

But I do not see the 1 minute 19 seconds video of this lake in .webm 
format, which is also in the lake's Wikimeida category and which was 
published on the same date with these photos:

https://commons.wikimedia.org/wiki/Category:Lac_de_Lovenex

The video files has got the correct coordinates, the same as photos, - 
I just verified it.


I checked with another places, which have a video, for instance 
https://en.wikipedia.org/wiki/Lac_de_Salanfe . And videos are not 
shown on the Pic4Carto. A short HD or 4K video, especially filmed in 
good light conditions from the air, provides a lot of details about a 
place, what could be sometimes very useful for mapping. By the way, 
Google Maps recently also announced that short videos, up to 30 
seconds could be added to its commercial map.


Wikimedia accepts videos only in free .webm format ( 
https://en.wikipedia.org/wiki/WebM ).


Best regards,
Oleksiy

On 21.09.17 21:03, PanierAvide wrote:

Thank you, let me know if you have any ideas to improve it :-)

Regards,

Adrien.


Le 21/09/2017 à 20:53, Oleksiy Muzalyev a écrit :

Hi Adrien,

I tested the Pic4Carto application on photos which I added recently 
to Wikimedia. It works just fine. Very impressive. I will 
definitively use it.


Best regards,
Oleksiy







___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] OpenStreetCam or Mapillary?

[Marc Gemis]

(Second try, the first one went only to Neil)

Slightly off-topic, but answering Neil's questions:

I use a DSLR to take pictures, then georeference them, and then upload
them via a Jython script to OpenStreetCam. I use the Mapilary website
to upload them there as well. They have scripts to upload pictures as
well.

Recently I started using OruxMap and use their photo way points in the
way you describe for OSM tracker.

back on topic:
Mapillary is more advanced in the type of objects they can extract
from a photo. OSC can only do traffic signs. OSC's unblurring
functionality still does not work. So some signs might be unreadable
due to that

For walking I still prefer a method that takes less pictures, but
better framed pictures. I do not have the time to wade through
hundreds of "useless" pictures of paths.

I'll agree with Simon that the Mapillary-Here deal is something to think about.

regards

On Fri, Sep 22, 2017 at 12:24 AM, Neil Matthews  wrote:
> I've tried Mapillary -- not tried OpenStreetCam yet.
>
> Comments mostly relate to the Mapillary Android app:
>
> Mapillary App drove me nuts until I worked out how to take photos
> individually when walking, rather than as a continuous sequence - more car
> oriented?
> Seems to be moderately "fussy" about getting a GPS lock.
> Takes a long while to upload images over WiFi.
> Images are removed after loading on WiFi - so can't keep a backup, e.g. to
> upload to a second site.
> Battery life may be impacted severely.
> Mapillary has a JOSM plugin.
>
> Personally, I think something like running OSM tracker (or a real GPS)
> and/or using naive Android photo GPS tagging might be good.
> Find a good scripting mechanism to upload - without using the App? Upload to
> either Mapillary / OpenStreetCam / both?
> Maybe a battery pack?
>
> There's also a thought that you might even want to pick the least well-used
> site -- so that it's easier to find "your own" pictures -- you may find a
> lot of less relevant shots on popular roads from others (motorists).
> It may be worth seeing how easy it is to filter them by user or time/date on
> each site.
>
> Neil
>
>
> On 21/09/2017 19:09, Brian Prangle wrote:
>
> Hi everyone
>
> I'm in discussions with Transport for West Midlands to use their inspection
> teams'  time on the street to assist us by taking photos with smartphones,
> which will also help them with their asset management and not have to rely
> on outdated data from Google StreetView.
>
> Which one of the above is better for us? Or just plain better?
>
> Regards
>
> Brian
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-cz] OdBL a komercni vyuziti mapy Re: Import dat do QGisu

[Vladimír Semotán]

Ahoj,
jo, pardon. Je to vlastně taková hierarchie různě detailních TIN. Jde o to,
že geometrie (3d model) ČR má třeba několik stovek GB a při dohlednosti
přes 100 km by to žádná grafická karta neutáhla. Proto se to dělá takhle.
Těch způsobů je vícero. Je to uplně stejné, jako v PC hrách.

V.

Dne 21. září 2017 23:49 Jan Macura  napsal(a):

> Ahoj,
>
> 2017-09-21 23:34 GMT+02:00 Pavel Machek :
>
>> Uplne nevim jak vypada 3D teren. Mozna je to spis obrazek nez
>> databaze. Kazdopadne tohle je otazka pro pravniky...
>>
>> právě jsi to slyšel (četl..) – v tomhle případě je to forma TIN
> . A
> pro právníky to moc otázka není, možná pro soudní znalce, třeba..
>
> H.
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] WhatOSM, a guide for contribution tools

[Oleksiy Muzalyev]

Good morning Adrien,

I have an idea how to improve it. For example, for this lake 
http://projets.pavie.info/pic4carto/index.html?from=1490466554238#17/46.35173/6.79455

I see three photos from Wikimedia category all right.

But I do not see the 1 minute 19 seconds video of this lake in .webm 
format, which is also in the lake's Wikimeida category and which was 
published on the same date with these photos:

https://commons.wikimedia.org/wiki/Category:Lac_de_Lovenex

The video files has got the correct coordinates, the same as photos, - I 
just verified it.


I checked with another places, which have a video, for instance 
https://en.wikipedia.org/wiki/Lac_de_Salanfe . And videos are not shown 
on the Pic4Carto. A short HD or 4K video, especially filmed in good 
light conditions from the air, provides a lot of details about a place, 
what could be sometimes very useful for mapping. By the way, Google Maps 
recently also announced that short videos, up to 30 seconds could be 
added to its commercial map.


Wikimedia accepts videos only in free .webm format ( 
https://en.wikipedia.org/wiki/WebM ).


Best regards,
Oleksiy

On 21.09.17 21:03, PanierAvide wrote:

Thank you, let me know if you have any ideas to improve it :-)

Regards,

Adrien.


Le 21/09/2017 à 20:53, Oleksiy Muzalyev a écrit :

Hi Adrien,

I tested the Pic4Carto application on photos which I added recently 
to Wikimedia. It works just fine. Very impressive. I will 
definitively use it.


Best regards,
Oleksiy





___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk