Re: [Talk-cz] Národní archiv leteckých snímků

[Michal Poupa]

Že to není zdarma když jsem za to už všichni zaplatili



11. 11. 2018 v 23:33, Jan Macura :

> Ahoj,
> 
>> On Sun, 11 Nov 2018 at 22:17, Michal Poupa  wrote:
>> a dá to někdo skutečně někdo  k tomu soudu?
> 
> to je vlastně zajímavá otázka. Co přesně bys chtěl u soudu žalovat v tomhle 
> případě?
> 
> H.
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[joost schouppe]

Hi Doudou,
I don't think anyone has a local domain to show the same as what
openstreetmap.org shows. In fact, I think most people believe
openstreetmap.org should look more like what the local websites look like,
rather than the other way around.
In the previous version of osm.be, there was in fact a link to "oh you just
want to see the default map" somewhere prominent on the page. I think it
was a conscious choice -not- to do that this time, but maybe we do have to
offer an alternative to that. For example: "I just want to see the map"
which leads to a page explaining there is only "the" database, and many
maps. With of course a link to the openstreetmap.org rendering of the map.

Op ma 12 nov. 2018 om 08:21 schreef OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com>:

> It’s fine as long as it’s consistent and predictable for the user.
>
> If a regional domain shows a map and another the chapter info, it can be
> confusing.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[Marc Gemis]

.nl .ie .de. fr .be .jp .us  --> no map, or map as background.
.ch .org --> map
.it -> just some text + link to wiki


On Mon, Nov 12, 2018 at 8:21 AM OSMDoudou
<19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:
>
> It’s fine as long as it’s consistent and predictable for the user.
>
> If a regional domain shows a map and another the chapter info, it can be 
> confusing.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

It’s fine as long as it’s consistent and predictable for the user.

If a regional domain shows a map and another the chapter info, it can be 
confusing.

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

Re: [Talk-at] WN Tooling

[emga]

> Am 11.11.2018 um 23:00 schrieb scubbx :
> 
> Hallo, Liste!
> 
> Angespornt durch Norberts Vorschlag, frage ich in die Runde, wie das mit
> dem Wochennotiz-Tooling aussieht? So viel ich weiß, benutzt die
> Wochennotiz eine eigene Web-App für das Zusammentragen interessanter
> Informationen.

Dazu würde ich mich ja an das Wochennotiz Team wenden, nur so als heißer 
Tipp;-) 
Ich denke die wissen am besten wie ihr System funktioniert...

> 
> Wie wird diese Erinnerungs-eMail generiert? Wenn automatisch, dann
> könnte man dort ja möglicherweise bereits Content einpflegen lassen? Mir
> würde so eine text-only Variante der WN schon gefallen.
> 
> Beste Grüße,
> Markus
> (ScubbX)
> 
> 
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at


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

[OSM-ja] 11/17 首都圏マッピングパーティ：六本木 檜町公園

[Takahisa TAGUCHI]

田口です。

不定期で開催している「首都圏マッピングパーティ」ですが、次回は
11/17(土) 港区六本木 檜町公園で開催します。

https://shutoken-mapping-party.connpass.com/event/105900/

ぜひお気軽にご参加ください！

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

[OSM-talk] Copying from a venue's website

[Andrew Harvey]

What's the acceptance on copying things like address, phone numbers,
contact email, opening hours from a venue's website?

Is that considered acceptable in OSM?

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

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Albert Pundt]

I didn't mean put network=* on the way; I meant the route relation. I
presume that's already how it differentiates Interstates, US routes, state
routes, etc. I don't know how else it could be done from the relation.

I certainly agree now with adding PATP as a ref on the ways for the reasons
you've described.

On Sun, Nov 11, 2018 at 7:54 PM Kevin Kenny  wrote:

> An aside (off list for reasons that will become obvious):
>
> It's unlikely that OSM-Carto will ever support the shaped shields and
> relation-driven support for route concurrencies that I'm doing. The support
> requires changes pretty much all up and down the rendering toolchain, and
> the development teams for several of the tools (most notably osm2pgsql)
> have pretty much conclusively rejected the changes that I proposed to
> implement. Without them, it's pretty much impossible to provide proper
> support for concurrency among route relations.
>
> Essentially, I'm foiled at every step because the dev teams don't agree
> with my approach. For instance, the osm2pgsql team rejects any inclusion of
> relations (rather than constructing ways from the relations) in the
> rendering database. They predict various performance and maintainability
> problems that warrant rejecting the changes out of hand, even if they
> provide functionality that cannot be done otherwise. (Actually, pnorman
> believes that it *can* be done - but has yet to offer a coherent path to
> *how* to do it in a way that he'd accept - and I've not been able to find
> one.)
>
> At one point, the openstreetmap.us team was accepting of Phil! Gold's
> rendering of shielded ways and concurrent routes, which has several issues
> that I've fixed (requiring a read/write connection to the PostGIS database,
> and access as well to the native file system underlying it). I have hopes
> that if I can refine this system enough, I might convince someone to accept
> this as a national map, even though the main opensteetmap.org server will
> never have it.
>
> I've got things to where I can run with an unpatched mapnik, and I'm
> looking at pulling a switch at some point from osm2pgsql to imposm3. Once
> I'm to that point, I can start looking at integrating a tile cache and
> incremental updates. But my development time at this point is limited. Life
> keeps getting in the way. For instance, at the moment, I'm recovering from
> retinal surgery, and have a lot to catch up on once I'm back to full
> function, so OSM will be on hold for a while longer.
>
>
>

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

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Kevin Kenny]

On Sun, Nov 11, 2018 at 6:34 PM Albert Pundt  wrote:

> On an unrelated note, thanks for linking that renderer. I used it to find
> and fix some holes in PA's US 119 relation where it defaulted to using a
> plain text rectangle since only the ref tag was present.
>

It may be a while before your changes show up.  I reroll the tiles only
sporadically.

The shaped shields are used only for route=road relations. Putting network
and ref on the way won't get them. (The plain text rectangles are used as a
fallback for routes that have ref=* but are not members of route relations,
or for networks that the code doesn't recognize.)

Even though there are no reassurance markers, I think that map users would
expect to see the Pike labeled as such, with the shield in place.  The
markers at entry and exit are prominent, and it's pretty obvious when
you're entering and leaving since your go through a toll station.
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-at] WN Tooling

[ScubbX]

Es scheint im Endeffekt auf ein WordPress-System hinauszulaufen:
https://wiki.openstreetmap.org/wiki/Wochennotiz


Am 2018-11-11 um 23:20 schrieb Andreas:
> Am 11.11.18 um 23:00 schrieb scubbx:
>> Hallo, Liste!
>>
>> Angespornt durch Norberts Vorschlag, frage ich in die Runde, wie das mit
>> dem Wochennotiz-Tooling aussieht? So viel ich weiß, benutzt die
>> Wochennotiz eine eigene Web-App für das Zusammentragen interessanter
>> Informationen.
>>
>> Wie wird diese Erinnerungs-eMail generiert? Wenn automatisch, dann
>> könnte man dort ja möglicherweise bereits Content einpflegen lassen? Mir
>> würde so eine text-only Variante der WN schon gefallen.
> Ich weiß nicht genau, wie das Mail zu generiert wird, aber ich habe von
> einem manuell ausgeführten Skript gehört.
>
> Ich weiß mit meinem Mail hat die ganze Diskussion hier angefangen, dabei
> wollte ich nur meine Aussagen zu vorherigen Mails korrigieren.
>
> lg Andreas
> (geologist)
>
>
>
> ___
> Talk-at mailing list
> Talk-at@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-at

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

Re: [OSM-talk-fr] Borne de puisage

[François Lacombe]

Bonsoir à vous

Je regrette de ne pas avoir plus de temps à consacrer à cet échange (le
temps se fait rare)

Même si cela n'a pas à voir avec la question des bornes de puisage ou
pompier, il faut noter cette proposition en cours d'écriture
https://wiki.openstreetmap.org/wiki/Proposed_features/Pipeline_valves_proposal

Elle va toucher tout types de robinets, dont ceux sur les bornes à incendie
ou de puisage si ils existent.
Tout n'est pas encore terminé

Bonne soirée

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux 


Le jeu. 1 nov. 2018 à 17:41, Vincent Bergeot  a écrit :

> Le 31/10/2018 à 21:18, Vincent de Château-Thierry a écrit :
>
> D'une manière plus générale je trouve hasardeux de démarrer une page de
> wiki en anglais pour amenity=hydrant sans passer par une discussion sur la
> ML tagging.
>
>
> quelques propositions :
> https://lists.openstreetmap.org/pipermail/tagging/2018-November/040525.html
>
> man_made=standpipe
> colour=green
> water_source=main
>
> avec une "définition" : https://en.wikipedia.org/wiki/Standpipe_(street)
> à plus
>
> --
> Vincent Bergeot
>
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Albert Pundt]

This would not involve adding ref=PATP to the PA Turnpike route relation.
However, thinking about it now, I think it should be added to the ways for
the sake of the Carto renderer. (I know, I know, tagging for the renderer,
but isn't Carto's use of ref tags for route markers the only reason the
tags remain on ways?) We'd need to be careful where we use PATP in
destination:ref tags, since the Turnpike shield is very rarely used once on
the Turnpike. For example, the ramps from the mainline Turnpike (I-276) to
the northbound Northeast Extension (I-476) should remain tagged as
destination:ref=I
476 and not destination:ref=I 476;PATP since that shield does not appear on
the signs. The only such use of a Turnpike shield that I know of is the
aforementioned example eastbound at Willow Grove.

"PA Turnpike XX" routes are an established type in Pennsylvania. Three
examples currently exist: 66 (New Stanton to Delmont), 43 (WV to Fairchance
and Uniontown to Jefferson Hills), and 576 (entire length, US 22 to Pgh
Int'l Airport). A relation tagged with network=US:PA:Turnpike and a
numerical ref value should trigger the use of the PA Turnpike XX
shield. This isn't simply a fancy label for a standard state route like the
yellow TOLL banners on I-376. They are treated as separate routes by
PennDOT and the PTC. Exiting US 22 near Delmont, signs say "PA 66 South, TO
PA Turnpike 66." Occasionally, an erroneous PA Turnpike XX shield pops up
for I-76, 276, or 476, but that's inaccurate. Also, the oldest part of PA
43 and the tolled part of I-376 (once PA 60) were in the past signed with a
white keystone simply saying "TOLL" at the top, but there are no remaining
routes signed this way.

On an unrelated note, thanks for linking that renderer. I used it to find
and fix some holes in PA's US 119 relation where it defaulted to using a
plain text rectangle since only the ref tag was present.

I'll start adding PATP to destination:ref tags now, but will only retag the
mainline ways if no one else has any objections.

On Sun, Nov 11, 2018 at 3:17 PM Kevin Kenny  wrote:

> The Turnpike already has a series of relations, which renderers that are
> aware of concurrent road routes are able to render.
>
> It's network=US:PA:Turnpike, and the relation has no ref=* since the road
> markings are unique.
>
> https://www.openstreetmap.org/relation/3075582
>
> It appears to render correctly on
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.1101=-75.3106=11
> which shows the Pike overlaid on Interstates 76, 276 and 476.
>
> I'd have no objection to putting ref=PATP on either the relation or the
> ways, but please let me know if you plan to change the network since my
> code needs to be aware of that.
>
> You might also want to consider what to do about the unusually signed
> PA-Turnpike-66 from New Stanton to Belmont.
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.2748=-79.6186=11
> shows what I'm doing with it at the moment. I'd need to check to see
> whether I put in an override or whether the network tag is different. PA 43
> from Jefferson Hills to Uniontowm
> https://kbk.is-a-geek.net/catskills/test4.html?la=40.1043=-79.9194=11
> is another one that has Turnpike-overlaid-on-state-highway.
>
>
> On Sat, Nov 10, 2018 at 7:52 PM Albert Pundt  wrote:
>
>> Does anyone object to the use of "PATP" as the ref equivalent for the PA
>> Turnpike? Particularly for destination:ref tags, as the Turnpike
>> keystone shield is used on most guide signs for ramps onto the Turnpike.
>> However, since it's not used as a reassurance marker*, I don't think it
>> should be added as a ref tag on the ways (i.e. ref=I 76;PATP) as is done
>> on the New Jersey Turnpike, which does have its shield on pull-through
>> signs and similar.
>>
>> This sort of abbreviation is already standard practice in New Jersey (for
>> the NJTP, GSP, and ACE) and New York (all the parkways), which have
>> standard shields used on guide signs.
>>
>> This would apply to the mainline (I-76 and I-276) and the Northeast
>> Extension (I-476), but not the newer four extensions (PA Tpke 43, 66, 576,
>> and I-376).
>>
>> *There is now one set of signs eastbound on the mainline PA Turnpike
>> approaching the Willow Grove (PA 611) interchange that has the PA Turnpike
>> shield on the pull-through side. However, this was put up within the past
>> two months and is not nearly common enough to base system-wide practice on.
>>
>> —Albert Pundt
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>

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

Re: [Talk-cz] Národní archiv leteckých snímků

[Jan Macura]

Ahoj,

On Sun, 11 Nov 2018 at 22:17, Michal Poupa  wrote:

> a dá to někdo skutečně někdo  k tomu soudu?
>

to je vlastně zajímavá otázka. Co přesně bys chtěl u soudu žalovat v tomhle
případě?

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Mapy ve vlacich/autobusech

[Jan Macura]

Ahoj,

On Sun, 11 Nov 2018 at 13:11, Pavel Machek  wrote:

> Poznavam openstreetmap :-(. Screenshot v priloze.
>

je to dost podobné Wikimedia Maps i OSM Bright, ale jsou tam rozdíly.
Nejspíš vlastní styl přes Mapbox Studio...?
To jen tak pro úplnost.

H.
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-at] WN Tooling

[Andreas]

Am 11.11.18 um 23:00 schrieb scubbx:
> Hallo, Liste!
> 
> Angespornt durch Norberts Vorschlag, frage ich in die Runde, wie das mit
> dem Wochennotiz-Tooling aussieht? So viel ich weiß, benutzt die
> Wochennotiz eine eigene Web-App für das Zusammentragen interessanter
> Informationen.
> 
> Wie wird diese Erinnerungs-eMail generiert? Wenn automatisch, dann
> könnte man dort ja möglicherweise bereits Content einpflegen lassen? Mir
> würde so eine text-only Variante der WN schon gefallen.

Ich weiß nicht genau, wie das Mail zu generiert wird, aber ich habe von
einem manuell ausgeführten Skript gehört.

Ich weiß mit meinem Mail hat die ganze Diskussion hier angefangen, dabei
wollte ich nur meine Aussagen zu vorherigen Mails korrigieren.

lg Andreas
(geologist)



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

[Talk-at] WN Tooling

[scubbx]

Hallo, Liste!

Angespornt durch Norberts Vorschlag, frage ich in die Runde, wie das mit
dem Wochennotiz-Tooling aussieht? So viel ich weiß, benutzt die
Wochennotiz eine eigene Web-App für das Zusammentragen interessanter
Informationen.

Wie wird diese Erinnerungs-eMail generiert? Wenn automatisch, dann
könnte man dort ja möglicherweise bereits Content einpflegen lassen? Mir
würde so eine text-only Variante der WN schon gefallen.

Beste Grüße,
Markus
(ScubbX)


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

Re: [OSM-talk-be] OSM.be versus OpenStreetMap.be

[OSMDoudou]

Second thoughts...

When you visit a .com website, which also has an affiliated regional website, 
like .be, you expect to find the same stuff but in the local language and with 
local products.

By the logic above, openstreetmap.be should show the map centered on Belgium.

In the case of openstreetmap.org and openstreetmap.be, they would be totally 
different.

My 2ç.


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

Re: [Talk-at] OSM Wochennotiz Aktualität & Richtigstellung

[Norbert Wenzel]

On 11.11.18 18:19, Peter Barth wrote:
> grubernd schrieb:
>> allerdings schliesse ich mich gedanklich trotzdem denen an, die sagen 
>> eine wöchentliche Zwangsbeglückungserinnerung für ein wöchentliches 
>> Ereignis ist übertrieben.
> 
> die Idee war da eher, dass die WN rauskommt wenn sie fertig ist und
> nicht an einem fixen Tag. Daher macht die Erinnerung auch irgendwo Sinn.
> 
> Ich benutze auch lieber RSS (scheint aber irgendwie auszusterben), aber
> dafür hatten wir ja eine kleine nichtrepräsentative Umfrage auf dieser
> ML gemacht und da war die Mehrheit für die Erinnerungsmail. Ich glaube
> keiner im WN-Team verspürt den Zwang die Mail zu schicken, aber nur
> wegen einiger lauter Stimmen sollte sie nicht unterlassen werden solang
> die Mehrheit die Erinnerung wünscht.

Ich bin auch kein Fan der (bis auf den aktualisierten Link) recht leeren
Mail und ja, es gab vor der Einführung der Erinnerungsmail eine
Diskussion (Umfrage würde ich das nicht nennen). Seither bekommt auch
talk-at diese Mail, vorher haben sich die WN Autoren auch an den Wunsch
gehalten die Erinnerung bitte nicht zu schicken. Afair kam es zu der
Diskussion überhaupt nur weil es immer noch Leute gab, die die WN nicht
kannten. Wenn sie die WN durch diese Erinnerung kennenlernen, dann leg
ich persönlich dafür gern einen weiteren Mailfilter in meiner Inbox an.

Wenn wir aber was gegen diese leere Erinnerungsmail unternehmen wollen,
dann sollten wir imo unsere Energie darauf verwenden *gemeinsam* mit den
WN Autoren am Tooling für informativere Erinnerungen zu arbeiten und
nicht tagelang fruchtlose und tlw. ins Beleidigende abgleitende
Diskussionen führen um die eine, kleine und ach so störende Mail pro
Woche zu verhindern. Denn persönlich muss ich sagen, hat dieser Thread
die Rate an unerwünschten Mails in meiner Inbox ganz deutlich gesteigert.

@Peter: Sorry, ist jetzt als Antwort auf dich verfasst, aber du bist
ausdrücklich *nicht* damit gemeint.

lg,
Norbert

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

Re: [Talk-cz] Národní archiv leteckých snímků

[Michal Poupa]

a dá to někdo skutečně někdo  k tomu soudu?
ne 11. 11. 2018 v 13:05 odesílatel Pavel Machek  napsal:
>
> On Tue 2018-11-06 13:01:15, Jan Macura wrote:
> > On Tuesday, 6 November 2018, Marián Kyral  wrote:
> > >> b) protože "© ČÚZK"
> > > Kolik že to je? 80 let po smrti autora? A kdo je vlastně autor? :-D
> >
> > Autorské právo platí 70 let od smrti autora. Nevsadil bych ale na to, že
> > stejná doba se aplikuje i na "zvláštní právo pořizovatele databáze",
> > nehledě na to, kdy toto právo nabývá účinnosti...
> > (Aneb ČÚZK si vždycky výmluvu najde).
>
> Nastesti o tomhle nerozhoduje CUZK ale soud, a CUZK se musi ridit i
> jinymi zakony (106, svobodny pristup k informacim), pracuje se na tom,
> na OpenAltu o tom byla prednaska.
>
> Nejjednodussi by bylo copyright CUZK proste ignorovat, statni veci na
> nej nemaj narok a CUZK k soudu nepujde, protoze by tam prohral :-).
> Pavel
> --
> (english) http://www.livejournal.com/~pavelmachek
> (cesky, pictures) 
> http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

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

