date:20170906

[Talk-us] Tampa/Clearwater Building Import to aid in Irma Recovery Efforts

2017-09-06 Diskussionsfäden Clifford Snow

The Tampa/Clearwater building import [1] wiki page is available. Basically
this import is to add building outlines provided by Microsoft [2] to aid in
Irma Recovery efforts. It will use the Tasking Manager for the import
process.

The import, like the Corpus Christi import, requires JOSM. For people
familiar with JOSM, this is a fairly easy import.

I expect to have the Project available shortly.


[1] https://wiki.openstreetmap.org/wiki/Tampa,_Florida_Building_Import
[2] https://wiki.openstreetmap.org/wiki/Microsoft_Building_Footprint_Data

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-us] Hurricane Irma - Puerto Rico

2017-09-06 Diskussionsfäden Marc Gemis

The hot task manager http://tasks.hotosm.org/ already lists 4 tasks :
3499, 3501, 3502 and 3504

regards

m.

On Wed, Sep 6, 2017 at 5:33 AM, Jordan Brod  wrote:
> Hey all,
>
> I was curious if anybody was planning to do a response similar to what was
> done in the Houston area for Puerto Rico (technically part of the US) in
> regards to Irma.  From looking at the map San Juan looks to be well mapped
> but the other areas seem to be lacking in building footprints.  The reason I
> ask is that with Puerto Rico being a commonwealth / unincorporated territory
> of the U.S. and not a state I don't know what kind of attention they will
> receive from FEMA or any of the other federal disaster departments, and if
> they are really hamstrung on data we might be able to offer assistance.  I
> don't think HOT will do an activation for Puerto Rico since they are part of
> the U.S. even if not an official state, and from the looks of the current
> response they are only activating for islands that have requested their
> help.
>
> ___
> 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: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-06 Diskussionsfäden Jo

Depuis quelques mois nous avons enfin une façon de taguer les bus_bay. Pour
les ajouter le chemin est également découpé deux fois. S'il se trouve sur
le rond-point c'est une autre raison pour le découper.

Dire que c'est au rendu de dessiner les lignes de bus en partiel sur les
rond-points, c'est facile. Néanmoins, ce n'est pas quelque chose qui sera
implémenté dans un futur proche. Probablement jamais. Diviser les
rond-points, c'est quelque chose qu'un mappeur peut faire facilement et ça
ne heurte personne. Ça décrit très précisement les trajets des bus, surtout
quand la même ligne emprunte le rond-point plusieurs fois, ou s'il
n'emprunte pas certaines parties, parce qu'il y a des 'fourches' en oneway
avant ou derrière.

Polyglot

2017-09-07 1:52 GMT+02:00 Philippe Verdy :

> Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
> détectable même et surtout si c'est un way fermé. Si le dessin du cercle
> est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
> pas une ligne mais un disque, assimilable à un point un peu plis gros en
> son centre. De plus un bus peut encore être amené à faire plus que 1 tour
> s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la ligne.
>
> C'est pareil pour les itinéraires routiers pour automobiles, camions ou
> cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
> de passer par le centre d'un grand giratoire en passant par des passages
> protégés, ce chemin sera marqué de même que les connexions aux rues
> arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
> circulaire du giratoire.
>
> Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
> les giratoires ne sert pas à grand chose.
>
> Je n'ai vus que quelques seul cas où ça peut être utile
> - : si le giratoire passe emprunte des ponts au dessus d'autres voies
> routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
> évitant le giratoire. Le but étant alors de mettre des attributs différents
> sur des sections du giratoire, notamment les barrières de sécurité (mais on
> peut aussi représenter ces barrières sur des chemins parallèles.) mais
> surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
> passer en mettant le layer sur les voies qui traversent en dessous.
> - Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
> le couper (ce sont ces ponts qu'on va découper éventuellement)
> - Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
> voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
> pourrait être gêné par le fait que ce layer passe alors aussi en dessous
> des "landuse" environnants s'ils englobent la surface du giratoire
>
> Certains veulent découper les giratoires à ponts pour uniquement le rendu
> (qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
> par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
> en surimpression des voies connectées (comme si ce filet noir était des
> barrières barrant les accès). On peut faire autrement en évitant
> "bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
> les voies en dessous, et en ajoutant les barrières de sécurité de chaque
> côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
> giratoire".
>
> Pour les assistants de navigation GPS, ils disent "entrez dans le
> giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
> pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
> rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
> retrouver et n'a pas besoin de toucher à son GPS!
>
> Il reste les rares cas de giratoires avec des feux temporaires
> (fonctionnant en giratoire la plupart du temps quand les feux sont éteints
> mais en carrefour avec des voies plus prioritaires qui les traversent quand
> les feux sont allumés). Cela ne concerne que de rares giratoires qui ont
> une voie centrale pour les transports en commun munis de radiocommande ou
> de télédétections des véhicules de transport en commun. On en trouve pas
> mal à Nantes avec les carrefours utilisés aussi par les trams toujours
> prioritaires (il y a des feux clignotants signalant l'approche d'une rame
> et l'arrêt impératif de tous les autres usagers, mais là encore pas besoin
> de découper le giratoire car le tram n'emprunte pas les mêmes voies).
>
> Les derniers cas sont les ceux où un giratoire est temporairement
> partiellement fermé  (par exemple un accident de la route ou des travaux):
> la police ou des feux temporaires seront là pour rendre les autres sections
> du giratoire bidirectionnelles ou unidirectionnelle alternée, et le faire
> fonctionner comme un carrefour normal mais ce n'est jamais pour longtemps
> (quelques heures pour un accident routier, quelques heures s'il y a des
> travaux sur un giratoire

Re: [OSM-ja] How to Map Aの、畦道のためのタグ

2017-09-06 Diskussionsfäden Satoshi IIDA

いいだです。

みなさまご意見ありがとうございます。

ひとまず並べると、こんなかんじでしょうか。

* だいたい合意されてる事項
footwayじゃないよね

* 代替となるタグ
1. highway=path
2. そもそもhighwayにするのがよくないのでは？


で、代替となるタグなのですが、確かにpathがよいのかな、と思います。
主に農業のなかで使うのであればtrackかな？と思ったのですが、
pathのOSM wikiをみると、用途が指定されていない、とあって、
僕の認識が間違っていたようでした。
（pathは、highway=roadのように、目的が不明な場合のタグの印象があった）

> highway =*path* is a *generic
path*, either multi-use or unspecified usage, open to all non-motorized
vehicles.

https://wiki.openstreetmap.org/wiki/Tag:highway%3Dpath

ここに、必要に応じて、foot=agriculturalのようなアクセス制限をつけてゆくのがよいのかな、と。

浅野さんから指摘いただいた、「そもそも道じゃないのでは」という指摘は、
僕もあまのさんからの回答と同様です。
子供の頃に、よく通っていた、という実体験もあって、
農業などで通ることのできる場所であるし、
それならばなんらかの通行できることを示すタグをつけたほうがよいのではないか、という考えです。





2017年9月6日 19:57 Ryosuke Amano :

>
> 横浜のあまのです。
> 確かに浅野さんがおっしゃることは、全く正しく異論はありません。
> ただ今回、いいださんが問題提議した事例は、そうした田畑や用水との界を地元の慣例的に通行の便に供している、そのような箇所を「畦道」としてどうしようか？
> そういう観点ではないでしょうか？
>
> #法務局公図の二線引きや畦畔の問題みたい…
>
>
>  元のメッセージ 
> 件名: Re: [OSM-ja] How to Map Aの、畦道のためのタグ
> From: 浅野和仁
> To: OpenStreetMap Japanese talk
> Cc:
>
>
> 浅野です。
>
> そもそも、あぜ道を「道」と捉えるのは、いかがなものでしょうか。通行を目的としたものではなく、地物としては、構囲や植生界に近いものと思います。
> 田畑を一枚ずつ描画すれば、事足りると思うのですが。
>
> helicobacter_y...@hera.eonet.ne.jp
> 浅野和仁
>
>
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
>


-- 
Satoshi IIDA
mail: nyamp...@gmail.com
twitter: @nyampire
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[Talk-us] Emergency Shelters

2017-09-06 Diskussionsfäden Nick Hocking

Are the emergency shelters currently mapped in OSM?

I think that it would be really useful, in an emergency to have these
locations available on your phone or watch as offline routable maps
(including whether they are pet friendly).

Maybe in the next few months we could convince/help all states to import
their data into OSM.


PS - I've just bought a waterproof Garmin Epix watch and loaded routable
OSM maps to it. Turn by turn navigation works really well on it.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Champs phone : futur projet du mois ?

2017-09-06 Diskussionsfäden Jérôme Amagat

ça serait bien de laisser une trace sur le wiki de comment il faut indiquer
les numéro.
J'ai ajouté 3 lignes sur la page en français :
https://wiki.openstreetmap.org/wiki/FR:Key:phone
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-au] Phone numbers

2017-09-06 Diskussionsfäden Simon Slater

On Wednesday, 6 September 2017 9:26:41 PM AEST Warin wrote:
> 1300, 1800 numbers are national only - no ISD access. Some of these have
> a 'local' number for ISD access.
> 
> I would assume these are not OSM compatible at this time?

From: https://wiki.openstreetmap.org/wiki/
Key:phone#Support_for_multiple_countries

Also some amenities have a local phone number which can only be used 
domestically not cannot be called internationally (notably for toll free phone 
numbers, or abbreviated phone numbers). For international calls, they publish 
another phone number. For example:
phone:FR=0 800 123 456 for standard toll free call only from France where the 
amenity is (note that there's NO "+" sign, it is NOT in international format), 
...

so they could be included.
-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

Re: [talk-au] Phone numbers

2017-09-06 Diskussionsfäden Andrew Davidson

TL;DR summary:

I'm happy to use E.123 international format for phone numbers or local 
format if they are not able to be called from overseas.

On 6/9/17 21:07, Phil (The Geek) Wyatt wrote:
> I think this is the correct format is it not?
>
>
>
> +61 3 6109 4621

It depends. Like most things it gets complicated and boring very 
quickly. So strap yourself in... If you look at the wiki entry: 
https://wiki.openstreetmap.org/wiki/Key:phone

phone numbers can be in E.164, E.123, DIN5008, RFC3966, or NANP "format".

Turns out that E.164 and NANP are not formats rather they are standards 
for numbering plans. E.164 is for allocating international numbers and 
NANP for allocating numbers in North America.

RFC3966 is a standard for creating URIs of telephone numbers so they end 
up in the form tel:+1-201-555-0123 (and I doubt anyone has used this in 
OSM).

E.123 and DIN5008 (part of) define formats for writing down phone 
numbers. They both have a international and national format but the wiki 
doesn't say which one to use.

There is certainly a mixed bag in Tasmania (only checked nodes)

+61 (0)3 6220 7100

So this one is not OK (it's a way that some Germans and Austrians write 
international numbers but is not in E.123 or DIN5008)

+61 03 6239 3095

Not OK (extra zero in front of 3)

+61 3 6109 4621

OK (matches E.123 and DIN5008 international formats)

(03) 6424 6762

OK (E.123 national format)

+61363313968

OK (E.123 international doesn't need spaces. Not sure about DIN5008)

64282013

Not OK. E.164 number not in either national or international format

132050

1800 770 224

OK. These are not E.164 numbers (ie: can't call from overseas) but are 
in E.123 and DIN5008 local format.

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

Re: [talk-au] Phone numbers

2017-09-06 Diskussionsfäden Simon Slater

On Thursday, 7 September 2017 7:57:26 AM AEST Warin wrote:
> I have not come up wit a way to search for '+'
> as that is a registered character.

Can you escape with a \ ? ie phone!="^\+61 8 " 

-- 
Regards
Simon Slater

Registered Linux User #463789 @ http://linuxcounter.net

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

[Talk-us] Task Manager Projects for Hurricane Harvey

2017-09-06 Diskussionsfäden Clifford Snow

There are six projects in the US Tasking Manager that need help. Consider
spending some time helping out.

1. http://tasks.openstreetmap.us/project/114 Addicks Reservoir North
2. http://tasks.openstreetmap.us/project/109 Crosby Tx home, buildings and
Infrastructure
3. http://tasks.openstreetmap.us/project/106 Manchester TX Homes and
Buildings
4. http://tasks.openstreetmap.us/project/105 Dickinson TX Buildings
5. http://tasks.openstreetmap.us/project/104 TIGER Clean up
6. http://tasks.openstreetmap.us/project/118 Corpus Christi Building Import




-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [OSM-talk-fr] Trajets de bus et ronds--points

2017-09-06 Diskussionsfäden Philippe Verdy

Je le pense aussi. Un giratoire sur le tracé d'un ligne est très aisément
détectable même et surtout si c'est un way fermé. Si le dessin du cercle
est "gênant" en zoom avant, il suffit de le considérer comme si ce n'était
pas une ligne mais un disque, assimilable à un point un peu plis gros en
son centre. De plus un bus peut encore être amené à faire plus que 1 tour
s'il est gêné pour sortir, cela ne remet pas en cause le trajet de la ligne.

C'est pareil pour les itinéraires routiers pour automobiles, camions ou
cyclistes, et même pour les piétons (s'il y a peur eux un chemin permettant
de passer par le centre d'un grand giratoire en passant par des passages
protégés, ce chemin sera marqué de même que les connexions aux rues
arrivant au rond point, et dans ce cas le piéton n'utilisera pas le tracé
circulaire du giratoire.

Dans tous les cas, on sait par où on y entre et par où en en sort. Briser
les giratoires ne sert pas à grand chose.

Je n'ai vus que quelques seul cas où ça peut être utile
- : si le giratoire passe emprunte des ponts au dessus d'autres voies
routières/ferrée/cyclistes ou un avec cours d'eau passant dessous et
évitant le giratoire. Le but étant alors de mettre des attributs différents
sur des sections du giratoire, notamment les barrières de sécurité (mais on
peut aussi représenter ces barrières sur des chemins parallèles.) mais
surtout les l'attributs "layer" et "bridge=yes" (dont on peut pourtant se
passer en mettant le layer sur les voies qui traversent en dessous.
- Si le giratoire passe sous d'autres ponts il n'est jamais nécessaire de
le couper (ce sont ces ponts qu'on va découper éventuellement)
- Si le giratoire passe dans des sections en tunnel (exemple en Andorre)
voire sous un bâtiment un "layer=-n" sera éventuellement nécessaire mais on
pourrait être gêné par le fait que ce layer passe alors aussi en dessous
des "landuse" environnants s'ils englobent la surface du giratoire

Certains veulent découper les giratoires à ponts pour uniquement le rendu
(qui détoure les voies des ponts par un filet noir : à mon avis ça se règle
par une correction dans le moteur de rendu, pour que ce filet ne vienne pas
en surimpression des voies connectées (comme si ce filet noir était des
barrières barrant les accès). On peut faire autrement en évitant
"bridge=yes" sur ces sections de giratoire, et mettant plutôt tunnel pour
les voies en dessous, et en ajoutant les barrières de sécurité de chaque
côté du pont. Dans ce cas plus besoin de "bridge" et "layer" sur le
giratoire".

Pour les assistants de navigation GPS, ils disent "entrez dans le
giratoire/rond-point, prenez la deuxième sortie" et ça suffit car il n'y a
pas d'autres chemins possibles et si celui qui ne connait pas bien le coin
rate la bonne sortie, il sait qu'il va devoir faire le tour complet pour la
retrouver et n'a pas besoin de toucher à son GPS!

Il reste les rares cas de giratoires avec des feux temporaires
(fonctionnant en giratoire la plupart du temps quand les feux sont éteints
mais en carrefour avec des voies plus prioritaires qui les traversent quand
les feux sont allumés). Cela ne concerne que de rares giratoires qui ont
une voie centrale pour les transports en commun munis de radiocommande ou
de télédétections des véhicules de transport en commun. On en trouve pas
mal à Nantes avec les carrefours utilisés aussi par les trams toujours
prioritaires (il y a des feux clignotants signalant l'approche d'une rame
et l'arrêt impératif de tous les autres usagers, mais là encore pas besoin
de découper le giratoire car le tram n'emprunte pas les mêmes voies).

Les derniers cas sont les ceux où un giratoire est temporairement
partiellement fermé  (par exemple un accident de la route ou des travaux):
la police ou des feux temporaires seront là pour rendre les autres sections
du giratoire bidirectionnelles ou unidirectionnelle alternée, et le faire
fonctionner comme un carrefour normal mais ce n'est jamais pour longtemps
(quelques heures pour un accident routier, quelques heures s'il y a des
travaux sur un giratoire important, parfois quelques semaines sinon en zone
résidentielle). Mais là on est rarement dans le cas où il faut modifier OSM
(le temps de faire la modif, que ce soit exporté et visible sur les cartes
et c'est déjà terminé, on aura fait la modif pour rien qu'il faut déjà
l'annuler...)

Le 7 septembre 2017 à 00:26, Francescu GAROBY  a écrit :

> Bonsoir,
> Je pense qu'il faudrait se mettre d'accord une bonne fois pour toutes,
> avec les ronds-points empruntés par les lignes de bus...
> À chaque fois, ça ne loupe pas : je trouve des ronds-points morcelés, ou
> refusionnés, puis remorcelés, ... Bref, à cause de tout ça, les tracés des
> lignes de bus sont incorrects, au niveau des ronds-points.
> Personnellement, je pense que ça n'a pas de sens de couper un rond-point,
> étant donné que l'entrée et la sortie sont connues. Charge au logiciel de
> dessin de tenir compte de ça...
>
> --
> Cordialement,
>

Re: [Talk-it] Info semaforo ed attraversamento pedonale

2017-09-06 Diskussionsfäden Alessandro Sarretta

Sulla pagina wiki crossing=zebra è segnalato come "UK shortcut" e mi 
pare che le due combinazioni siano usate entrambe in modo quasi 
equivalente: https://taginfo.openstreetmap.org/search?q=crossing%3Dzebra


Credo che ciò sia dovuto essenzialmente al fatto che e in ID viene 
inserito di default quando si seleziona "Pedestrain crosswalk"... 
Dovremmo suggerire che venga modificato il default di ID?


Ale


On 06/09/2017 22:13, Martin Koppenhoefer wrote:



sent from a phone

On 11. Aug 2017, at 16:54, Carlo > wrote:



Sul nodo lungo la strada ho inserito:
hightway=crossing
crossing=zebra



per crossing i valori tipici sono traffic_signals (semaforo) e 
uncontrolled (per esempio strisce/zebra):

https://wiki.openstreetmap.org/wiki/Key:crossing

crossing=zebra non è un valore documentato ma sembra un doppione di 
uncontrolled.


Scusate che scrivo dopo tanto tempo, sto un pochino in dietro grazie 
alle vacanze ;-)



Ciao, Martin


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


--
--

Alessandro Sarretta

skype/twitter: alesarrett
Web: ilsarrett.wordpress.com 

Research information:

 * Google scholar profile
   
 * ORCID 
 * Research Gate 
 * Impactstory 

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

Re: [Talk-br] Mapeamento hidrológico

2017-09-06 Diskussionsfäden Sérgio V .

Mais um motivo para mapear rios.

Imagino que o verão que chega vá ser extremamente chuvoso e de tempestades:
https://www.theguardian.com/world/2017/sep/06/twin-megastorms-irma-harvey-scientists-fear-new-normal

O mapeamento básico de rios ( waterways=* como eixos), pontes e correlatos,
ainda é o mais importante. É o mais simples, rápido, e mais útil como
informação. Sobretudo necessário em regiões já normalmente críticas.

A precisão do riverbank (como área), serve mais para tornar bonito o mapa, como
disse o Cássio em outro momento. Traz pouco ganho de informação. Além de ser
uma informação secundária, gasta 10x mais tempo para cobrir a mesma área do que
se for traçar eixos, que são muito mais importantes: para 2 nós com que se
possa cobrir uma determinada extensão de eixo de rio com suficiente precisão, o
mesmo trecho se for desenhado como área precisa de uns 20 nós.
Riverbank em escala meso-regional de estados (+/-acima de 1:1.000.000, ou zoom
9 no OSM) nem aparece, se torna irrelevante. Só faz diferença para rios mega
largos, com mais de 1km de largura. Mesmo assim não é fundamental para
estimativas de de contribuição hídrica, pois informações importantes como
largura, área da seção transversal, vazão, etc, podem bem ser aplicadas como
média por trechos de eixos.

A base mais importante de tudo é o simples traçado de eixos, que tranquilamente
pode ser feita remotamente (e é o que mais necessita). Os outros dados podem
ser agregados posteriormente. Mesmo eventuais possíveis importações de rios a
partir de bases de dados de órgãos públicos sempre necessitarão de muito ajuste
manual, pois nenhuma se compara em resolução aos traçados manuais que já
existem no OSM, por piores que sejam. Some-se a isto que importações são cada
vez mais complicadas e menos viáveis, pelos conflitos que dá, uma vez que já
existem muitas geometrias no OSM.

Na ordem de importância, o traçado manual de eixos é 10x mais importante do que
riverbank, e é algo simples de fazer (e prazeiroso, na minha opinião).

- - - - - - - - - - - - - - - -

Sérgio - http://www.openstreetmap.org/user/smaprs

De: Cassio Eskelsen
Enviado: quinta-feira, 31 de agosto de 2017 10:44
Para: OpenStreetMap no Brasil
Assunto: Re: [Talk-br] Mapeamento hidrológico

2. Sempre que for traçado um "waterway=river" deve-se traçar também uma área
com tag "waterway=riverbank"?

Obrigatório não e a maioria não tem mapeado mas desejável é já que, fora rios
retificados/canalizados, dificilmente a calha do rio será regular.

1 2 >

1 - 100 von 131 matches

Mail list logo