Re: [Talk-es] Voluntarios para mapaton en Pamplona (Universidad Pública de Navarra)

[Miguel Sevilla-Callejo]

Genial!
Héctor está coordinándose con la profesora de la Universidad Pública de
Navarra que organiza la actividad.
Quien esté interesado que se comunique con él.
Un saludo

--
*Miguel Sevilla-Callejo*
Doctor en Geografía
--
Si estas por Zaragoza y alrededores no olvides que te esperamos en el grupo
de Mapeado Colaborativo:
Twitter: @mapcolabora | Web: http://mapcolabora.org | Actividades:
http://meetup.com/mapcolabora

On Sun, 11 Nov 2018 at 18:02, Oscar Zorrilla Alonso <
oscar_zorri...@hotmail.com> wrote:

> Hola;
> Yo también podría ir.
> Un saludo
> Óscar (cronoser)
>
>
> *De:* Héctor Ochoa 
> *Enviado:* viernes, 2 de noviembre de 2018 12:10
> *Para:* Discusión en Español de OpenStreetMap
> *Asunto:* Re: [Talk-es] Voluntarios para mapaton en Pamplona (Universidad
> Pública de Navarra)
>
> Me apunto, esa tarde la tengo libre.
>
> El mar., 30 oct. 2018 a las 15:33, Miguel Sevilla-Callejo (<
> msevill...@gmail.com>) escribió:
>
> Hola,
>
> Una profesora de la Universidad Pública de Navarra se ha puesto con
> contacto conmigo para saber si habría algún voluntario dispuesto a
> colaborar en un mapaton que van a realizar en la universidad, en Pamplona,
> junto a Médicos sin fronteras, la tarde del día 16 de noviembre.
>
> Si no recuerdo mal no hay mucha gente "geoinquieta" o grupos de editores
> de OSM por Pamplona pero si alguien está interesado en ayudar que lo diga.
> A priori es para poder disponer de contribuidores con experiencia para
> poder realizar la verificación de las ediciones que se lleven a cabo ese
> día.
>
> Saludos
>
> --
> *Miguel Sevilla-Callejo*
> Doctor en Geografía
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
>
>
> --
>
>
>
>
>
> Obtener Outlook para Android 
>
> ___
> Talk-es mailing list
> Talk-es@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-es
>
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es

Re: [Talk-cz] Mapy ve vlacich/autobusech

[Pavel Machek]

On Sun 2018-11-11 20:33:43, Miroslav Suchý wrote:
> Dne 11. 11. 18 v 13:11 Pavel Machek napsal(a):
> > Poznavam openstreetmap :-(. Screenshot v priloze.
> 
> To fakt vypada hoodne podobne. Akorat mi v tom screenshotu chybi ta
> administrativni hranice mezi Mukarovem a Zernuvkou.
> Ale jinak i ty pocty linii a jejich zalomeni na pesinach sedi.
> 
> Zda se, ze dodavetel je
>   http://www.rehspot.de/
> Nechcete jim nekdo kdo umite nemecky napsat?
> Nebo mam napsat na Cesky FlixBus?

Tohle byl vlak "Alex". Ve Flixbusu se neda zazoomovat, takze neni moc
poznat jakou mapu pozivaj.

Pavel

-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-cz] Mapy ve vlacich/autobusech

[Miroslav Suchý]

Dne 11. 11. 18 v 13:11 Pavel Machek napsal(a):
> Poznavam openstreetmap :-(. Screenshot v priloze.

To fakt vypada hoodne podobne. Akorat mi v tom screenshotu chybi ta
administrativni hranice mezi Mukarovem a Zernuvkou.
Ale jinak i ty pocty linii a jejich zalomeni na pesinach sedi.

Zda se, ze dodavetel je
  http://www.rehspot.de/
Nechcete jim nekdo kdo umite nemecky napsat?
Nebo mam napsat na Cesky FlixBus?

Mirek



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

Re: [Talk-it] [talk-it] Nuova tabella per l'Italia per pagina wiki "OSM tags for routing/Access-Restrictions"

[Aury88]

voschix wrote
> Vorrei aggiungere una tabella per l'Italia alla pagina
> OSM tags for routing/Access-Restrictions
> https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Access-Restrictions;
> Una bozza della nuova tabella trovate nel mio documento di lavoro
> Copia di lavoro di IT:Bicycle
> https://wiki.openstreetmap.org/wiki/Copia_di_lavoro_di_IT:Bicycle;
> 
> Controllate, criticate, migliorate!
> 
> Grazie
> 
> Volker
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it

Ciao Volker, 

Come sempre gran bel lavoro.
avrei un dubbio sui valori nella colonna Ref delle tabelle nella sezione
"Esempi di percorsi ciclabili". A cosa corrispondono? è una qualche
classificazione ufficiale delle tipologie di piste ciclabili/pedonali in
italia?

inoltre perchè per i casi S3 e S4 proponi anche l'alternativa dell'uso di
più way  anche se la pista non è separata a un ostacolo fisico? sono gli
unici casi separati da una semplice linea che però hanno una mappatura
alternativa che preveda way multiple e volevo capire perchè solo per queste
è accettata questa metodologia.

Grazie per l'interessantissimo ed utilissimo lavoro!




-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

Re: [OSM-talk-fr] Comment tagguer une demi-barrière ?

[Gwenaël Jouvin]

Bonsoir,

L’état actuel des tags ne me paraît pas du tout inapproprié, la voie est bien 
libre pour les piétons et les cyclises, étant donné que le chemin concerné est 
une voie verte (ici interdite aux cavaliers faute de panonceau M4y).

J’irai même jusqu’à dire qu’y mettre barrier=cycle_barrier, dans ce contexte, 
n’est pas si incohérent que ça.
https://wiki.openstreetmap.org/wiki/Tag%3Abarrier%3Dcycle_barrier

La largeur avec width ou maxwidth est une information très utile pour ceux qui 
souhaitent utiliser la voie verte avec des vélos plus larges que ce qu’on 
considère comme étant la « normale » : vélos couchés, tricycles, cargos.


Gwenaël


Le 11/11/2018 à 19:04, pepilepi...@ovh.fr a écrit :
> Bonsoir,
> 
> Un p'tit dessin  vaut mieux qu'un grand baratin. 
> Actuellement c'est taggué "barrier=swing_gate". Mais elle laisse passer tout 
> ce qui fait moins d'un mètre de large, piéton, vélo, poussette, etc.
> 
> Quel serait le bon tag ? Pour l'instant j'ai juste ajouté foot=yes et 
> bicycle=yes.
> 
> Merci, bonne soirée
> 
> Jean-Pierre
> 
> 
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
> 

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

[OSM-talk-fr] Comment tagguer une demi-barrière ?

[pepilepi...@ovh.fr]

  
  
Bonsoir,
Un p'tit dessin vaut mieux qu'un
grand baratin. Actuellement c'est taggué "barrier=swing_gate".
Mais elle laisse passer tout ce qui fait moins d'un mètre de
large, piéton, vélo, poussette, etc.
Quel serait le bon tag ? Pour l'instant j'ai
juste ajouté foot=yes et bicycle=yes.
  
Merci, bonne soirée
Jean-Pierre

  


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

[Talk-ca] hebdoOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 433 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10913/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
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

[OSM-talk-fr] hebdoOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 433 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10913/

Bonne lecture !

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

[Talk-ht] hebdoOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Bonjour,

Le résumé hebdomadaire n° 433 de l'actualité OpenStreetMap vient de paraître 
*en français*. Un condensé à retrouver sur :

http://www.weeklyosm.eu/fr/archives/10913/

Bonne lecture !

hebdoOSM ? 
Qui : https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
Où : 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ht mailing list
Talk-ht@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ht
Notez! Vous pouvez utiliser Google Translate (http://translate.google.com) pour 
traduire les messages.

[Talk-pt] semanárioOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 433, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/10913/

Aproveite!

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

[Talk-br] semanárioOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Bom dia,

O semanárioOSM Nº 433, o resumo de tudo o que acontece no mundo OpenStreetMap, 
está publicado *em português*:

http://www.weeklyosm.eu/pb/archives/10913/

Aproveite!

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

Re: [Talk-at] OSM Wochennotiz Aktualität & Richtigstellung

[Peter Barth]

Hi,

grubernd schrieb:
> allerdings schliesse ich mich gedanklich trotzdem denen an, die sagen 
> eine wöchentliche Zwangsbeglückungserinnerung für ein wöchentliches 
> Ereignis ist übertrieben. sowas können nur Leute mit der 
> Aufmerksamkeitsspanne eines facebook-teenagers einfallen. zumal diese 
> Mail ja nicht einmal den Inhalt wiedergibt und somit auch für Suchen 
> komplett sinnlos ist. einmal im Quartal eine zusammenfassende Erinnerung 
> sollte für alte und neue Mitglieder der Mailingliste ausreichen.

die Idee war da eher, dass die WN rauskommt wenn sie fertig ist und
nicht an einem fixen Tag. Daher macht die Erinnerung auch irgendwo Sinn.

Ich benutze auch lieber RSS (scheint aber irgendwie auszusterben), aber
dafür hatten wir ja eine kleine nichtrepräsentative Umfrage auf dieser
ML gemacht und da war die Mehrheit für die Erinnerungsmail. Ich glaube
keiner im WN-Team verspürt den Zwang die Mail zu schicken, aber nur
wegen einiger lauter Stimmen sollte sie nicht unterlassen werden solang
die Mehrheit die Erinnerung wünscht. (Nur zur Erklärung, nicht um dir zu
widersprechen :-))

Gruß.
Peda


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

Re: [Talk-es] Voluntarios para mapaton en Pamplona (Universidad Pública de Navarra)

[Oscar Zorrilla Alonso]

Hola;
Yo también podría ir.
Un saludo
Óscar (cronoser)


De: Héctor Ochoa 
Enviado: viernes, 2 de noviembre de 2018 12:10
Para: Discusión en Español de OpenStreetMap
Asunto: Re: [Talk-es] Voluntarios para mapaton en Pamplona (Universidad Pública 
de Navarra)

Me apunto, esa tarde la tengo libre.

El mar., 30 oct. 2018 a las 15:33, Miguel Sevilla-Callejo (< 
msevill...@gmail.com>) escribió:
Hola,

Una profesora de la Universidad Pública de Navarra se ha puesto con contacto 
conmigo para saber si habría algún voluntario dispuesto a colaborar en un 
mapaton que van a realizar en la universidad, en Pamplona, junto a Médicos sin 
fronteras, la tarde del día 16 de noviembre.

Si no recuerdo mal no hay mucha gente "geoinquieta" o grupos de editores de OSM 
por Pamplona pero si alguien está interesado en ayudar que lo diga. A priori es 
para poder disponer de contribuidores con experiencia para poder realizar la 
verificación de las ediciones que se lleven a cabo ese día.

Saludos

--
Miguel Sevilla-Callejo
Doctor en Geografía
___
Talk-es mailing list
Talk-es@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-es


--





Obtener Outlook para Android

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

Re: [Talk-at] OSM Wochennotiz Aktualität & Richtigstellung

[grubernd]

On 09.11.18 13:04, Frederik Ramm wrote:

die wöchentliche Erinnerung an die Erscheinung der Wochennotiz ist kein
Spam.

Die Wochennotiz darf hier weiter an ihr Erscheinen erinnern.



mh. keine Ahnung was der ganze Lärm soll, in meiner talk-at inbox gibt's 
keinen WN-Spam. ein ganz normales RSS-Abo hilft mir hier den Überblick 
zu behalten, weil ich keine Lust habe die Wochennotiz dann zu lesen, 
wenn sie gerade veröffentlicht wird. ich will die Arbeit, die sich die 
Macher machen, auch mit dem entsprechenden Zeitfenster honorieren.


ob ich die WN-Mails jetzt selber gefiltert habe oder mein Spam-Filter so 
clever ist, weiss ich nicht. ist auch egal, es funktioniert.


deshalb hier so einen Krawall zu machen, und damit meine ich NICHT den 
Frederik, halte ich allerdings für komplett kindisch.


filtert euren Blödsinn, schickt die Rechnung an euer Seelenheil und 
lasst es gut sein. wer auf der OSM als Mapper aktiv ist sollte die 
technische und zeitliche Reserve haben um einmal einen Mailfilter zu 
erstellen. wirklich.


allerdings schliesse ich mich gedanklich trotzdem denen an, die sagen 
eine wöchentliche Zwangsbeglückungserinnerung für ein wöchentliches 
Ereignis ist übertrieben. sowas können nur Leute mit der 
Aufmerksamkeitsspanne eines facebook-teenagers einfallen. zumal diese 
Mail ja nicht einmal den Inhalt wiedergibt und somit auch für Suchen 
komplett sinnlos ist. einmal im Quartal eine zusammenfassende Erinnerung 
sollte für alte und neue Mitglieder der Mailingliste ausreichen.


meine 2 cent in die Kaffeekasse.

grüsse,
grubernd

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

Re: [OSM-talk-fr] [Tagging-fr] access=yes -> accès public

[Vincent Bergeot]

Le 05/11/2018 à 18:31, marc marc a écrit :

je répondu sur talk-fr vu que tagging-fr est mort né

Le 05. 11. 18 à 17:28, Vincent Bergeot a écrit :

Dans le wiki osm, sommes nous d'accord que public devrait être "yes" ici
: https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dtoilets#Acc.C3.A8s

oui c'est une erreur de traduction présente depuis la création
de la version fr


j'ai modifié la traduction, ajouté que private n'avait vraisemblablement 
pas sa place et éventuellement permissive (mise à disposition pour le 
public par un propriétaire !!!).


https://wiki.openstreetmap.org/wiki/FR:Tag:amenity%3Dtoilets#Acc.C3.A8s

Reste à corriger maintenant !

à plus


--
Vincent Bergeot


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

Re: [OSM-talk-fr] Problème authentification Maproulette ?

[Paul Desgranges]

J'ai eu le même souci aujourd'hui

Le dim. 11 nov. 2018 à 17:13, pepilepi...@ovh.fr  a
écrit :

> Bonjour,
>
> Après une interruption de quelques heures je suis retourné sur
> maproulette.org et j'ai maintenant un message d'erreur :
>
> "Error
>
> Communication with the service provider failed:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target"
>
> ¿ Qué pasa ? Quelqu'un a une idée ? À qui faut-il s'adresser pour ça ?
>
> Merci, bonne soirée
>
> Jean-Pierre
> ___
> Talk-fr mailing list
> Talk-fr@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-fr
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk-fr] Problème authentification Maproulette ?

[pepilepi...@ovh.fr]

  
  
Bonjour,
Après une interruption de quelques heures je
suis retourné sur maproulette.org et j'ai maintenant un message
d'erreur : 
  
"Error

  Communication with the service provider failed:
  sun.security.validator.ValidatorException: PKIX path building
  failed:
  sun.security.provider.certpath.SunCertPathBuilderException:
  unable to find valid certification path to requested target"
  ¿ Qué pasa ? Quelqu'un a une idée ? À qui
  faut-il s'adresser pour ça ?

  Merci, bonne soirée
  Jean-Pierre


  


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

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

[Nick Whitelegg]

Thanks for all the replies.


After thinking about this, I realised that I don't really want to update _all_ 
the data that often. The only thing I need to update on a weekly basis is the 
footpaths (I'm not so bothered if say the roads, or the pubs are a year out of 
date - as long as newly mapped footpaths appear quickly). So what I'm now doing 
is just doing an osmosis extract of paths weekly, deleting all data in the DB 
which I class as a 'path' and repopulating in amend mode.


Thanks,

Nick



From: Paul Norman 
Sent: 08 November 2018 20:10:14
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

On 2018-11-08 6:34 AM, Nick Whitelegg wrote:

At the moment I download full planet extracts about every 6 months. However, 
due to the limitations of my server, I filter out (with osmosis) a lot of stuff 
I don't need so that I am basically left with roads, footpaths, natural 
features, water features and selected POIs.


I'd like to move towards a system which applies diffs from geofabrik instead, 
and applies them regularly (daily or weekly) with osm2pgsql.


My question is this; given that not everything in the diff will be in my 
database (as I filter out what I don't need during the import process), will 
osm2pgsql apply the diff successfully or will it complain that not all features 
in the diff are in my database?

I can think of four ways to do this, all which have a different balance of 
correctness, performance, and ease of use.

There are two "right" ways to do this. The first one is to re-import every 
week. Because imports without slim tables (either --slim --drop or no --slim) 
are faster, this is a good option and needs less space than a database able to 
consume diffs.

The second right way involves keeping two files, one with the current full 
data, and one with the filtered data. Call these "planet.pbf" and 
"planet-filtered.pbf". Then when updating create "planet-new.pbf", filter it to 
get "planet-filtered-new.pbf", create a diff for the differences between 
"planet-filtered-new.pbf" and "planet-filtered.pbf", and apply that diff to the 
database. Then replace the old files with the new ones. This will keep the 
database correct.

A "wrong" way to do it is to import the filtered data, apply updates directly, 
and periodically delete data from the DB. The problem with this is that if 
someone adds one of the selected POI tags to a building that you have filtered 
out, osm2pgsql won't have the node data to create a geometry. This might be 
acceptable, depending on use case.

A less wrong way would be to modify your filtering so no nodes are filtered 
out. There are still potential errors with relations, but these are less 
common. If you're doing the planet or a large extract and using flat nodes 
there's no storage penalty for having all the nodes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

[Nick Whitelegg]

... append mode!





From: Nick Whitelegg
Sent: 11 November 2018 15:53:18
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data



Thanks for all the replies.


After thinking about this, I realised that I don't really want to update _all_ 
the data that often. The only thing I need to update on a weekly basis is the 
footpaths (I'm not so bothered if say the roads, or the pubs are a year out of 
date - as long as newly mapped footpaths appear quickly). So what I'm now doing 
is just doing an osmosis extract of paths weekly, deleting all data in the DB 
which I class as a 'path' and repopulating in amend mode.


Thanks,

Nick



From: Paul Norman 
Sent: 08 November 2018 20:10:14
To: talk@openstreetmap.org
Subject: Re: [OSM-talk] osm2pgsql diff application with filtered OSM data

On 2018-11-08 6:34 AM, Nick Whitelegg wrote:

At the moment I download full planet extracts about every 6 months. However, 
due to the limitations of my server, I filter out (with osmosis) a lot of stuff 
I don't need so that I am basically left with roads, footpaths, natural 
features, water features and selected POIs.


I'd like to move towards a system which applies diffs from geofabrik instead, 
and applies them regularly (daily or weekly) with osm2pgsql.


My question is this; given that not everything in the diff will be in my 
database (as I filter out what I don't need during the import process), will 
osm2pgsql apply the diff successfully or will it complain that not all features 
in the diff are in my database?

I can think of four ways to do this, all which have a different balance of 
correctness, performance, and ease of use.

There are two "right" ways to do this. The first one is to re-import every 
week. Because imports without slim tables (either --slim --drop or no --slim) 
are faster, this is a good option and needs less space than a database able to 
consume diffs.

The second right way involves keeping two files, one with the current full 
data, and one with the filtered data. Call these "planet.pbf" and 
"planet-filtered.pbf". Then when updating create "planet-new.pbf", filter it to 
get "planet-filtered-new.pbf", create a diff for the differences between 
"planet-filtered-new.pbf" and "planet-filtered.pbf", and apply that diff to the 
database. Then replace the old files with the new ones. This will keep the 
database correct.

A "wrong" way to do it is to import the filtered data, apply updates directly, 
and periodically delete data from the DB. The problem with this is that if 
someone adds one of the selected POI tags to a building that you have filtered 
out, osm2pgsql won't have the node data to create a geometry. This might be 
acceptable, depending on use case.

A less wrong way would be to modify your filtering so no nodes are filtered 
out. There are still potential errors with relations, but these are less 
common. If you're doing the planet or a large extract and using flat nodes 
there's no storage penalty for having all the nodes.
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-au] PSMA Administrative Boundaries

[Joel H.]

Just downloaded to take a look, Most seem right.

In order to QA something like this, taking random samples won't help
since any number of errors would be small.

Does the script currently check for a byte-to-byte match of the name=*
text? I think that should be the determining faction of adding a node to
the relation. The remaining un-merged entries can be determined manually.


On 10/11/18 10:44 am, Andrew Davidson wrote:
> If you want to start working on something I have had a go at matching
> place nodes:
>
> http://overpass-turbo.eu/s/Dy3
>
> with the corresponding admin_level 10 boundaries:
>
> https://github.com/FrakGart/TestAdmin10Labels
>
> These have been matched by finding the best matching place node by
> name within a bbox 150% the size of the admin boundary. In the cases
> where there are more than one perfect match the first one the program
> encountered is used.
>
> Needs reviewing to see if the most appropriate node has been selected.
> Particularly where a town/city node has been selected: do we need to
> add a suburb node? (or do we use the same node for city and suburb eg:
> Brisbane)
>
> This is v1.0, I was planning to see if I could flag if the selected
> node is inside/outside the boundaries (eg: Mount Isa) and also look
> for duplicate place nodes (ie: same name appearing on different values
> of place).
>
>
> On 7/11/18 2:57 pm, Joel H. wrote:
>> How are we with our import plan on the wiki, Do we have any blockers
>> stopping the PSMA import?
>>
>> I think we should start setting dates state-by-state for import.
>>
>>
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>>
>
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au

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

Re: [Talk-us] Thoughts on a standard "ref" abbreviation for PA Turnpike?

[Bryan Housel]

Sounds good to me - I think the PATP abbreviation is easy to understand. 

Thanks, Bryan 

Sent from my iPhone

> On Nov 10, 2018, at 7:50 PM, Albert Pundt  wrote:
> 
> Does anyone object to the use of "PATP" as the ref equivalent for the PA 
> Turnpike? Particularly for destination:ref tags, as the Turnpike keystone 
> shield is used on most guide signs for ramps onto the Turnpike. However, 
> since it's not used as a reassurance marker*, I don't think it should be 
> added as a ref tag on the ways (i.e. ref=I 76;PATP) as is done on the New 
> Jersey Turnpike, which does have its shield on pull-through signs and similar.
> 
> This sort of abbreviation is already standard practice in New Jersey (for the 
> NJTP, GSP, and ACE) and New York (all the parkways), which have standard 
> shields used on guide signs.
> 
> This would apply to the mainline (I-76 and I-276) and the Northeast Extension 
> (I-476), but not the newer four extensions (PA Tpke 43, 66, 576, and I-376).
> 
> *There is now one set of signs eastbound on the mainline PA Turnpike 
> approaching the Willow Grove (PA 611) interchange that has the PA Turnpike 
> shield on the pull-through side. However, this was put up within the past two 
> months and is not nearly common enough to base system-wide practice on.
> 
> —Albert Pundt
> ___
> 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-ja] 都道府県道の名前について

[yasunari yamashita]

山下です。こんにちわ。

道路のnameについては、
https://lists.openstreetmap.org/pipermail/talk-ja/2013-May/007332.html
から始まるスレッドで、
「name には社会的に認知されよく使われている名称を使用する」
で合意されていると思います。

ご参考まで

2018年11月11日(日) 11:09 horisyu231 :
>
> はじめまして、horisyuです。都道府県道のnameタグについて質問があります。
> Japan 
> taggingにおいて都道府県道のタグ付けの例には「北海道道1号小樽定山渓線」と記載されていますが、実際には「小樽定山渓線」のように都道府県名と番号が省略されてタグ付けされていることが多いようです。
> そこで都道府県道をマッピングする際には「XX県道YY号ZZ線」の形式に書き換えていたのですが、また修正前の「ZZ線」の形式に戻されてしまうことがありました。
> これからマッピングする際にはJapan 
> taggingに沿って「XX県道YY号ZZ線」の形式に書き換えたほうがよいのか、「ZZ線」の形式にしたほうがよいのか、どうすればよいでしょうか。ご教示よろしくおねがいいたします。
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja



-- 
山下康成＠京都府向日市
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [Talk-cz] Národní archiv leteckých snímků

[Pavel Machek]

On Tue 2018-11-06 13:01:15, Jan Macura wrote:
> On Tuesday, 6 November 2018, Marián Kyral  wrote:
> >> b) protože "© ČÚZK"
> > Kolik že to je? 80 let po smrti autora? A kdo je vlastně autor? :-D
> 
> Autorské právo platí 70 let od smrti autora. Nevsadil bych ale na to, že
> stejná doba se aplikuje i na "zvláštní právo pořizovatele databáze",
> nehledě na to, kdy toto právo nabývá účinnosti...
> (Aneb ČÚZK si vždycky výmluvu najde).

Nastesti o tomhle nerozhoduje CUZK ale soud, a CUZK se musi ridit i
jinymi zakony (106, svobodny pristup k informacim), pracuje se na tom,
na OpenAltu o tom byla prednaska.

Nejjednodussi by bylo copyright CUZK proste ignorovat, statni veci na
nej nemaj narok a CUZK k soudu nepujde, protoze by tam prohral :-).
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html


signature.asc
Description: Digital signature
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-in] Extracting a polygon from an mbtiles file

[Aruna S]

Similar to tilelive-copy, are there other tools that can be used to extract
data within a polygon boundary from an mbtiles file?

mbtiles-extracts comes close, but it extracts tiles intersecting with the
polygon, and not tile data bounded by the polygon[1]

[1]: https://github.com/mapbox/mbtiles-extracts/issues/15
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-it] workshop OpenStreetMap a FOSS4G-IT 2019

[Volker Schmidt]

Ciao,

essendo di Padova, conto di esserci.
Posso fare qualcosa come "miglorare la mappa con Mapillary (uso delle foto
e dei segnali stradali)", un argomanto che rientra nel settore mappatura
avanzata, suppongo.

Volker

On Mon, 5 Nov 2018 at 15:41, Alessandro Palmas <
alessandro.pal...@wikimedia.it> wrote:

> Ciao lista,
> come spero tutti sappiate, a Padova dal 19 al 22 febbraio 2019 si terrà
> http://foss4g-it2019.gfoss.it/
>
> Io pensavo di proporre i "soliti" due workshop da 2h ciascuno su
> "Introduzione a OpenStreetMap" e "Editing avanzato in OpenStreetMap",
> dove di avanzato (per chi lavora abitualmente in JOSM e fa qualche query
> overpass) non c'è molto. Questi due workshop negli anni passati hanno
> visto molti partecipanti che si vogliono avvicinare attivamente a OSM e
> sarebbe bello che continuassero ad essere presenti.
>
> Per la prossima edizione non riuscirò ad essere presente alla prima
> giornata visti i miei nuovi impegni. Chiedo se c'è qualcuno che possa
> tenere i due workshop. Se desiderate potete ovviamente prendere spunto,
> o copiare in parte o completamente, le mie slide che prevedono comunque
> parecchia pratica.
>
> Per la call c'è tempo sino al 30 novembre
> http://foss4g-it2019.gfoss.it/callforworkshop
> Mi auguro che qualcuno voglia raccogliere il testimone.
>
> Alessandro Ale_Zena_IT
>
>
> P.S.: sto scrivendo dal mio ex indirizzo mail a cui avrò accesso ancora
> per un certo tempo (lo uso solo per queste mail di servizio).
> Come moltissimi di voi già sapranno non sono più Project Manager
> OpenStreetMap per Wikimedia italia. A tal proposito, tra qualche
> giorno/settimana si aprirà la call per un nuovo PM a cui spero
> arriveranno diverse proposte.
> Happy mapping
>
> ___
> 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: [OSM-talk-fr] Projet du mois de novembre: gendarmerie/police

[Noémie Lehuby]

Hello,

J'ai fait une petite passe pour qualifier les polices municipales avec 
le tag police:FR, on en a à présent un peu plus de 200.
Pour ajouter le tag sur les autres types, je pense qu'on peut se prévoir 
une édition massive à la fin du projet en utilisant la valeur du tag 
operator.


Pour le reste, d'après les fichiers opendata intégrés à Osmose, il nous 
reste environ 1000 gendarmeries et 500 commissariats de police nationale 
à mettre sur la carte : on peut dire qu'on est à mi-chemin je pense ;)


Bonne fin de week-end !

--
Noémie Lehuby

Le 07/11/2018 à 11:20, Erik Amzallag a écrit :

Bonjour,

Projet intéressant, pour plusieurs raisons :)
Au delà de l'enrichissement de la base, ce projet du mois est attractif :
- on peut mapper depuis sa chaise (au contraire des postes électriques 
qui nécessitent un relevé terrain)
- l'objectif des 3000 gendarmeries est facilement atteignable (au 
contraire des postes électriques dont le volume est juste effrayant...)
- ça peut être très rapide (dans le cas où le bâti est déjà tagué, 
avec josm en 2 clics - chargement de la zone, import des attributs - 
l'affaire est jouée). Pour le coup, là où le mapping était de qualité, 
c'est facile - merci aux précédents contributeurs.
- mise en qualité du bâti (correction des imports fainéants où le bâti 
est resté découpé en triangles à cause des parcelles cadastrales...)
- mise en qualité de l'occupation du sol (tracer le landuse military 
permet souvent de repositionner correctement le résidentiel alentour)

- mise en qualité/ajout/correction du voisinage immédiat (routes...)

Toutefois, dans ce qui n'apparait pas dans le descriptif du projet 
mais qui nécessitera surement une seconde passe une fois l'ensemble 
traité, j'ai noté plusieurs écarts dans l'existant :
- valeur de l'attribut building: yes, public, civic. Pour le coup, la 
page projet et amenity=police n'ayant pas précisé cette valeur, je 
suis parti sur building=yes. Mais la page wiki de building=public 
pourrait laisser penser que c'est plutôt cette valeur à utiliser. 
Peut-être faudra t-il prévoir un script de mise à niveau de l'ensemble 
des bâtis Gendarmerie pour uniformiser la chose selon la valeur retenue.
- nature des voies et accès au sein de la gendarmerie (je suis parti 
sur du highway=service plutôt que residential). Quant aux règles 
d'accès, j'ai vu de tout, du coup je n'ai rien précisé (si ce n'est 
barrier=gate à l'entrée). Là aussi, il faudra peut-être se mettre 
d'accord sur les tags à utiliser et faire une passe globale après coup 
pour tout uniformiser.


En tout cas, les petites camionnettes bleues et les zebras aux entrées 
depuis les photos aériennes de la BDOrtho aident beaucoup à bien 
identifier les zones :)


Erik









Le mar. 6 nov. 2018 à 21:56, Cédric Frayssinet > a écrit :


Bonsoir,

Comment sont gérées les épingles ? En effet, hier, j'ai rajouté de
nombreuses gendarmeries dans ce secteur :

https://osmose.openstreetmap.fr/en/map/#item=8191=500=3=11=44.3626=2.4478==
; et j'ai donc cliqué sur le bouton vert pour les faire disparaître.

Aujourd'hui, ces épingles sont réapparues avec un texte 'issus
reported on 2018-11-04', hier, nous étions le 5 hier. Faut-il une
nouvelle analyse ?

De plus, j'ai remarqué au moins 3 gendarmeries en Aveyron dont les
coordonnées GPS sont KO, l'épingle est sur l'ancienne gendarmerie
mais OSMOSE et donc le fichier OpenData indique la nouvelle
adresse. Il faut donc localiser la nouvelle et souvent dessiner ;
d'ailleurs que met-on sur l'ancienne parcelle ?

Je mets entre 5 et 10 mn avec iD pour rajouter une gendarmerie, je
suppose qu'avec JOSM, c'est plus rapide, notamment avec l'ajout en
masse des tags.

Cédric

PS : bravo aux contributeurs de la région parisienne, y a plus bcp
d'épingles dans ce secteur :)



Le 05/11/2018 à 21:21, Noémie Lehuby a écrit :


Hello,

Déjà 5 jours de ce #ProjetDuMoisOSM, voici un premier bilan chiffré :

Près de 700 commissariats ou gendarmeries ont été créés !

D'après les chiffres publiés en opendata par le Ministère de
l'Intérieur, nous avons actuellement, à la louche, un sixième de
commissariats de Police Nationale, et un tiers des gendarmeries.
(je n'ai pas trouvé de source officielle pour un nombre de
commissariats de police municipale, n'hésitez pas si vous avez ça
sous la main)

Bref, on va dans la bonne direction, il faut maintenir le rythme !
N'hésitez pas à partager vos astuces ici ou en complétant la page
du projet du mois


;)

-- 
Noémie Lehuby

Le 04/11/2018 à 22:26, Vincent de Château-Thierry a écrit :

Bonsoir,


De: "Noémie Lehuby"  


Le 04/11/2018 à 11:26, lenny.libre a écrit :

+1 avec Vincent, du fait de la présence des polices 

Re: [Talk-it] workshop OpenStreetMap a FOSS4G-IT 2019

[Luca Delucchi]

Il giorno dom 11 nov 2018, 11:55 Stefano  ha scritto:

> Entro quanto va proposto il workshop?
>

Entro fine mese


> Stefano
>

Ciao
Luca

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

Re: [Talk-it] workshop OpenStreetMap a FOSS4G-IT 2019

[mbranco2]

Bisgona proporlo entro fine mese.
Ci sarò anch'io, e ne sto parlando anche con Matteo Zaffonato.
Fra tutti, 'sti due workshop li facciamo :-)

Ciao,
Marco

Il giorno dom 11 nov 2018 alle ore 11:55 Stefano  ha
scritto:

> Entro quanto va proposto il workshop?
> Al limite posso farlo io, se c'è qualcun'altro di backup bene.
>
> Stefano
>
> Il giorno dom 11 nov 2018 alle ore 11:53 Marco Minghini <
> marco.minghin...@gmail.com> ha scritto:
>
>> credo di non essere un candidato ideale per tenere i workshops, in
>>> particolare quello dell'editing avanzato, però non vorrei che questa
>>> chiamata di Ale rimanesse in sospeso per troppo tempo, e quindi intanto mi
>>> propongo per dare una mano per la call ed eventualmente per un aiuto per il
>>> workshop più generale.
>>>
>> Anche io sono dell'idea che la chiamata di Ale non debba andare a vuoto e
>> penso sia importante "mantenere" entrambi i workshop al convegno.
>> Personalmente non sono ancora sicuro di poter esserci anche per la giornata
>> dei workshop, nel caso sono disponibile a dare una mano ma sono sicuro che
>> in lista ci sono persone molto piú qualificate per entrambi, il punto è
>> capire chi tra le persone che leggono questa lista sará a Padova.
>> Forse potremmo cominciare a fare un elenco...
>>
>>> Intanto ad Ale chiedo se le slides sono disponibili da qualche parte (ho
>>> guardato nel sito dell'anno scorso ma non le ho trovate).
>>>
>> A proposito di materiale:
>> - ieri HOT ha tenuto un webinar su JOSM avanzato, l'ho seguito e l'ho
>> trovato molto utile (le slide saranno a breve su YouTube)
>> - qualche mese fa sempe HOT ha tenuto un webinar su JOSM base, che
>> trovate qui: https://www.youtube.com/watch?v=tF3MIHoPzoI=youtu.be
>>
>> Marco
>>
>> ___
>> 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
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] workshop OpenStreetMap a FOSS4G-IT 2019

[Stefano]

Entro quanto va proposto il workshop?
Al limite posso farlo io, se c'è qualcun'altro di backup bene.

Stefano

Il giorno dom 11 nov 2018 alle ore 11:53 Marco Minghini <
marco.minghin...@gmail.com> ha scritto:

> credo di non essere un candidato ideale per tenere i workshops, in
>> particolare quello dell'editing avanzato, però non vorrei che questa
>> chiamata di Ale rimanesse in sospeso per troppo tempo, e quindi intanto mi
>> propongo per dare una mano per la call ed eventualmente per un aiuto per il
>> workshop più generale.
>>
> Anche io sono dell'idea che la chiamata di Ale non debba andare a vuoto e
> penso sia importante "mantenere" entrambi i workshop al convegno.
> Personalmente non sono ancora sicuro di poter esserci anche per la giornata
> dei workshop, nel caso sono disponibile a dare una mano ma sono sicuro che
> in lista ci sono persone molto piú qualificate per entrambi, il punto è
> capire chi tra le persone che leggono questa lista sará a Padova.
> Forse potremmo cominciare a fare un elenco...
>
>> Intanto ad Ale chiedo se le slides sono disponibili da qualche parte (ho
>> guardato nel sito dell'anno scorso ma non le ho trovate).
>>
> A proposito di materiale:
> - ieri HOT ha tenuto un webinar su JOSM avanzato, l'ho seguito e l'ho
> trovato molto utile (le slide saranno a breve su YouTube)
> - qualche mese fa sempe HOT ha tenuto un webinar su JOSM base, che trovate
> qui: https://www.youtube.com/watch?v=tF3MIHoPzoI=youtu.be
>
> Marco
>
> ___
> 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] workshop OpenStreetMap a FOSS4G-IT 2019

[Marco Minghini]

>
> credo di non essere un candidato ideale per tenere i workshops, in
> particolare quello dell'editing avanzato, però non vorrei che questa
> chiamata di Ale rimanesse in sospeso per troppo tempo, e quindi intanto mi
> propongo per dare una mano per la call ed eventualmente per un aiuto per il
> workshop più generale.
>
Anche io sono dell'idea che la chiamata di Ale non debba andare a vuoto e
penso sia importante "mantenere" entrambi i workshop al convegno.
Personalmente non sono ancora sicuro di poter esserci anche per la giornata
dei workshop, nel caso sono disponibile a dare una mano ma sono sicuro che
in lista ci sono persone molto piú qualificate per entrambi, il punto è
capire chi tra le persone che leggono questa lista sará a Padova.
Forse potremmo cominciare a fare un elenco...

> Intanto ad Ale chiedo se le slides sono disponibili da qualche parte (ho
> guardato nel sito dell'anno scorso ma non le ho trovate).
>
A proposito di materiale:
- ieri HOT ha tenuto un webinar su JOSM avanzato, l'ho seguito e l'ho
trovato molto utile (le slide saranno a breve su YouTube)
- qualche mese fa sempe HOT ha tenuto un webinar su JOSM base, che trovate
qui: https://www.youtube.com/watch?v=tF3MIHoPzoI=youtu.be

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Thu, Nov 8, 2018 at 5:07 PM Leif Rasmussen <354...@gmail.com> wrote:

> Integrating GTFS seems like a much better idea than adding actual
> schedules to OpenStreetMap.  I had not considered this previously because I
> did not understand how GTFS is used worldwide.  Perhaps it would be
> possible to start something like a new gtfs.openstreetmap.org (which
> would be similar to transit.land and transitfeeds.com, but with a focus
> of OpenStreetMap integration) for hosting GTFS feeds that could be
> integrated into OSM.  That would allow for much easier integration and
> maintenance.
>

Easier still would be to use existing feeds.  The only copyright issue
involved iswhether or not those
feeds permit "deep linking" and I think most do.

Copying what Google has done successfully seems like a better option than
> creating a big, out of date mess.
>

Google has put a lot of thought into it.  It's possible, of course, that
the current GTFS now evolved from
more primitive beginnings and has a few things that might be bettter if
starting from scratch.
Nevertheless, it seems like a workable system and, more importantly, it's
already in use and some
organizations use it to make their route information public.  I don't think
that wheel needs to be
re-invented.

I think that creating a new GTFS server would be better than using transit
> land or transitfeeds.com, because OSM would have full control over what
> happened to the servers and which licencing was used.
>

I think that anything other than full mirroring, in the same way the OSM
database is mirrored by other
tile providers, would be a mistake.  And even full mirroring would be
unnecessary for this usage.  I
see an OSM GTFS server, if it comes into existence, as a way for mappers to
create GTFS feeds
for routes that don't currently have them.  And, if we're able to use
something like transitland or
transitfeeds for that purpose, we don't even need an OSM server (unless we
don't trust their data
or trust them to stay in existence, for some reason).

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

That is something that OSM should map instead of the official timetable :)

In Paris it is almost the same case, the bus does not follow their official
timetable due to grid locks.

Julien « djakk »


Le mer. 7 nov. 2018 à 00:16, Martin Koppenhoefer  a
écrit :

>
>
> sent from a phone
>
> > On 6. Nov 2018, at 15:41, djakk djakk  wrote:
> >
> > Martin, maybe locals do know their bus stop timetable, as they always
> use the service they may memorize the schedules ... ?
>
>
> there are no timetables and the service is notoriously bad and infrequent,
> while management scandals are frequent. This weekend there will be a
> referendum about closing the public company and procurement by tender.
>
> Cheers, Martin
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Thu, Nov 8, 2018 at 12:07 AM OSMDoudou <
19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com> wrote:

> > Even if you can make it fit, it's not necessarily a good idea to do it.
> > I'm thinking of the Hoover Dustette.
>
> Excuse my ignorance. You’re thinking to what ?
>

The Hoover Dustette was a cylinder vacuum cleaner.  The impeller had no
protective guard since
it was set so far inside the machine that the British Standard Finger (yes,
there is such a thing)
could not reach it and therefore it was not a danger.  Not a danger until
somebody found himself
sexually attracted to something that was warm, throbbed and sucked.  It
didn't end well for him.
Nor for the others that tried the same thing.  The excuses they came up
with for how they had their
"accident" were amusing.  Moral which applies to this thread: even if you
can make it fit, it may not
be a good idea to do so.

> I'm not sure that a wiki would be the optimal architecture for this if we
> ended up with many GTFS feeds that were interrogated frequently.
>
> Problem solved already, it seems: http://transitfeeds.com.
>

 Looks good, apart from their problem loading Google Maps.  If only there
were some other map
they could use instead. :)

I think that, unless there are serious flaws with GTFS, we should figure
out a way to tag it.  Another
problem I thought of is whether it should go on individual stops or route
relations.  Simplicity and
data integrity says on route relations.  The ability for an ordinary user
to use the query tool on the
standard map to find which buses stop at a certain stop and at what times
says on bus/train stops.

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

For example in Japan transit companies sells their timetable for about
1000€ ... maybe copying the timetable is forbidden but Osm can have at
least an opening hour and a frequency for a line in Japan.
An other example, the city of Accra (Ghana) : only share taxis, no transit
authority, lines are already mapped in OSM, with a travel time and a
frequency.

Julien « djakk »


Le mer. 7 nov. 2018 à 14:37, Jonathon Rossi  a écrit :

> I've been following along the few threads to better understand this topic,
> however I'm still feeling that mapping complex timetables is a bit like
> mapping the full menu of a cafe or restaurant, or the room options at a
> hotel. These things vary whenever the service business chooses and it is
> close to impossible to keep it up to date.
>
> In Brisbane Australia, some PT timetables vary often especially with
> public holidays (local, state or federal), school holidays (which differ
> between schools) and especially with special events (sporting, concerts,
> etc). Sometimes timetables get more trips sometimes less, it can be quite
> variable throughout the year and not something that can be 100% codified
> into timetable rules, and obviously not known too far in advance.
>
> I appreciate that timetables are very useful for consumers of maps, and
> understand that in some cities timetables can be reverse engineered by
> being somewhat observable (I would think copying a full timetable off a
> sign would classify as an import), however are we concerned that this adds
> a massive burden to maintain this data in OSM and it is very likely to
> always be out of date? If it is always going to be out of date will any app
> developer even integrate this data into their app when they can use GTFS
> feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of
> either application been consulted?
>
> Having this data embedded in the OSM tags also forces apps to reduce their
> map cache duration to try to get more updated timetables.
>
> I'm not very experienced with PT in OSM, but I'd have thought improving
> the tags for mapping objects to GTFS feeds, including the GTFS endpoints
> and license info as tags, and maybe then adding the ability to discover the
> GTFS Realtime extension would be the way to go. I think this would give
> much more power to app developers. It does overlap a little with
> Transitland, but obviously OSM wouldn't be polling or hosting the feeds,
> that would be up to an application developer.
>
> Happy to hear any feedback if I've missed the point of this.
>
> On Tue, Nov 6, 2018 at 2:07 AM Jo  wrote:
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started creating
>> a new one. It differs in rather important ways from your proposal, so I
>> preferred not modifying your wiki page. I also think it's important to
>> decouple the (voting for a) full timetable solution from the solution where
>> tags are added to indicate interval during 'opening_hours' or a route,
>> which is a lot more likely to be accepted.
>>
>> So here goes:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> Please let me know what you think. What I still haven't figured out yet
>> is how to differ weekdays that fall in school holiday periods from "normal"
>> weekdays. So work in progress.
>>
>> Polyglot
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
> --
> Jono
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jonathon Rossi]

I've been following along the few threads to better understand this topic,
however I'm still feeling that mapping complex timetables is a bit like
mapping the full menu of a cafe or restaurant, or the room options at a
hotel. These things vary whenever the service business chooses and it is
close to impossible to keep it up to date.

In Brisbane Australia, some PT timetables vary often especially with public
holidays (local, state or federal), school holidays (which differ between
schools) and especially with special events (sporting, concerts, etc).
Sometimes timetables get more trips sometimes less, it can be quite
variable throughout the year and not something that can be 100% codified
into timetable rules, and obviously not known too far in advance.

I appreciate that timetables are very useful for consumers of maps, and
understand that in some cities timetables can be reverse engineered by
being somewhat observable (I would think copying a full timetable off a
sign would classify as an import), however are we concerned that this adds
a massive burden to maintain this data in OSM and it is very likely to
always be out of date? If it is always going to be out of date will any app
developer even integrate this data into their app when they can use GTFS
feeds? The proposal refers to MAPS.ME and OsmAnd, have the developers of
either application been consulted?

Having this data embedded in the OSM tags also forces apps to reduce their
map cache duration to try to get more updated timetables.

I'm not very experienced with PT in OSM, but I'd have thought improving the
tags for mapping objects to GTFS feeds, including the GTFS endpoints and
license info as tags, and maybe then adding the ability to discover the
GTFS Realtime extension would be the way to go. I think this would give
much more power to app developers. It does overlap a little with
Transitland, but obviously OSM wouldn't be polling or hosting the feeds,
that would be up to an application developer.

Happy to hear any feedback if I've missed the point of this.

On Tue, Nov 6, 2018 at 2:07 AM Jo  wrote:

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started creating
> a new one. It differs in rather important ways from your proposal, so I
> preferred not modifying your wiki page. I also think it's important to
> decouple the (voting for a) full timetable solution from the solution where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured out yet is
> how to differ weekdays that fall in school holiday periods from "normal"
> weekdays. So work in progress.
>
> Polyglot
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Hello !

Ok for a google hangout ! I’m also available tonight and on Friday evening.

Julien « djakk »


Le mer. 7 nov. 2018 à 12:53, Jo  a écrit :

> Hi Tony,
>
> Could you also have a look at the proposal I created?
>
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> At the moment I'm looking into how to represent that in meaningful ways
> using MapCSS in JOSM, but I don't think that makes too much sense.
>
> For your use case where you want to do routing. The timetable relations
> give the possibility to calculate when a bus passes at a particular stop at
> a given time of day. And it's possible to see how long it takes to get from
> there to another stop or calculate at what time one arrives there. For
> complex routing involving transfers this will involve quite a bit of
> recursion, but it should be feasible.
>
> At the moment I'm looking how this can be rendered in meaningful ways and
> how data entry can be made as convenient as possible. (I think we need
> spreadsheet like functionality to accomplish that, I made an attempt here:
> https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
> .
> But we need more possibilities for indicating where a specific time on the
> schedule came from.
>
> Right now I have the following:
>
> Line (route_master relation)
>contains several:
>  Itineraries composes of (longest) stop sequences including ways
> (route relation)
> if referred to by 1 or more
>Actual stop sequences with time deltas (timetable relation)
>The stops in these relations are always a subset of the
> referre route relation
>
> I would also include a public_holidays relation in each route_master
> relation to avoid duplication but still enable which days get Sunday
> schedules and which days are in school holiday periods.
>
>
> If anyone feels like doing a Google Hangout to discuss this, let me know.
> I have time tonight and Friday evening
>
> Polyglot
>
> Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :
>
>> Hi
>>
>> I have worked in data analysis for many years, recently become interested
>> in PT and added routes to my locality. I look at PT timetables frequently
>> as much of my travel is by PT.
>>
>> My use case is that I want to find times and routes from A to B, I do not
>> know the route numbers or their actual route. I expect the system to be
>> able to give times and routes and any interchanges.
>>
>> As a system I fail to see how putting the timing detail on each stop will
>> enable me to efficiently perform that use case. From what is described
>> system would have to identify route, then iterate route to check if
>> destination is on route, if on route then  select time entry in A then a
>> time entry in B and ASSUME that they both relate to the same journey and
>> have been updated correctly. For connections/interchanges the same rules
>> apply. Those assumptions make storing the data against a stop
>> extraordinarily unreliable, the proposed method does not take shortened
>> journeys - eg school or factory journeys where the whole route is not
>> travelled  - into account.
>>
>> I suggest that the best way to get timetable data is to replicate the
>> present system that most PT organisations do - a table related to the
>> route. A timetable could be associated with an OSM route. A system will be
>> required to generate meaningful times and itineraries, so should we be
>> asking those existing OSM routing people what  is their preferred way to
>> store timetable data that can be updated reliably.
>>
>> Here in the UK timetable data is in the public domain - is that the case
>> in other places?
>>
>> TonyS
>>
>>
>>
>> On 06/11/2018 19:59, Jo wrote:
>>
>> Indeed, a mapper who wants to add this and who can't find the information
>> on the internet or in a booklet, would have travel to the first stop, take
>> note of all the departure times and then establish the deltas between all
>> the stops of the itinerary.
>> If that's the case, such a mapper would probably better use the tags
>> based method on the route relations.
>>
>> It all depends on how much detail you want to add (and maintain in the
>> long run).
>>
>> Another weakness of the relation pet stop/route pair method is that it
>> will be very hard to encode the exceptions; not on Wednesdays, only on
>> Fridays, etc.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 20:22 schreef djakk djakk :
>>
>>> Ok I see.
>>>
>>> I am still a bit reluctant to your proposal since the travelling time
>>> between 2 stops can vary during the day, especially for train routes.
>>> Ok there is the possibility of adding a new timetable relation ...
>>>
>>> Moreover, I think that data inputs from the ground can not be done with
>>> your proposal (it needs to know the timetable for the whole line), we’ll
>>> depend on GTFS file actually :-/
>>>
>>> Julien “djakk”
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>>>
 Yes, 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Paul Allen]

On Wed, Nov 7, 2018 at 5:08 PM Jo  wrote:

> (started writing this several hours ago)
>
> And another that goes into full detail, listing all the departures at the
> first stop and then lists all stops, with the most common times between
> stops as roles. For this we would need separate public_transport=timetable
> relations.
>
> I've been trying how that could work and I can confirm what everybody
> already knew: it's a lot of work, even for lines that seem relatively
> simple at first sight! :-) An incredible time sink.
>

And it can go stale, very quickly.  Sure, there are places where the same
route has operated to the
same schedule since time immemorial, but there are other places where
timetables change on whim.

And it's re-inventing the wheel.  GTFS already exists.  Could we do
better?  Maybe, maybe not.  Could
we convince operators to duplicate their effort in maintaining GTFS and our
alternative?  I very much
doubt it.  Could we convince data consumers to support our format as well
as GTFS?  I very much
doubt that too.  This is not just re-inventing the wheel, it's insisting
everyone has to fit our wheel as
well as the wheel they already have.  Good luck with that.

What we can do is come up with a tag to place on a route that points at a
GTFS feed on the web.
That feed could be published by the operator or by an independent
organization.  We could perhaps
encourage mappers to generate feeds where the operator doesn't provide them
and maybe even
go so far as to run a web server hosting those feeds until such time as a
more official feed is
available.  Even offer an alternative feed that our tag points to when the
official feed is known to be
seriously incorrect.

I think we could (probably should) have a tag linking to the operator's
timetable whether or not
a GTFS feed is available.  Even the query tool of the standard map exposes
links that can be clicked
on.  That doesn't require a third-party app to make the info available to
an ordinary user.

So, an interesting exercise.  One that (perhaps) had to be tried to
determine if it was a good idea or
not.  And maybe there's room for a sloppy "once a day" or "once a week" tag
on minor routes that
will probably never get a GTFS feed.

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Tony Shield]

Hi

I have worked in data analysis for many years, recently become 
interested in PT and added routes to my locality. I look at PT 
timetables frequently as much of my travel is by PT.


My use case is that I want to find times and routes from A to B, I do 
not know the route numbers or their actual route. I expect the system to 
be able to give times and routes and any interchanges.


As a system I fail to see how putting the timing detail on each stop 
will enable me to efficiently perform that use case. From what is 
described system would have to identify route, then iterate route to 
check if destination is on route, if on route then  select time entry in 
A then a time entry in B and ASSUME that they both relate to the same 
journey and have been updated correctly. For connections/interchanges 
the same rules apply. Those assumptions make storing the data against a 
stop extraordinarily unreliable, the proposed method does not take 
shortened journeys - eg school or factory journeys where the whole route 
is not travelled  - into account.


I suggest that the best way to get timetable data is to replicate the 
present system that most PT organisations do - a table related to the 
route. A timetable could be associated with an OSM route. A system will 
be required to generate meaningful times and itineraries, so should we 
be asking those existing OSM routing people what  is their preferred way 
to store timetable data that can be updated reliably.


Here in the UK timetable data is in the public domain - is that the case 
in other places?


TonyS



On 06/11/2018 19:59, Jo wrote:
Indeed, a mapper who wants to add this and who can't find the 
information on the internet or in a booklet, would have travel to the 
first stop, take note of all the departure times and then establish 
the deltas between all the stops of the itinerary.
If that's the case, such a mapper would probably better use the tags 
based method on the route relations.


It all depends on how much detail you want to add (and maintain in the 
long run).


Another weakness of the relation pet stop/route pair method is that it 
will be very hard to encode the exceptions; not on Wednesdays, only on 
Fridays, etc.


Jo

Op di 6 nov. 2018 om 20:22 schreef djakk djakk >:


Ok I see.

I am still a bit reluctant to your proposal since the travelling
time between 2 stops can vary during the day, especially for train
routes.
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done
with your proposal (it needs to know the timetable for the whole
line), we’ll depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo mailto:winfi...@gmail.com>> a écrit :

Yes, very hard to debug and we already established some change
every few months. So after a change from the operator. One
traveler will update one of those schedules, Another may do so
for 3 stops down the line, in the mean time the stops in
between and after are not updated yet. A maintenance
nightmare. The way I proposed it, suffers less from that
problem. When timetables change it's usually that trips are
added or removed or their start time changes slightly. The
time to get from one stop to the next will remain constant,
most of the time.

Jo

Op di 6 nov. 2018 om 18:40 schreef djakk djakk
mailto:djakk.dj...@gmail.com>>:

I don’t get it ...

With my point of view, one route with 15 stops has 15
timetables, each timetable describes the arrival time and
the departure time of several trips at the stop.

There must be the same number of trips along the stops’
timetables. (Otherwise this is an other route).

You mean, if somebody messed up and add an extra trip
inside a timetable, this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo mailto:winfi...@gmail.com>> a écrit :

If you have a single one for a stop/route pair, no
problem. As soon as you have a few hundred and the
information in them starts to conflict with other
another timetable relation for the same route it will
be extremely hard to figure out where it went wrong.

Polyglot

Op di 6 nov. 2018 om 17:08 schreef djakk djakk
mailto:djakk.dj...@gmail.com>>:

In which case a timetable per stop and per route
is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk
mailto:djakk.dj...@gmail.com>> a écrit :

I think it is important to have an osm object
  

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Jo]

Hi Tony,

Could you also have a look at the proposal I created?

https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

At the moment I'm looking into how to represent that in meaningful ways
using MapCSS in JOSM, but I don't think that makes too much sense.

For your use case where you want to do routing. The timetable relations
give the possibility to calculate when a bus passes at a particular stop at
a given time of day. And it's possible to see how long it takes to get from
there to another stop or calculate at what time one arrives there. For
complex routing involving transfers this will involve quite a bit of
recursion, but it should be feasible.

At the moment I'm looking how this can be rendered in meaningful ways and
how data entry can be made as convenient as possible. (I think we need
spreadsheet like functionality to accomplish that, I made an attempt here:
https://docs.google.com/spreadsheets/d/16wEAMjbgr9yEUglGaUzdGkB5MJEg3VEI3om6UgCnqKg/edit#gid=0
.
But we need more possibilities for indicating where a specific time on the
schedule came from.

Right now I have the following:

Line (route_master relation)
   contains several:
 Itineraries composes of (longest) stop sequences including ways (route
relation)
if referred to by 1 or more
   Actual stop sequences with time deltas (timetable relation)
   The stops in these relations are always a subset of the
referre route relation

I would also include a public_holidays relation in each route_master
relation to avoid duplication but still enable which days get Sunday
schedules and which days are in school holiday periods.


If anyone feels like doing a Google Hangout to discuss this, let me know. I
have time tonight and Friday evening

Polyglot

Op wo 7 nov. 2018 om 12:24 schreef Tony Shield :

> Hi
>
> I have worked in data analysis for many years, recently become interested
> in PT and added routes to my locality. I look at PT timetables frequently
> as much of my travel is by PT.
>
> My use case is that I want to find times and routes from A to B, I do not
> know the route numbers or their actual route. I expect the system to be
> able to give times and routes and any interchanges.
>
> As a system I fail to see how putting the timing detail on each stop will
> enable me to efficiently perform that use case. From what is described
> system would have to identify route, then iterate route to check if
> destination is on route, if on route then  select time entry in A then a
> time entry in B and ASSUME that they both relate to the same journey and
> have been updated correctly. For connections/interchanges the same rules
> apply. Those assumptions make storing the data against a stop
> extraordinarily unreliable, the proposed method does not take shortened
> journeys - eg school or factory journeys where the whole route is not
> travelled  - into account.
>
> I suggest that the best way to get timetable data is to replicate the
> present system that most PT organisations do - a table related to the
> route. A timetable could be associated with an OSM route. A system will be
> required to generate meaningful times and itineraries, so should we be
> asking those existing OSM routing people what  is their preferred way to
> store timetable data that can be updated reliably.
>
> Here in the UK timetable data is in the public domain - is that the case
> in other places?
>
> TonyS
>
>
>
> On 06/11/2018 19:59, Jo wrote:
>
> Indeed, a mapper who wants to add this and who can't find the information
> on the internet or in a booklet, would have travel to the first stop, take
> note of all the departure times and then establish the deltas between all
> the stops of the itinerary.
> If that's the case, such a mapper would probably better use the tags based
> method on the route relations.
>
> It all depends on how much detail you want to add (and maintain in the
> long run).
>
> Another weakness of the relation pet stop/route pair method is that it
> will be very hard to encode the exceptions; not on Wednesdays, only on
> Fridays, etc.
>
> Jo
>
> Op di 6 nov. 2018 om 20:22 schreef djakk djakk :
>
>> Ok I see.
>>
>> I am still a bit reluctant to your proposal since the travelling time
>> between 2 stops can vary during the day, especially for train routes.
>> Ok there is the possibility of adding a new timetable relation ...
>>
>> Moreover, I think that data inputs from the ground can not be done with
>> your proposal (it needs to know the timetable for the whole line), we’ll
>> depend on GTFS file actually :-/
>>
>> Julien “djakk”
>>
>>
>>
>> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>>
>>> Yes, very hard to debug and we already established some change every few
>>> months. So after a change from the operator. One traveler will update one
>>> of those schedules, Another may do so for 3 stops down the line, in the
>>> mean time the stops in between and after are not updated yet. A maintenance
>>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

:)

Le mar. 6 nov. 2018 à 20:55, Yves  a écrit :

> Are you looking for a general transit feed specification?
> :)
>
> Yves
>
> Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk 
> a écrit :
>>
>> Ok I see.
>>
>> I am still a bit reluctant to your proposal since the travelling time
>> between 2 stops can vary during the day, especially for train routes.
>> Ok there is the possibility of adding a new timetable relation ...
>>
>> Moreover, I think that data inputs from the ground can not be done with
>> your proposal (it needs to know the timetable for the whole line), we’ll
>> depend on GTFS file actually :-/
>>
>> Julien “djakk”
>>
>>
>>
>> Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>>
>>> Yes, very hard to debug and we already established some change every few
>>> months. So after a change from the operator. One traveler will update one
>>> of those schedules, Another may do so for 3 stops down the line, in the
>>> mean time the stops in between and after are not updated yet. A maintenance
>>> nightmare. The way I proposed it, suffers less from that problem. When
>>> timetables change it's usually that trips are added or removed or their
>>> start time changes slightly. The time to get from one stop to the next will
>>> remain constant, most of the time.
>>>
>>> Jo
>>>
>>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>>>
 I don’t get it ...

 With my point of view, one route with 15 stops has 15 timetables, each
 timetable describes the arrival time and the departure time of several
 trips at the stop.

 There must be the same number of trips along the stops’ timetables.
 (Otherwise this is an other route).

 You mean, if somebody messed up and add an extra trip inside a
 timetable, this would be hard to figure ?

 Julien “djakk”


 Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :

> If you have a single one for a stop/route pair, no problem. As soon as
> you have a few hundred and the information in them starts to conflict with
> other another timetable relation for the same route it will be extremely
> hard to figure out where it went wrong.
>
> Polyglot
>
> Op di 6 nov. 2018 om 17:08 schreef djakk djakk  >:
>
>> In which case a timetable per stop and per route is unmaintable ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>> écrit :
>>
>>> I think it is important to have an osm object describing the
>>> timetable user-oriented for simple editing without any tool.
>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>> import it later in osm without the need of any extra tool.
>>> Validator can be inside a tool.
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>> écrit :
>>>
 Almost that ! Sometimes bus stops does not have their official
 timetable, the user have to refer to the closest previous bus stop 
 having
 an official timetable. So this kind of bus stop may not have a 
 timetable in
 osm (except an osm mapper really wants to put it into osm, knowing per
 habits the schedule).


 Julien « djakk »



 Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :

> You mean per stop/route pair? That's an incredible s amount of
> relations! It seems to me that it would be a nighmare to try and 
> maintain
> it that way. At first sight it seems simpler, but with the new 
> proposal i
> came up with, you can see how the stops of a variation in itinerary 
> tie
> together.
>
> If the vehicle remains in the station longer, the roles could
> become 00:30-00:35 instead of simply 00:35 for the departure offset 
> to the
> time the vehicle left at its first stop.
>
> Seeing the stops in the timetable relation in the order they are
> served also enables comparing this with the stops sequence in the 
> route
> relation they refer to, adding additional possibilities for 
> validation of
> the data.
>
> The stops in a timetable sequence should always be a subset of the
> stops in a route relation and appear in the same order.
>
> Polyglot
>
>
> Op di 6 nov. 2018 om 16:07 schreef djakk djakk <
> djakk.dj...@gmail.com>:
>
>> I’ll agree with Leif, having a timetable relation per stop is
>> better.
>>
>>
>> Yes Leif, there can be a delay expressed in minutes instead of an
>> arrival-departure pair of time.
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:04, djakk djakk 
>> a écrit :
>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[Yves]

Are you looking for a general transit feed specification?
:)
Yves 

Le 6 novembre 2018 20:22:18 GMT+01:00, djakk djakk  a 
écrit :
>Ok I see.
>
>I am still a bit reluctant to your proposal since the travelling time
>between 2 stops can vary during the day, especially for train routes.
>Ok there is the possibility of adding a new timetable relation ...
>
>Moreover, I think that data inputs from the ground can not be done with
>your proposal (it needs to know the timetable for the whole line),
>we’ll
>depend on GTFS file actually :-/
>
>Julien “djakk”
>
>
>
>Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :
>
>> Yes, very hard to debug and we already established some change every
>few
>> months. So after a change from the operator. One traveler will update
>one
>> of those schedules, Another may do so for 3 stops down the line, in
>the
>> mean time the stops in between and after are not updated yet. A
>maintenance
>> nightmare. The way I proposed it, suffers less from that problem.
>When
>> timetables change it's usually that trips are added or removed or
>their
>> start time changes slightly. The time to get from one stop to the
>next will
>> remain constant, most of the time.
>>
>> Jo
>>
>> Op di 6 nov. 2018 om 18:40 schreef djakk djakk
>:
>>
>>> I don’t get it ...
>>>
>>> With my point of view, one route with 15 stops has 15 timetables,
>each
>>> timetable describes the arrival time and the departure time of
>several
>>> trips at the stop.
>>>
>>> There must be the same number of trips along the stops’ timetables.
>>> (Otherwise this is an other route).
>>>
>>> You mean, if somebody messed up and add an extra trip inside a
>timetable,
>>> this would be hard to figure ?
>>>
>>> Julien “djakk”
>>>
>>>
>>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>>
 If you have a single one for a stop/route pair, no problem. As soon
>as
 you have a few hundred and the information in them starts to
>conflict with
 other another timetable relation for the same route it will be
>extremely
 hard to figure out where it went wrong.

 Polyglot

 Op di 6 nov. 2018 om 17:08 schreef djakk djakk
>:

> In which case a timetable per stop and per route is unmaintable ?
>
> Julien “djakk”
>
>
> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
> écrit :
>
>> I think it is important to have an osm object describing the
>timetable
>> user-oriented for simple editing without any tool.
>> The mapper is at a bus stop, takes a picture of the timetable,
>can
>> import it later in osm without the need of any extra tool.
>> Validator can be inside a tool.
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 16:46, djakk djakk 
>a
>> écrit :
>>
>>> Almost that ! Sometimes bus stops does not have their official
>>> timetable, the user have to refer to the closest previous bus
>stop having
>>> an official timetable. So this kind of bus stop may not have a
>timetable in
>>> osm (except an osm mapper really wants to put it into osm,
>knowing per
>>> habits the schedule).
>>>
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>>
 You mean per stop/route pair? That's an incredible s amount of
 relations! It seems to me that it would be a nighmare to try
>and maintain
 it that way. At first sight it seems simpler, but with the new
>proposal i
 came up with, you can see how the stops of a variation in
>itinerary tie
 together.

 If the vehicle remains in the station longer, the roles could
>become
 00:30-00:35 instead of simply 00:35 for the departure offset to
>the time
 the vehicle left at its first stop.

 Seeing the stops in the timetable relation in the order they
>are
 served also enables comparing this with the stops sequence in
>the route
 relation they refer to, adding additional possibilities for
>validation of
 the data.

 The stops in a timetable sequence should always be a subset of
>the
 stops in a route relation and appear in the same order.

 Polyglot


 Op di 6 nov. 2018 om 16:07 schreef djakk djakk <
 djakk.dj...@gmail.com>:

> I’ll agree with Leif, having a timetable relation per stop is
> better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of
>an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk
> a
> écrit :
>
>> In order to reduce the length of the value of the departures=
>tag,
>> should we allow this kind of abstraction level :
>departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Ok I see.

I am still a bit reluctant to your proposal since the travelling time
between 2 stops can vary during the day, especially for train routes.
Ok there is the possibility of adding a new timetable relation ...

Moreover, I think that data inputs from the ground can not be done with
your proposal (it needs to know the timetable for the whole line), we’ll
depend on GTFS file actually :-/

Julien “djakk”



Le mar. 6 nov. 2018 à 19:27, Jo  a écrit :

> Yes, very hard to debug and we already established some change every few
> months. So after a change from the operator. One traveler will update one
> of those schedules, Another may do so for 3 stops down the line, in the
> mean time the stops in between and after are not updated yet. A maintenance
> nightmare. The way I proposed it, suffers less from that problem. When
> timetables change it's usually that trips are added or removed or their
> start time changes slightly. The time to get from one stop to the next will
> remain constant, most of the time.
>
> Jo
>
> Op di 6 nov. 2018 om 18:40 schreef djakk djakk :
>
>> I don’t get it ...
>>
>> With my point of view, one route with 15 stops has 15 timetables, each
>> timetable describes the arrival time and the departure time of several
>> trips at the stop.
>>
>> There must be the same number of trips along the stops’ timetables.
>> (Otherwise this is an other route).
>>
>> You mean, if somebody messed up and add an extra trip inside a timetable,
>> this would be hard to figure ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :
>>
>>> If you have a single one for a stop/route pair, no problem. As soon as
>>> you have a few hundred and the information in them starts to conflict with
>>> other another timetable relation for the same route it will be extremely
>>> hard to figure out where it went wrong.
>>>
>>> Polyglot
>>>
>>> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>>>
 In which case a timetable per stop and per route is unmaintable ?

 Julien “djakk”


 Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
 écrit :

> I think it is important to have an osm object describing the timetable
> user-oriented for simple editing without any tool.
> The mapper is at a bus stop, takes a picture of the timetable, can
> import it later in osm without the need of any extra tool.
> Validator can be inside a tool.
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
> écrit :
>
>> Almost that ! Sometimes bus stops does not have their official
>> timetable, the user have to refer to the closest previous bus stop having
>> an official timetable. So this kind of bus stop may not have a timetable 
>> in
>> osm (except an osm mapper really wants to put it into osm, knowing per
>> habits the schedule).
>>
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>
>>> You mean per stop/route pair? That's an incredible s amount of
>>> relations! It seems to me that it would be a nighmare to try and 
>>> maintain
>>> it that way. At first sight it seems simpler, but with the new proposal 
>>> i
>>> came up with, you can see how the stops of a variation in itinerary tie
>>> together.
>>>
>>> If the vehicle remains in the station longer, the roles could become
>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>> the vehicle left at its first stop.
>>>
>>> Seeing the stops in the timetable relation in the order they are
>>> served also enables comparing this with the stops sequence in the route
>>> relation they refer to, adding additional possibilities for validation 
>>> of
>>> the data.
>>>
>>> The stops in a timetable sequence should always be a subset of the
>>> stops in a route relation and appear in the same order.
>>>
>>> Polyglot
>>>
>>>
>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk <
>>> djakk.dj...@gmail.com>:
>>>
 I’ll agree with Leif, having a timetable relation per stop is
 better.


 Yes Leif, there can be a delay expressed in minutes instead of an
 arrival-departure pair of time.

 Julien « djakk »



 Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
 écrit :

> In order to reduce the length of the value of the departures= tag,
> should we allow this kind of abstraction level : departures=5:35 ; 
> 6:35 ;
> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 15:41, djakk djakk 
> a écrit :
>
>> Martin, maybe locals do know their bus stop timetable, as they
>> always use the service they may memorize the schedules ... ?
>>
>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Almost that ! Sometimes bus stops does not have their official timetable,
the user have to refer to the closest previous bus stop having an official
timetable. So this kind of bus stop may not have a timetable in osm (except
an osm mapper really wants to put it into osm, knowing per habits the
schedule).


Julien « djakk »



Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :

> You mean per stop/route pair? That's an incredible s amount of relations!
> It seems to me that it would be a nighmare to try and maintain it that way.
> At first sight it seems simpler, but with the new proposal i came up with,
> you can see how the stops of a variation in itinerary tie together.
>
> If the vehicle remains in the station longer, the roles could become
> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
> the vehicle left at its first stop.
>
> Seeing the stops in the timetable relation in the order they are served
> also enables comparing this with the stops sequence in the route relation
> they refer to, adding additional possibilities for validation of the data.
>
> The stops in a timetable sequence should always be a subset of the stops
> in a route relation and appear in the same order.
>
> Polyglot
>
>
> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>
>> I’ll agree with Leif, having a timetable relation per stop is better.
>>
>>
>> Yes Leif, there can be a delay expressed in minutes instead of an
>> arrival-departure pair of time.
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>> écrit :
>>
>>> In order to reduce the length of the value of the departures= tag,
>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>> écrit :
>>>
 Martin, maybe locals do know their bus stop timetable, as they always
 use the service they may memorize the schedules ... ?

 Julien


 Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started
> creating a new one. It differs in rather important ways from your 
> proposal,
> so I preferred not modifying your wiki page. I also think it's important 
> to
> decouple the (voting for a) full timetable solution from the solution 
> where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured out
> yet is how to differ weekdays that fall in school holiday periods from
> "normal" weekdays. So work in progress.
>
> Polyglot
>
> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>
>> Polyglot:
>>
> I think that having a timetable relation for each stop is less
>> complicated than having one per route.  There are several advantages to
>> this:
>> 1) People can easily add a single relation at a time, rather than
>> having to do the entire line at one time.  This could make it much easier
>> to, for example, have a StreetComplete quest asking "What are the arrival
>> times of bus X at this bus stop?"  iD could also have a field at bus 
>> stops
>> with "arrivals for each parent bus route" that would allow people to
>> seamlessly create timetable relations.  It also makes more features
>> possible in the future, such as additional tags to each timetable.
>> 2) The system is easier for newbies to learn to use.
>>
>> The disadvantage is that there are now a ton of relations per bus /
>> train / subway route.  Creating these could made easier by a new JOSM
>> plugin.  Also, if someone wanted to delete all timetable relations that 
>> are
>> part of a route, they could simply use this overpass query to download 
>> the
>> data into JOSM and then delete all of the timetable relations:
>> https://overpass-turbo.eu/s/Dlf
>>
>> If people really prefer a single timetable relation for each route,
>> then I will go with that.
>>
>> Julien:
>> Why not have a "delay"="> at this platform>" tag instead of separate arrivals/departures tags?
>>
>> Thanks,
>> Leif Rasmussen
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>

___
Talk-transit mailing list
Talk-transit@openstreetmap.org

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

In which case a timetable per stop and per route is unmaintable ?

Julien “djakk”


Le mar. 6 nov. 2018 à 16:59, djakk djakk  a écrit :

> I think it is important to have an osm object describing the timetable
> user-oriented for simple editing without any tool.
> The mapper is at a bus stop, takes a picture of the timetable, can import
> it later in osm without the need of any extra tool.
> Validator can be inside a tool.
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a écrit :
>
>> Almost that ! Sometimes bus stops does not have their official timetable,
>> the user have to refer to the closest previous bus stop having an official
>> timetable. So this kind of bus stop may not have a timetable in osm (except
>> an osm mapper really wants to put it into osm, knowing per habits the
>> schedule).
>>
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>>
>>> You mean per stop/route pair? That's an incredible s amount of
>>> relations! It seems to me that it would be a nighmare to try and maintain
>>> it that way. At first sight it seems simpler, but with the new proposal i
>>> came up with, you can see how the stops of a variation in itinerary tie
>>> together.
>>>
>>> If the vehicle remains in the station longer, the roles could become
>>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>>> the vehicle left at its first stop.
>>>
>>> Seeing the stops in the timetable relation in the order they are served
>>> also enables comparing this with the stops sequence in the route relation
>>> they refer to, adding additional possibilities for validation of the data.
>>>
>>> The stops in a timetable sequence should always be a subset of the stops
>>> in a route relation and appear in the same order.
>>>
>>> Polyglot
>>>
>>>
>>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>>
 I’ll agree with Leif, having a timetable relation per stop is better.


 Yes Leif, there can be a delay expressed in minutes instead of an
 arrival-departure pair of time.

 Julien « djakk »



 Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
 écrit :

> In order to reduce the length of the value of the departures= tag,
> should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
> écrit :
>
>> Martin, maybe locals do know their bus stop timetable, as they always
>> use the service they may memorize the schedules ... ?
>>
>> Julien
>>
>>
>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>
>>> Hi Leif,
>>>
>>> You made me do it! :-) I sort of stole your proposal and started
>>> creating a new one. It differs in rather important ways from your 
>>> proposal,
>>> so I preferred not modifying your wiki page. I also think it's 
>>> important to
>>> decouple the (voting for a) full timetable solution from the solution 
>>> where
>>> tags are added to indicate interval during 'opening_hours' or a route,
>>> which is a lot more likely to be accepted.
>>>
>>> So here goes:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>
>>> Please let me know what you think. What I still haven't figured out
>>> yet is how to differ weekdays that fall in school holiday periods from
>>> "normal" weekdays. So work in progress.
>>>
>>> Polyglot
>>>
>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com
>>> >:
>>>
 Polyglot:

>>> I think that having a timetable relation for each stop is less
 complicated than having one per route.  There are several advantages to
 this:
 1) People can easily add a single relation at a time, rather than
 having to do the entire line at one time.  This could make it much 
 easier
 to, for example, have a StreetComplete quest asking "What are the 
 arrival
 times of bus X at this bus stop?"  iD could also have a field at bus 
 stops
 with "arrivals for each parent bus route" that would allow people to
 seamlessly create timetable relations.  It also makes more features
 possible in the future, such as additional tags to each timetable.
 2) The system is easier for newbies to learn to use.

 The disadvantage is that there are now a ton of relations per bus /
 train / subway route.  Creating these could made easier by a new JOSM
 plugin.  Also, if someone wanted to delete all timetable relations 
 that are
 part of a route, they could simply use this overpass query to download 
 the
 data into JOSM and then delete all of the timetable relations:
 https://overpass-turbo.eu/s/Dlf

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I don’t get it ...

With my point of view, one route with 15 stops has 15 timetables, each
timetable describes the arrival time and the departure time of several
trips at the stop.

There must be the same number of trips along the stops’ timetables.
(Otherwise this is an other route).

You mean, if somebody messed up and add an extra trip inside a timetable,
this would be hard to figure ?

Julien “djakk”


Le mar. 6 nov. 2018 à 18:30, Jo  a écrit :

> If you have a single one for a stop/route pair, no problem. As soon as you
> have a few hundred and the information in them starts to conflict with
> other another timetable relation for the same route it will be extremely
> hard to figure out where it went wrong.
>
> Polyglot
>
> Op di 6 nov. 2018 om 17:08 schreef djakk djakk :
>
>> In which case a timetable per stop and per route is unmaintable ?
>>
>> Julien “djakk”
>>
>>
>> Le mar. 6 nov. 2018 à 16:59, djakk djakk  a
>> écrit :
>>
>>> I think it is important to have an osm object describing the timetable
>>> user-oriented for simple editing without any tool.
>>> The mapper is at a bus stop, takes a picture of the timetable, can
>>> import it later in osm without the need of any extra tool.
>>> Validator can be inside a tool.
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:46, djakk djakk  a
>>> écrit :
>>>
 Almost that ! Sometimes bus stops does not have their official
 timetable, the user have to refer to the closest previous bus stop having
 an official timetable. So this kind of bus stop may not have a timetable in
 osm (except an osm mapper really wants to put it into osm, knowing per
 habits the schedule).


 Julien « djakk »



 Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :

> You mean per stop/route pair? That's an incredible s amount of
> relations! It seems to me that it would be a nighmare to try and maintain
> it that way. At first sight it seems simpler, but with the new proposal i
> came up with, you can see how the stops of a variation in itinerary tie
> together.
>
> If the vehicle remains in the station longer, the roles could become
> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
> the vehicle left at its first stop.
>
> Seeing the stops in the timetable relation in the order they are
> served also enables comparing this with the stops sequence in the route
> relation they refer to, adding additional possibilities for validation of
> the data.
>
> The stops in a timetable sequence should always be a subset of the
> stops in a route relation and appear in the same order.
>
> Polyglot
>
>
> Op di 6 nov. 2018 om 16:07 schreef djakk djakk  >:
>
>> I’ll agree with Leif, having a timetable relation per stop is better.
>>
>>
>> Yes Leif, there can be a delay expressed in minutes instead of an
>> arrival-departure pair of time.
>>
>> Julien « djakk »
>>
>>
>>
>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>> écrit :
>>
>>> In order to reduce the length of the value of the departures= tag,
>>> should we allow this kind of abstraction level : departures=5:35 ; 6:35 
>>> ;
>>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>>
>>> Julien « djakk »
>>>
>>>
>>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>>> écrit :
>>>
 Martin, maybe locals do know their bus stop timetable, as they
 always use the service they may memorize the schedules ... ?

 Julien


 Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started
> creating a new one. It differs in rather important ways from your 
> proposal,
> so I preferred not modifying your wiki page. I also think it's 
> important to
> decouple the (voting for a) full timetable solution from the solution 
> where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured
> out yet is how to differ weekdays that fall in school holiday periods 
> from
> "normal" weekdays. So work in progress.
>
> Polyglot
>
> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <
> 354...@gmail.com>:
>
>> Polyglot:
>>
> I think that having a timetable relation for each stop is less
>> complicated than having one per route.  There are several advantages 
>> to
>> this:
>> 1) People can easily add a single 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I think it is important to have an osm object describing the timetable
user-oriented for simple editing without any tool.
The mapper is at a bus stop, takes a picture of the timetable, can import
it later in osm without the need of any extra tool.
Validator can be inside a tool.

Julien « djakk »


Le mar. 6 nov. 2018 à 16:46, djakk djakk  a écrit :

> Almost that ! Sometimes bus stops does not have their official timetable,
> the user have to refer to the closest previous bus stop having an official
> timetable. So this kind of bus stop may not have a timetable in osm (except
> an osm mapper really wants to put it into osm, knowing per habits the
> schedule).
>
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:28, Jo  a écrit :
>
>> You mean per stop/route pair? That's an incredible s amount of relations!
>> It seems to me that it would be a nighmare to try and maintain it that way.
>> At first sight it seems simpler, but with the new proposal i came up with,
>> you can see how the stops of a variation in itinerary tie together.
>>
>> If the vehicle remains in the station longer, the roles could become
>> 00:30-00:35 instead of simply 00:35 for the departure offset to the time
>> the vehicle left at its first stop.
>>
>> Seeing the stops in the timetable relation in the order they are served
>> also enables comparing this with the stops sequence in the route relation
>> they refer to, adding additional possibilities for validation of the data.
>>
>> The stops in a timetable sequence should always be a subset of the stops
>> in a route relation and appear in the same order.
>>
>> Polyglot
>>
>>
>> Op di 6 nov. 2018 om 16:07 schreef djakk djakk :
>>
>>> I’ll agree with Leif, having a timetable relation per stop is better.
>>>
>>>
>>> Yes Leif, there can be a delay expressed in minutes instead of an
>>> arrival-departure pair of time.
>>>
>>> Julien « djakk »
>>>
>>>
>>>
>>> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a
>>> écrit :
>>>
 In order to reduce the length of the value of the departures= tag,
 should we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
 [7-19]:[05;35] ; 20:35 ; 21:35  ?

 Julien « djakk »


 Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
 écrit :

> Martin, maybe locals do know their bus stop timetable, as they always
> use the service they may memorize the schedules ... ?
>
> Julien
>
>
> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started
>> creating a new one. It differs in rather important ways from your 
>> proposal,
>> so I preferred not modifying your wiki page. I also think it's important 
>> to
>> decouple the (voting for a) full timetable solution from the solution 
>> where
>> tags are added to indicate interval during 'opening_hours' or a route,
>> which is a lot more likely to be accepted.
>>
>> So here goes:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> Please let me know what you think. What I still haven't figured out
>> yet is how to differ weekdays that fall in school holiday periods from
>> "normal" weekdays. So work in progress.
>>
>> Polyglot
>>
>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>
>>> Polyglot:
>>>
>> I think that having a timetable relation for each stop is less
>>> complicated than having one per route.  There are several advantages to
>>> this:
>>> 1) People can easily add a single relation at a time, rather than
>>> having to do the entire line at one time.  This could make it much 
>>> easier
>>> to, for example, have a StreetComplete quest asking "What are the 
>>> arrival
>>> times of bus X at this bus stop?"  iD could also have a field at bus 
>>> stops
>>> with "arrivals for each parent bus route" that would allow people to
>>> seamlessly create timetable relations.  It also makes more features
>>> possible in the future, such as additional tags to each timetable.
>>> 2) The system is easier for newbies to learn to use.
>>>
>>> The disadvantage is that there are now a ton of relations per bus /
>>> train / subway route.  Creating these could made easier by a new JOSM
>>> plugin.  Also, if someone wanted to delete all timetable relations that 
>>> are
>>> part of a route, they could simply use this overpass query to download 
>>> the
>>> data into JOSM and then delete all of the timetable relations:
>>> https://overpass-turbo.eu/s/Dlf
>>>
>>> If people really prefer a single timetable relation for each route,
>>> then I will go with that.
>>>
>>> Julien:
>>> Why not have a "delay"=">> departure at this platform>" tag instead of separate arrivals/departures
>>> tags?
>>>
>>> 

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

Martin, maybe locals do know their bus stop timetable, as they always use
the service they may memorize the schedules ... ?

Julien


Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :

> Hi Leif,
>
> You made me do it! :-) I sort of stole your proposal and started creating
> a new one. It differs in rather important ways from your proposal, so I
> preferred not modifying your wiki page. I also think it's important to
> decouple the (voting for a) full timetable solution from the solution where
> tags are added to indicate interval during 'opening_hours' or a route,
> which is a lot more likely to be accepted.
>
> So here goes:
>
> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>
> Please let me know what you think. What I still haven't figured out yet is
> how to differ weekdays that fall in school holiday periods from "normal"
> weekdays. So work in progress.
>
> Polyglot
>
> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>
>> Polyglot:
>>
> I think that having a timetable relation for each stop is less complicated
>> than having one per route.  There are several advantages to this:
>> 1) People can easily add a single relation at a time, rather than having
>> to do the entire line at one time.  This could make it much easier to, for
>> example, have a StreetComplete quest asking "What are the arrival times of
>> bus X at this bus stop?"  iD could also have a field at bus stops with
>> "arrivals for each parent bus route" that would allow people to seamlessly
>> create timetable relations.  It also makes more features possible in the
>> future, such as additional tags to each timetable.
>> 2) The system is easier for newbies to learn to use.
>>
>> The disadvantage is that there are now a ton of relations per bus / train
>> / subway route.  Creating these could made easier by a new JOSM plugin.
>> Also, if someone wanted to delete all timetable relations that are part of
>> a route, they could simply use this overpass query to download the data
>> into JOSM and then delete all of the timetable relations:
>> https://overpass-turbo.eu/s/Dlf
>>
>> If people really prefer a single timetable relation for each route, then
>> I will go with that.
>>
>> Julien:
>> Why not have a "delay"="> this platform>" tag instead of separate arrivals/departures tags?
>>
>> Thanks,
>> Leif Rasmussen
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

... and/or an abbreviation with the frequency : departures=5:15 - 1:25
every 1:30 ~ 3 minutes
(This is for Rennes’ subway line)

Julien « djakk »


Le mar. 6 nov. 2018 à 16:07, djakk djakk  a écrit :

> I’ll agree with Leif, having a timetable relation per stop is better.
>
>
> Yes Leif, there can be a delay expressed in minutes instead of an
> arrival-departure pair of time.
>
> Julien « djakk »
>
>
>
> Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :
>
>> In order to reduce the length of the value of the departures= tag, should
>> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
>> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>>
>> Julien « djakk »
>>
>>
>> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a
>> écrit :
>>
>>> Martin, maybe locals do know their bus stop timetable, as they always
>>> use the service they may memorize the schedules ... ?
>>>
>>> Julien
>>>
>>>
>>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>>
 Hi Leif,

 You made me do it! :-) I sort of stole your proposal and started
 creating a new one. It differs in rather important ways from your proposal,
 so I preferred not modifying your wiki page. I also think it's important to
 decouple the (voting for a) full timetable solution from the solution where
 tags are added to indicate interval during 'opening_hours' or a route,
 which is a lot more likely to be accepted.

 So here goes:

 https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables

 Please let me know what you think. What I still haven't figured out yet
 is how to differ weekdays that fall in school holiday periods from "normal"
 weekdays. So work in progress.

 Polyglot

 Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:

> Polyglot:
>
 I think that having a timetable relation for each stop is less
> complicated than having one per route.  There are several advantages to
> this:
> 1) People can easily add a single relation at a time, rather than
> having to do the entire line at one time.  This could make it much easier
> to, for example, have a StreetComplete quest asking "What are the arrival
> times of bus X at this bus stop?"  iD could also have a field at bus stops
> with "arrivals for each parent bus route" that would allow people to
> seamlessly create timetable relations.  It also makes more features
> possible in the future, such as additional tags to each timetable.
> 2) The system is easier for newbies to learn to use.
>
> The disadvantage is that there are now a ton of relations per bus /
> train / subway route.  Creating these could made easier by a new JOSM
> plugin.  Also, if someone wanted to delete all timetable relations that 
> are
> part of a route, they could simply use this overpass query to download the
> data into JOSM and then delete all of the timetable relations:
> https://overpass-turbo.eu/s/Dlf
>
> If people really prefer a single timetable relation for each route,
> then I will go with that.
>
> Julien:
> Why not have a "delay"=" at this platform>" tag instead of separate arrivals/departures tags?
>
> Thanks,
> Leif Rasmussen
> ___
> Tagging mailing list
> tagg...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
 ___
 Tagging mailing list
 tagg...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

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

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

In order to reduce the length of the value of the departures= tag, should
we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
[7-19]:[05;35] ; 20:35 ; 21:35  ?

Julien « djakk »


Le mar. 6 nov. 2018 à 15:41, djakk djakk  a écrit :

> Martin, maybe locals do know their bus stop timetable, as they always use
> the service they may memorize the schedules ... ?
>
> Julien
>
>
> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>
>> Hi Leif,
>>
>> You made me do it! :-) I sort of stole your proposal and started creating
>> a new one. It differs in rather important ways from your proposal, so I
>> preferred not modifying your wiki page. I also think it's important to
>> decouple the (voting for a) full timetable solution from the solution where
>> tags are added to indicate interval during 'opening_hours' or a route,
>> which is a lot more likely to be accepted.
>>
>> So here goes:
>>
>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>
>> Please let me know what you think. What I still haven't figured out yet
>> is how to differ weekdays that fall in school holiday periods from "normal"
>> weekdays. So work in progress.
>>
>> Polyglot
>>
>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>
>>> Polyglot:
>>>
>> I think that having a timetable relation for each stop is less
>>> complicated than having one per route.  There are several advantages to
>>> this:
>>> 1) People can easily add a single relation at a time, rather than having
>>> to do the entire line at one time.  This could make it much easier to, for
>>> example, have a StreetComplete quest asking "What are the arrival times of
>>> bus X at this bus stop?"  iD could also have a field at bus stops with
>>> "arrivals for each parent bus route" that would allow people to seamlessly
>>> create timetable relations.  It also makes more features possible in the
>>> future, such as additional tags to each timetable.
>>> 2) The system is easier for newbies to learn to use.
>>>
>>> The disadvantage is that there are now a ton of relations per bus /
>>> train / subway route.  Creating these could made easier by a new JOSM
>>> plugin.  Also, if someone wanted to delete all timetable relations that are
>>> part of a route, they could simply use this overpass query to download the
>>> data into JOSM and then delete all of the timetable relations:
>>> https://overpass-turbo.eu/s/Dlf
>>>
>>> If people really prefer a single timetable relation for each route, then
>>> I will go with that.
>>>
>>> Julien:
>>> Why not have a "delay"=">> this platform>" tag instead of separate arrivals/departures tags?
>>>
>>> Thanks,
>>> Leif Rasmussen
>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>> ___
>> Tagging mailing list
>> tagg...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-transit] [Tagging] Public Transport Timetables

[djakk djakk]

I’ll agree with Leif, having a timetable relation per stop is better.


Yes Leif, there can be a delay expressed in minutes instead of an
arrival-departure pair of time.

Julien « djakk »



Le mar. 6 nov. 2018 à 16:04, djakk djakk  a écrit :

> In order to reduce the length of the value of the departures= tag, should
> we allow this kind of abstraction level : departures=5:35 ; 6:35 ;
> [7-19]:[05;35] ; 20:35 ; 21:35  ?
>
> Julien « djakk »
>
>
> Le mar. 6 nov. 2018 à 15:41, djakk djakk  a écrit :
>
>> Martin, maybe locals do know their bus stop timetable, as they always use
>> the service they may memorize the schedules ... ?
>>
>> Julien
>>
>>
>> Le lun. 5 nov. 2018 à 17:08, Jo  a écrit :
>>
>>> Hi Leif,
>>>
>>> You made me do it! :-) I sort of stole your proposal and started
>>> creating a new one. It differs in rather important ways from your proposal,
>>> so I preferred not modifying your wiki page. I also think it's important to
>>> decouple the (voting for a) full timetable solution from the solution where
>>> tags are added to indicate interval during 'opening_hours' or a route,
>>> which is a lot more likely to be accepted.
>>>
>>> So here goes:
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/Public_transport_timetables
>>>
>>> Please let me know what you think. What I still haven't figured out yet
>>> is how to differ weekdays that fall in school holiday periods from "normal"
>>> weekdays. So work in progress.
>>>
>>> Polyglot
>>>
>>> Op za 3 nov. 2018 om 16:25 schreef Leif Rasmussen <354...@gmail.com>:
>>>
 Polyglot:

>>> I think that having a timetable relation for each stop is less
 complicated than having one per route.  There are several advantages to
 this:
 1) People can easily add a single relation at a time, rather than
 having to do the entire line at one time.  This could make it much easier
 to, for example, have a StreetComplete quest asking "What are the arrival
 times of bus X at this bus stop?"  iD could also have a field at bus stops
 with "arrivals for each parent bus route" that would allow people to
 seamlessly create timetable relations.  It also makes more features
 possible in the future, such as additional tags to each timetable.
 2) The system is easier for newbies to learn to use.

 The disadvantage is that there are now a ton of relations per bus /
 train / subway route.  Creating these could made easier by a new JOSM
 plugin.  Also, if someone wanted to delete all timetable relations that are
 part of a route, they could simply use this overpass query to download the
 data into JOSM and then delete all of the timetable relations:
 https://overpass-turbo.eu/s/Dlf

 If people really prefer a single timetable relation for each route,
 then I will go with that.

 Julien:
 Why not have a "delay"=">>> at this platform>" tag instead of separate arrivals/departures tags?

 Thanks,
 Leif Rasmussen
 ___
 Tagging mailing list
 tagg...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/tagging

>>> ___
>>> Tagging mailing list
>>> tagg...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/tagging
>>>
>>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

[Talk-cz] mapathon olomouc 12.12.2018

[anthaas]

Ahoj,

12. 12. 2018 budeme v Olomouci pořádat další mapathon.

Více info na fb události https://www.facebook.com/events/505257333218273/

--
s pozdravem
bass Antonin Haas


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

Re: [Talk-it] tracciamo il futuro di OpenStreetMap in Italia?

[Aury88]

Laurentius wrote
> Non so se hai visto ma in alcune voci c'è, ad esempio:
> https://it.wikipedia.org/wiki/Civico_Planetario_Ulrico_Hoepli
> 
> È abbastanza facile inserirla, basta modificare i diversi template per
> mostrarla; il sotto-template da utilizzare è questo:
> https://it.wikipedia.org/wiki/Template:Mappa_OSM

 Ciao Lorenzo,

si, sapevo dell'esistenza di un template per la visualizzazione della mappa
(anche se, non sapendo il nome, non sono riuscito a linkarlo qui, quindi ti
ringrazio per averlo fatto tu) la mia proposta era appunto integrare la
possibilità di visualizzare una mappa nei template di elementi
"georeferenziabili" che ancora ne sono privi,tipo questo[1], ma che già
richiedono le coordinate geografiche (c'è un modo per sapere quali template
richiedono le coordinate e quanti di essi non fanno visualizzare la mappa?).
Con il solo esempio del template dedicato alle suddivisioni amministrative,
il fatto che questo non abbia integrata la mappa, determina (ripeto
considerando quel solo template) la mancata visualizzazione della mappa OSM
in migliaia di voci WP il che è un vero peccato.
io non saprei dove e come modificare il template. e penso non sia un lavoro
che possa fare chiunque giusto? immagino servano  autorizzazioni apposite.

[1]https://it.wikipedia.org/wiki/Template:Divisione_amministrativa

> Sullo stesso tema, come dicevo in un'altra mail, sarebbe molto utile
> modificare il template Coord (che è quello che inserisce il link alle
> coordinate in alto a destra) per utilizzare la nuova estensione per le
> mappe (quindi il tag 
> 
> ), che è la stessa usata (con il tag
> 
> ) nell'esempio di sopra. Questo è più complicato perché ci sono
> molti più casi speciali da considerare (e ci sono da escludere i casi
> in cui sono usate mappe di altri corpi celesti), ma una volta fatto si
> applica a tutte le 300.000 voci circa che lo usano.

su questo punto sono abbastanza ignorante. avevo capito che fosse
consigliato l'uso di wikidata per l'inserimento delle coordinate in maniera
tale che venisero usate automaticamente dalle voci su WP nelle varie lingue
così come dagli altri progetti wiki*... speravo che a quel punto i template
nelle voci WP pescassero direttamente da WD o che bastasse linkare
all'apposita voce WD non ho ancora capito qual'è la metodologia
ufficiale.  



-
Ciao,
Aury
--
Sent from: http://gis.19327.n8.nabble.com/Italy-General-f5324174.html

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

[Talk-es] semanarioOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Hola, el semanario Nº 433, 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/10913/

¡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

[Talk-ko] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

매주 일어나는 OSM 소식을 종합한, 433번째 주간OSM이 발행되었습니다.

http://www.weeklyosm.eu/ko/archives/10913/

읽어 주셔서 감사합니다!

주간OSM이란? 
누가?: https://wiki.openstreetmap.org/wiki/WeeklyOSM#Available_Languages 
어디서?: 
https://umap.openstreetmap.fr/en/map/weeklyosm-is-currently-produced-in_56718#2/8.6/108.3
___
Talk-ko mailing list
Talk-ko@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ko

[Talk-cl] semanarioOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Hola, el semanario Nº 433, 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/10913/

¡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

[talk-latam] semanarioOSM Nº 433 2018-10-30-2018-11-05

[theweekly . osm]

Hola, el semanario Nº 433, 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/10913/

¡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

[OSM-talk] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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-ca] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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-us] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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-GB] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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

[OSM-talk-ie] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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-in] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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-ph] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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

[Talk-africa] weeklyOSM #433 2018-10-30-2018-11-05

[weeklyteam]

The weekly round-up of OSM news, issue # 433,
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/10913/

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: [Talk-in] Understanding "unprojection"

[Aruna S]

Sorry, to come to your other questions:

> I haven't published this script online because I'm afraid it'll get used
recklessly and cause excess load on the target tile server.It generates a
Z/X/Y URL list of tiles at multiple zoom levels. Then I used a download
manager to download the tiles with some time gap (so I don't trigger a
server lockout), with z/x/ folder paths maintained.

A python library does this, where it takes a bounding box and a zoom, and
generates z/x/y at zooms for the bounding box. Is your script doing
something different from this?

Warmly,
Aruna
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in