date:20200802

sent from a phone

> On 2. Aug 2020, at 18:11, Guillaume Rischard  wrote:
> 
> As someone who’s listed as having used 9 different editors on 
> https://hdyc.neis-one.org/?Stereo (including “unknown”), I know how important 
> the variety and richness of editing possibilities is.

agreed. Admittedly the stats look pretty bad, user numbers have been dropping 
constantly since 2012, in 2015 there were 24000 PL2 users, 2016: 14700, 2017 
1, 2018 6400, 2019 4900 and 2020 only 2500 so far, but I am willing to 
believe that these are mostly long term and hardcore contributors, and 2500 is 
no big money for the OpenStreetMap-Foundation, so it may be worth the effort. 
At least you can be sure that in  these 9,7 million edits no imports are hiding 
;-) and this number makes it 4th for performed edits.

Cheers Martin 

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Joseph Eisenberg

While the benefit of making Potlatch 2 on AIR is small, the cost is tiny.

2500 Euros is an insignificant price to pay for supporting an editor which
is still used by a couple of thousand long-term users.

I support this expenditure.

– Joseph Eisenberg

On Sun, Aug 2, 2020 at 10:05 AM Alexandre Oliveira 
wrote:

> I'd like to share my two cents on the matter of supporting Potlatch 2,
> an editor built with (now) dead technology.
>
> I don't think it's worth spending money to update P2 to Air. As others
> have stated, Air has been discontinued as well, and it was developed
> by Adobe, probably with the same amount of security flaws as Flash
> had, which contributed to its demise. I don't see Air as different
> even though it's being maintained now by Samsung.
>
> Just take a look. The web is different than when P2 released; flash is
> deprecated and a synonym for vulnerable systems, Air tried to take off
> but now it's just another dead technology. What are the benefits of
> porting P2 to Air? It may be easier because Air may share some code
> with Flash, which in turn makes it easier to port to.
>
> However, I think that the OSMF should find someone familiar with Flash
> and look forward to porting P2 to modern web technologies (please not
> Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
> CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
> web tech, it doesn't matter. I think it's going to be money well spent
> if P2 was ported to a supported web technology and not something that
> died a few years ago and is on life support, and barely anyone uses it
> nowadays.
>
> IMO porting P2 to Air is just a waste of money and time from the
> developer, and we will reach the same point in the future, be it
> either for deprecating P2 or looking to port it to newer web
> technologies. OSMF should prepare for the future and not continue
> using deprecated technology.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2



sent from a phone

> On 3. Aug 2020, at 00:09, Andy Townsend  wrote:
> 
>> I guess this is about not handling symbols?
> 
> 
> Not really - see 
> https://help.openstreetmap.org/questions/6368/in-josm-is-it-possible-to-see-gpx-track-waypoint-details
>  for information.


the second answer suggests it is configurable: “ Waypoit labeling can be 
customized in the JOSM Preferences -> Display Settings -> GPS Points -> Waypoit 
labeling (the page which directly opens, when you open the preference window).”

The answers also suggest that displaying an icon is already implemented, but 
there may be few icons available (missing artwork for many symbols)

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Andy Townsend


On 02/08/2020 22:52, Martin Koppenhoefer wrote:



sent from a phone


On 2. Aug 2020, at 17:09, Andy Townsend  wrote:

GPX track waypoint handling is the biggest missing piece of 
functionality for me, so you can start with that one if you wish



I guess this is about not handling symbols?


Not really - see 
https://help.openstreetmap.org/questions/6368/in-josm-is-it-possible-to-see-gpx-track-waypoint-details 
for information.


If there's a better answer available now (which is entirely possible - I 
asked that question 9 years ago!) then I'd suggest adding it at that 
help question.  See also 
https://help.openstreetmap.org/questions/7675/josm-is-it-possible-to-convert-an-individual-waypoint-in-a-gpx-file-to-a-node 
which is somewhat similar.


Best Regards,

Andy



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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione 80hnhtv4agou--- via Talk-transit

sent from a phone

> On 2. Aug 2020, at 17:09, Andy Townsend  wrote:
> 
> GPX track waypoint handling is the biggest missing piece of functionality for 
> me, so you can start with that one if you wish

I guess this is about not handling symbols? Because Josm does show waypoints 
and their names. Did you try to open an issue in the josm trac? It seems a 
reasonable problem and the solution seems easy to implement as well (at least 
concetenating the sym value to the name could probably be done in 5 minutes by 
someone who knows the josm code, if you want actual symbols it could be more 
work to find suitable artwork of course, assuming that the garmin symbols are 
copyrighted).
There’s also a visual c program that I used in 2008 on windows to do this, it 
is still around (and maybe can be used with mono?), source code is also 
available, sym2name
http://www.dimitri-junker.de/html/body_openstreetmap.html#sym2name

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

Re: [talk-cz] Maproullete Challenge - Czech Republic villages - Add wikipedia TAG

2020-08-02 Per discussione Jan Macura

Ahoj,

dík za oživení. Už se vyřešilo, zda cpát wikipedia:*=? a wikidata=? tagy do
uzlů, do relací nebo do obého? Viz https://openstreetmap.cz/talkcz/c3024 .

Jinak za mě osobně wikipedia:*=? vůbec nepoužívat a přidávat jen wikidata=?.

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

Re: [OSM-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione Guillaume Rischard

Bryan Housel hasn’t been the iD maintainer for a few weeks now.

You can find the discussion on the OSMF board’s proposal to resolve 
controversies related to iD at 
https://lists.openstreetmap.org/pipermail/osmf-talk/2020-June/006865.html 
.

Guillaume

> On 2 Aug 2020, at 19:52, Tomas Straupis  wrote:
> 
> Will this mean that iD would adhere to de facto situation as well as wiki 
> info and stop lying that original water schema is "deprecated" and 
> authoritarian coder Brian will be removed from decision making and 
> communication?
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione Romain MEHUT

Les hésitations ont trop duré, c'est souvent le problème dans OSM, on n'ose pas 
toujours pour ne pas froisser des susceptibilités. Je n'ai rien contre le tag 
boundary=urban, c'est juste que dans le cas présent, son emploi s'est fait sans 
tenir compte des données déjà présentes...



Romain


De : osm.sanspourr...@spamgourmet.com
À : talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?
Date : 02/08/2020 22:44:54 Europe/Paris

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

Si tu ne veux travailler que sur les versions 1, hormis afficher les numéros de 
version et filtrer après via un tableur ou un simple sed je ne vois pas : 
["::version"=1] ne marche pas.

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

> Et est-ce que le contributeur a été informé des échanges sur talk-fr ?

S'il n'est pas au courant il va rapidement demander à rom1 pourquoi il a tout 
cassé^^.

Pas idéal mais tu pourra toujours t'excuser.

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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione Romain MEHUT

Bonsoir,



Oui c'est beaucoup mais ce serait pourtant un moindre mal. Ces traffic_sign 
n'ont pas été créés conformément à la définition du wiki 
https://wiki.openstreetmap.org/wiki/FR:Tag:traffic_sign%3Dcity_limit soit un 
nœud sur la route. Pour les autres nœuds avec des versions ultérieures, il 
faudrait justement s'assurer qu'ils sont conformes au wiki.



Romain


De : Éric Gillet 
À : talk-fr@openstreetmap.org
Sujet : Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?
Date : 02/08/2020 22:23:45 Europe/Paris

Le 02/08/2020 à 15:07, rme...@openstreetmap.fr a écrit :
> J'aimerais également supprimer les traffic_sign=city_limit créés par le 
> contributeur à l'origine des polygones mais uniquement ceux restés en version 
> 1. Comment faire cette distinction dans overpass turbo ?

Exemple :

node[traffic_sign=city_limit](if: version() == 1)(user: "osm-operon");
out;

https://overpass-turbo.eu/s/WGA

Ça représente tout de même environ 3500 nœuds. Sont-ils vraiment à enlever ?


___
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: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione osm . sanspourriel


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


Si tu ne veux travailler que sur les versions 1, hormis afficher les
numéros de version et filtrer après via un tableur ou un simple sed je
ne vois pas : ["::version"=1] ne marche pas.

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

> Et est-ce que le contributeur a été informé des échanges sur talk-fr ?

S'il n'est pas au courant il va rapidement demander à rom1 pourquoi il a
tout cassé^^.

Pas idéal mais tu pourra toujours t'excuser.


Le 02/08/2020 à 15:07, rme...@openstreetmap.fr a écrit :

Bonjour,

Pour info, j'ai supprimé tous les polygones boundary=urban sur la France 
métropolitaine. J'aimerais également supprimer les traffic_sign=city_limit 
créés par le contributeur à l'origine des polygones mais uniquement ceux restés 
en version 1. Comment faire cette distinction dans overpass turbo ?



Romain


Bonjour,

Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
abominations que nous avions patiemment supprimées au cours de ces derniers
mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
https://www.openstreetmap.org/changeset/87258927?way_page=3 par exemple).
La méthode est toujours la même que celle pointée par Christian R il y a un
an et demi : tracé approximatif (il passe allègrement à travers des
quartiers d'habitation, voire des maisons), chevauchement de ses polygones,
absence de fondement administratif alors qu'il les range dans un
"admin_level", pas de concertation avec les locaux.
À cette liste, il faut ajouter que des appli comme OSMand fait apparaître
ces limites avec la même symbologie que les vraies limites communales, ce
qui rend la carte particulièrement illisible dans certains cas.

Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il
faudrait sans doute trouver une solution plus efficace pour traiter ce
problème.

Bonne journée,

P-Y

_
Sent from http://gis.19327.n8.nabble.com


___
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: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione Éric Gillet


Le 02/08/2020 à 15:07, rme...@openstreetmap.fr a écrit :

J'aimerais également supprimer les traffic_sign=city_limit créés par le 
contributeur à l'origine des polygones mais uniquement ceux restés en version 
1. Comment faire cette distinction dans overpass turbo ?


Exemple :

node[traffic_sign=city_limit](if: version() == 1)(user: "osm-operon");
out;

https://overpass-turbo.eu/s/WGA

Ça représente tout de même environ 3500 nœuds. Sont-ils vraiment à enlever ?


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Mateusz Konieczny via talk


And 2021 will be year of Linux on desktop.
More seriously, maybe in long run 
Windows will fall and Linux will survive
but it is not happening in any near future.
2 Aug 2020, 16:41 by talk@openstreetmap.org:

> Also Linux is the future. Every application that cannot run under Linux will 
> fail in the long run. Remember that Windows shouldn't be the main target 
> platform anymore because it is dying and the society is to blame that they 
> don't get it.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-pt] key capital= (Padronização das localidades)

2020-08-02 Per discussione António Madeira

gt; de alguma forma, chegar a um consenso sobre o melhor padrão a usar em
> Portugal para a tag place=*.
>
> Neste momento, segundo a wiki, o padrão a usar é este:
> https://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png
>
> Este padrão, no entanto, não está a ser usado de maneira uniforme nas
> edições que os contribuidores têm feito.
> Em geral, a dúvida mais comum é como aglomerar 5 conceitos diferentes
> (capital de distrito/sede de município/cidade/vila/freguesia) em 3 tags
> possíveis (city/town/village).
> Neste momento e, segundo a wiki, a tag "city" está reservada a
capitais de
> distrito, a tag "town" a todas as sedes de município, cidades e
vilas, e a
> tag "village" a freguesias ou sedes de município que não sejam pelo
menos
> vila (não conheço nenhum caso).
>
> Actualmente esta regra, se aplicada à risca, cria alguns casos
caricatos.
> É fácil encontrar casos no Grande Porto e Grande Lisboa em que uma
cidade
> tenha várias freguesias que são elas próprias cidades ou vilas. Num
exemplo
> prático, a cidade de Vila Nova de Gaia partilhará a tag town com mais de
> uma mão cheia de freguesias do seu concelho, o que a nível de
renderização
> pode trazer problemas - em zooms mais baixos/distantes Vila Nova de
Gaia,
> apesar de cidade e sede de concelho, poderá desaparecer em favor de uma
> freguesia sua que seja vila.
>
> O que proponho é uma alteração à regra existente, de forma à divisão ser
> esta:
>
> Capital de Distrito? -> place = city
> Cidade ou Capital Administrativa de Município? -> place = town
> Vila ou Capital Administrativa de Freguesia (não urbana)? -> place =
> village
> Capital Administrativa de Freguesia (urbana)? -> place = neighbourhood
>
> Esta mudança efectivamente cria distinções entre cidades e vilas, ao
mesmo
> tempo que preserva uma hierarquia em termos de divisões administrativas,
> sem criar casos caricatos como o acima descrito.
>
> Numa nota final, questiono se fará sentido despromover todas as sedes de
> freguesia para place=neighbourhood, por uma questão lógica. Não
incluí essa
> distinção no caso acima, incluindo apenas as freguesias urbanas
nessa tag,
> porque no contexto nacional a maioria das sedes de freguesia rurais têm
> efectivamente a identidade e contexto histórico de um povoado
distinto, ao
> contrário da maioria (e aqui podemos argumentar) das sedes de freguesia
> urbanas, que são historicamente vistas como sendo parte integrante da
> cidade a que pertencem.
>
> Agradeço desde já a vossa participação nesta discussão, pois é
necessário
> chegar a alguma conclusão neste tema, que já foi debatido várias vezes.
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


--
Alexandre Moleiro
  alexandre.mole...@gmail.com
-- next part --
An HTML attachment was scrubbed...
URL:
<http://lists.openstreetmap.org/pipermail/talk-pt/attachments/20200802/ad186ac3/attachment-0001.htm>

--

Subject: Digest Footer

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


--

End of Talk-pt Digest, Vol 127, Issue 1
***


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


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

Re: [OSM-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione Tomas Straupis

Will this mean that iD would adhere to de facto situation as well as wiki
info and stop lying that original water schema is "deprecated" and
authoritarian coder Brian will be removed from decision making and
communication?
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Skyler Hawthorne

In the absence of other proposals, even splitting it among the other two would 
be a much better use, in my opinion.

--
Skyler


On Sun, Aug 2, 2020, at 13:27, Rory McCann wrote:
> On 02.08.20 01:03, Skyler Hawthorne wrote:
> > Sorry if this sounds harsh, but I think using any funds at all to 
> > continue support for a tool that 1% of editors use would be wasteful. 
> > Flash is, for all intents and purposes, a dead technology. This money is 
> > better spent on other uses.
> 
> What would you suggest?
> 
> Serious question. We're suggesting spending €2,500 on this. Where else 
> do you suggest spending €2,500 on?
> 
> Rory
> ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Suggestions welcome | Re: Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Rory McCann


On 02.08.20 01:03, Skyler Hawthorne wrote:
Sorry if this sounds harsh, but I think using any funds at all to 
continue support for a tool that 1% of editors use would be wasteful. 
Flash is, for all intents and purposes, a dead technology. This money is 
better spent on other uses.


What would you suggest?

Serious question. We're suggesting spending €2,500 on this. Where else 
do you suggest spending €2,500 on?


Rory

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

Re: [Talk-us] [OSM-talk] Tag:railway=stop

2020-08-02 Per discussione stevea

Please click on the "View History" link of the wiki page (upper right) to see 
the contributors to this wiki (there are ten).
You can click on their username links to contact them.
SteveA

> On Aug 2, 2020, at 8:25 AM, 80hnhtv4agou--- via talk  
> wrote:
> Did someone on this List, contribute to this Wiki.?
> https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop

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

Re: [OSM-talk] Tag:railway=stop

2020-08-02 Per discussione stevea

Please click on the "View History" link of the wiki page (upper right) to see 
the contributors to this wiki (there are ten).
You can click on their username links to contact them.
SteveA

> On Aug 2, 2020, at 8:25 AM, 80hnhtv4agou--- via talk  
> wrote:
> Did someone on this List, contribute to this Wiki.?
> https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Alexandre Oliveira

I'd like to share my two cents on the matter of supporting Potlatch 2,
an editor built with (now) dead technology.

I don't think it's worth spending money to update P2 to Air. As others
have stated, Air has been discontinued as well, and it was developed
by Adobe, probably with the same amount of security flaws as Flash
had, which contributed to its demise. I don't see Air as different
even though it's being maintained now by Samsung.

Just take a look. The web is different than when P2 released; flash is
deprecated and a synonym for vulnerable systems, Air tried to take off
but now it's just another dead technology. What are the benefits of
porting P2 to Air? It may be easier because Air may share some code
with Flash, which in turn makes it easier to port to.

However, I think that the OSMF should find someone familiar with Flash
and look forward to porting P2 to modern web technologies (please not
Electron!), like WebAssembly or Web 2.0. Be it JavaScript,
CoffeeScript or TypeScript, React, Angular, Vue.js or any other modern
web tech, it doesn't matter. I think it's going to be money well spent
if P2 was ported to a supported web technology and not something that
died a few years ago and is on life support, and barely anyone uses it
nowadays.

IMO porting P2 to Air is just a waste of money and time from the
developer, and we will reach the same point in the future, be it
either for deprecating P2 or looking to port it to newer web
technologies. OSMF should prepare for the future and not continue
using deprecated technology.

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Simon Poole


Am 02.08.2020 um 11:31 schrieb mmd:
> ...
> In a more mid-term, I really like to see a move away from such
> proprietary platforms to an editor that runs in a browser
> out-of-the-box. 

...

Don't we already have that?




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Guillaume Rischard

Hi Sören,

The OSMF would, of course, be open to supporting development on editors other 
than Potlatch, and on other pieces of our infrastructure. Remember that this is 
a pilot for three projects with three long-term trusted contributors, so we can 
humbly learn how to do this the right way.

As someone who’s listed as having used 9 different editors on 
https://hdyc.neis-one.org/?Stereo  
(including “unknown”), I know how important the variety and richness of editing 
possibilities is.

Guillaume

> On 1 Aug 2020, at 15:09, Sören Reinecke via talk  > wrote:
> 
> > Nonetheless, even if P2 didn't run on Linux, I'm not sure why this should 
> > be an issue for other users. No-one says Vespucci isn't sustainable because 
> > it doesn't run on iOS.
> 
> But Vespucci is not mentioned here by OSMF and I remember that Android is 
> following the principle of free, democracy, open source, competition (because 
> it's distribution like approach though Google as a say in it which apps are 
> installed by default and what can be done with the phone in terms of rooting 
> it. The distribution approach as an argument for priorizing support for 
> Android is therefore questionable) more than iOS does. And iOS restricts you 
> more than Android does.
> 
> Regards
> 
> Sören Reinecke alias Valor Naram
> 
> 
>  Original Message 
> Subject: Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, 
> osm2pgsql, Potlatch 2
> From: Richard Fairhurst 
> To: talk@openstreetmap.org 
> CC: 
> 
> 
> Sören Reinecke wrote:
> > So far as I understood Adobe dropped Linux support for its 
> > AIR plattform. If that is right, then I am in doubt that 
> > supporting the development of Potlatch 2 is not that in 
> > a sustainable manner.
> 
> AIR is not maintained by Adobe, but by Harman, a Samsung subsidiary. AIR for 
> Linux is still supported at version 2.6 but not updated 
> (https://airsdk.harman.com/faq ): Harman is 
> considering future updates. P2 will still run on 2.6 - there are explicit 
> workarounds in the code (e.g. in 
> net/systemeD/potlatch2/collections/Imagery.as) to ensure backward 
> compatibility.
> 
> Nonetheless, even if P2 didn't run on Linux, I'm not sure why this should be 
> an issue for other users. No-one says Vespucci isn't sustainable because it 
> doesn't run on iOS.
> 
> mmd wrote:
> > Why aren't we porting Potlatch2 to WebAssembly, then? 
> 
> I'm not sure who the "we" is in this question, but assuming you're not 
> volunteering yourself :), the difficult dependency with P2 is not 
> ActionScript 3 but the Flash runtime, i.e. the Flash and Flex APIs. There are 
> currently only two runtimes capable of running P2: Flash Player and AIR. 
> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle 
> ) and is under very active development, 
> but does not yet support AS3 or the Flash Player features that P2 needs. I 
> would anticipate that P2 will be able to run as WebAssembly when Ruffle 
> reaches feature parity with AIR 2.6.
> 
> Richard
> ___
> talk mailing list
> talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione Guillaume Rischard

To nip this one in the bud:

No one employed by Mapbox is currently working on iD. Quincy, the current iD 
maintainer and lead developer, doesn’t and has never worked for Mapbox. Mapbox 
won’t receive any funding from this.

Guillaume

> On 2 Aug 2020, at 14:50, JB  wrote:
> 
> So, with sarcasm (at least half-)on, and english not being my mothertongue: 
> the osm2pgsql/Nomatim/Potlatch grants were just Troyan horses to enable the 
> OSMF funding of (ex or not ex?) Mapbox developer, with contributors not 
> screaming too loudly? And explaining the iD conflict resolution process that 
> was proposed lately (and, surprise, accepted by Mapbox iD developers)?
> Much thanks to the iD developers for having kept long, trustful and peaceful 
> relationships with the community over the years of iD development.
> Just saying out loud what some people may or may not think, but would not 
> dare to write. It does not expect answers.
> JB.
> 
> Le 02/08/2020 à 13:44, Mikel Maron a écrit :
>> Hello
>> 
>> The OSMF board is working to make OSM's core software and infrastructure 
>> more stable and sustainable by supporting paid roles for priority needs, 
>> such as the Senior Site Reliability role 
>> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html), 
>> and the pilot to fund "OSM Infrastructure" projects 
>> (https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html).
>> 
>> As part of this focus, we want to organise coordinated funding to support 
>> continued maintenance and development of the iD editor, as iD's strong 
>> continuous development over the past several years has served the OSM 
>> community well. Quincy Morgan is iD's maintainer and lead developer. 
>> Unfortunately, full-time support of his work recently ended. He'd very much 
>> like to continue, and the OSMF Board wants to see that happen. He has 
>> written up this proposal 
>> (https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
>>  with his ideal plans for iD over the next year, along with notes about how 
>> he'll organise, grow the developer base, communicate, and set priorities, 
>> and make iD better. The final priorities for the year will be made in 
>> consultation with the community.
>> 
>> To help fund this project, as well as the SSRE role, we're looking at 
>> earmarked donations from companies, chapters and organisations. 
>> Administratively, we believe this is easier than other methods of pooled 
>> funding, as the OSMF is already in most companies' procurement systems, and 
>> it would limit paperwork to one contract for iD. Initial contract would be 
>> for 1 year, and that's what the OSMF would look to raise now.
>> 
>> With the OSMF holding the contract, the Board would take a key 
>> accountability role, reviewing work done on the contract and assessing 
>> progress on the plans Quincy develops for the project. Additionally, the 
>> OSMF is working in cooperation with Quincy to establish a formal appeal 
>> process 
>> (https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
>>  for the relatively rare community issues iD cannot resolve itself.
>> 
>> The OSMF would not see its role as a traditional "boss", instructing iD to 
>> focus on this or that feature. We would not be prescriptive about 
>> priorities. This does not mean work in a vacuum. Our expectation is that 
>> Quincy, in addition to following our hiring framework's principles for 
>> transparent service to the community, would regularly convene stakeholders 
>> from the community to share their priorities and feedback. Quincy would 
>> assess all priorities holistically as he decides on a workable plan for the 
>> project.
>> 
>> Over the course of the year, we'll evaluate and learn from how the 
>> arrangement is working for all, as we look towards year 2 and beyond. For 
>> future years, we are looking at developing an overall plan for long-term 
>> support for all parts of the OSMF infrastructure. We want to be able to 
>> offer similar support to other OSM editors. Our early focus on iD is to 
>> ensure continued development.
>> 
>> We want to find out what you, the OSM community, think. Do you have any 
>> feedback?
>> 
>> If you know of an organisation that might want to fund this, please feel 
>> free to ask them to contact the OSMF Board.
>> 
>> -Mikel, for the OSMF Board
>> 
>> * Mikel Maron * +14152835207 @mikel s:mikelmaron
>> 
>> ___
>> osmf-talk mailing list
>> osmf-t...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/osmf-talk
> 
> 
> 
> ___
> osmf-talk mailing list
> osmf-t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk


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

Re: [OSRM-talk] OSRM Decentralized

2020-08-02 Per discussione michael spreng

Hi Nikhil

Thank you for realizing this, nice demo.

I think an automatic narrowing down of available back ends after
entering start and end coordinates would be an important feature (and
consequently an extension is needed to the configuration file to include
polygons for the available routing area)

Cheers,
Michael

On 02.08.20 09:46, Nikhil VJ wrote:
> Hi Folks,
> 
> Here are easy docker recipes for deploying your own OSRM instance for
> any base area. And a live demo page where OSRM for different areas can
> be brought together.
> 
> https://osrm-decentralized.github.io/
> 
> 
> --
> Cheers,
> Nikhil VJ
> https://nikhilvj.co.in
> 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
> 

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Frederik Ramm

Hi,

On 8/2/20 14:51, pangoSE wrote:
> I never use nonfree software like flash so I never tried P2. What is so
> special about it? Is there something hindering adding that specialness
> (as a plugin perhaps) to JOSM?

Every single Potlatch user has probably been told 20 times that they
should be switching to JOSM because it is so much better. If they
haven't until now, they never will.

I'd recommend a pragmatic approach here. If we can spend EUR 2500 to
make life easier for those several thousand people using Potlatch
regularly, and most of them doing so because they want and not because
they have no other choice, then why not.

If you look for principles and symbolism, yes Potlatch currently
requires a non-free platform to run, but the OSMF trying to support a
multitude of editors rather than pick one and support only that is IMHO
a positive signal.

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

[OSM-talk] Tag:railway=stop

2020-08-02 Per discussione 80hnhtv4agou--- via talk


Did someone on this List, contribute to this Wiki.?
 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop
 
 ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[talk-cz] Maproullete Challenge - Czech Republic villages - Add wikipedia TAG

2020-08-02 Per discussione Petr Schönmann

Ahoj všem !
Kdysi jsem zakládal stránku
https://wiki.openstreetmap.org/wiki/Cs:%C4%8Cesko/Projekty_k_mapov%C3%A1n%C3%AD

Nedávno jsem si na to vzpoměl, a zkusil vytvořit Maproulette challenge,
který by pomohl s tímto taskem a něco nového v OSM jsem se naučil.

https://maproulette.org/browse/challenges/13963

Chtěl bych zpětné info jestli by jste něco doplnili. Aktuálně task není
veřejný. Až bychom si to odsouhlasili, tak bych to pustil do světa.
Asi bych udělal i video pro jistotu jak mapovat. Ale myslím že na úroveň
expert co jsem nastavil u obtížnosti by měl každý "expert" pochopit.
Nehledě na to že "expert" používá pravděpodobně JOSM a v něm plugin
wikipedia doinstalovat není potíž.

Zároveň bych rád věděl, zda máte nějaký nápad který by se v projekt do
maproullete dal přetavit. Pokud na to jde udělat overpass turbo dotaz tak
je to realizovatelné :)
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-us] Tag:railway=stop

2020-08-02 Per discussione 80hnhtv4agou--- via Talk-us


Did someone on this List, contribute to this Wiki.?
 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop
 
 ___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-transit] Tag:railway=stop


Did someone on this List, contribute to this Wiki.?
 
https://wiki.openstreetmap.org/wiki/Tag:railway%3Dstop
 
 ___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Colin Smale

On 2020-08-02 16:41, Sören Reinecke via talk wrote:

> Also Linux is the future. Every application that cannot run under Linux will 
> fail in the long run. Remember that Windows shouldn't be the main target 
> platform anymore because it is dying and the society is to blame that they 
> don't get it.

Linux is a big part of the future for server platforms, but in its pure
form it has lost the battle for the desktop. Windows and MacOS as
platforms capable of enterprise-level management are not going anywhere
soon. Don't ignore ChromeOS and Android for local "desktops" either -
both are Linux-based of course. 

The biggest dependencies should not be the OS but the runtime
frameworks. This world used to be java-based; these days .NET Core is a
viable competitor, as is Node.js. As a server-side application supplier,
if your product doesn't run in a container, it doesn't exist. Containers
basically mean Linux and Windows. Actual host OS is irrelevant - only
the container environment matters.___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Mike Nice

Air is not a zero security risk, but the exposure is much lower than the 
old days of Flash.


I hate the security problems that came from Flash, as well as almost 
anything from Adobe, but I think the premise of this project to improve 
maintainability is important.   Although not part of this proposed 
project, it is a gateway that could allow migration to an open standard 
in the future.



On 8/2/2020 9:49 AM, john whelan wrote:
If Air is proprietary and an Adobe product I strongly suggest avoiding 
it purely from a security point of view. Adobe does not have a good 
reputation in the security world. Comments certainly have been made 
about Flash.


I don't think we should be encouraging the installation of software 
that could cause problems for our mappers.





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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Andy Townsend


On 02/08/2020 15:41, Sören Reinecke via talk wrote:
Also Linux is the future. Every application that cannot run under 
Linux will fail in the long run. Remember that Windows shouldn't be 
the main target platform anymore because it is dying and the society 
is to blame that they don't get it.



That's crossed off "Poe's law" on my "mailing list bingo" card :)



On Sun, Aug 2, 2020, 08:54 pangoSE mailto:pang...@riseup.net>> wrote:


You did not present a single usecase that is not covered
already by one of the other free software editors so I'm
guessing you will have a hard time convincing your peers
to team up around yet another editor, but I might be wrong.

I can't speak for Richard, but over the years I've asked several "how do 
you do X in JOSM" questions - look for ones with JOSM in the title at 
https://help.openstreetmap.org/users/387/someoneelse .  Some of the 
things there were supported by JOSM when I asked (often it's just a 
question of knowing what plugin to install), some weren't when I asked 
but are now, and some still, as far as I am aware, can't be done yet.


If you believe that I'm wrong then please add the relevant information 
to the questions on the OSM help site explain how to do the things that 
I'm asking about (GPX track waypoint handling is the biggest missing 
piece of functionality for me, so you can start with that one if you wish).


Best Regards,

Andy



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

Re: [OSM-talk-fr] Parking fermé aux camping cars la nuit

2020-08-02 Per discussione Philippe Verdy

Le dim. 2 août 2020 à 11:27,  a écrit :

> Le 02/08/2020 à 10:45, Philippe Verdy - ver...@gmail.com a écrit :
>
> Sauf que "dusk" et "dawn" sont aussi mal documentés et supportés. Et donc
> pourquoi pas simplement "@night" au lieu des deux mots "@(dusk-dawn)" ?
>
> Parce que c'est ce qui est documenté ! Mais je suis d'accord, ça aurait pu
> être plus simple sauf que "dusk" et "dawn" sont des limites utilisées.
>
> https://taginfo.openstreetmap.org/search?q=dusk#values
>
> Alors qu'on a plus de 50 000 dusk/dawn on n'a que :
> 118
> traffic_signals:operating_times
> 
> off @ *night*
> 
>
> Supposons que l'interdiction de parking "la nuit" s'applique réellement et
> est contrôlée, ce sera de toute façon en fonction des horaires de travail
> plus que sur la nuit réelle.
>
> J'aime cette supposition^^.
>

Qui dit horaires de travail, dit aussi heure légale. Porquoi ne pas
indiquer alors les heures (donc indépendamment des évolutions diurnes toute
l'année)... Ce genre de règle floue ne peut que causer des problèmes
(pourquoi le pouvais me garer hier ou le mois dernier et plus aujourd'hui,
mes horaires n'ont pas changé...). Et pour un peu ça dépend aussi de la
météo à l'aube ou en soirée qui peut changer la luminosité apparente bien
plus vite: Le policier stupide lui dira: il fait nuit puisque les
lampadaires sont allumés... Sauf que ça ne marche pas comme ça et la météo
change sans prévenir personne (difficile de prévoir si on va sa
grer quelques heures). Parlons de la gêne de voisinage, ce qui peut compter
c'est le bruit et les nuisances, l'absence de sécurité/surveillance et
surtout les horaires de travail de ceux qui surveillent le domaine
public... Tout le monde se base sur l'heure légale. Même pour fermer les
plages la nuit en ce moment, c'est réglementé par des horaires et pas une
vague indication, surtout s'agissant ici de restrictions/interdictions.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Sören Reinecke via talk

Also Linux is the future. Every application that cannot run under Linux will fail in the long run. Remember that Windows shouldn't be the main target platform anymore because it is dying and the society is to blame that they don't get it.CheersSören Reinecke alias Valor Naram Original Message Subject: Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2From: James To: john whelan CC: OpenStreetMap talk mailing list Personally I use Linux and I fail to see why funding an application that isn't multiplatform. I choose to use linux as scripting/data manipulation is easier than windows.I will not install adobe air as it's discontinued on linux since 2011(security bugs anyone?).  Development and bug fixes on AIR have come to a crawl on other platforms, if you can't seen it's impending death with Web2.0 as well as web assembly, clearly you cannot read the market.On Sun., Aug. 2, 2020, 9:53 a.m. john whelan,  wrote:If Air is proprietary and an Adobe product I strongly suggest avoiding it purely from a security point of view.  Adobe does not have a good reputation in the security world.  Comments certainly have been made about Flash.I don't think we should be encouraging the installation of software that could cause problems for our mappers.I accept that for many who know potlatch well there is a cost of learning something new and many are experienced editors who we'd like to see continue but there are tradeoffs and I think security of the software we are asking people to install should be taken into account.Cheerio JohnOn Sun, Aug 2, 2020, 08:54 pangoSE  wrote:

Is this the platform you are targeting? https://en.m.wikipedia.org/wiki/Adobe_AIRIts proprietary which makes it prone to the same fate as Flash Player. Why even consider such a move?I never use nonfree software like flash so I never tried P2. What is so special about it? Is there something hindering adding that specialness (as a plugin perhaps) to JOSM?The JOSM devs seem very helpful, supporting and have a friendly culture.I suggest letting this code die as it lures people to install nonfree and therefore dangerous software. Alternatively that you team up with your 20 mio edits-peers and port the code to something that does not require proprietary software. You did not present a single usecase that is not covered already by one of the other free software editors so I'm guessing you will have a hard time convincing your peers to team up around yet another editor, but I might be wrong.I don't care about your ROI arguments because they are based on the not outspoken premise that economics of software development is more important when making decisions than freedom, which is false IMO. If you had compared 2 free software projects like iD and JOSM that run without any proprietary code, then it might have been relevant.I suggest declining support of any software project that is or requires proprietary software to run.Cheers pangoSEPS I use 4 different editors to edit in the database: JOSM, OsmAnd, StreetComplete and rarely iD.Richard Fairhurst  skrev: (2 augusti 2020 10:28:22 CEST)

Skyler Hawthorne wrote:
> Sorry if this sounds harsh, but I think using any funds at all to 
> continue support for a tool that 1% of editors use would be wasteful. 
> Flash is, for all intents and purposes, a dead technology. This 
> money is better spent on other uses.

The entire point is to move away from a dead technology (Flash Player) to a supported one (AIR).

On the percentage stat, it's worth bearing in mind that the P2 project is by a long chalk the smallest sum (€2500) of the three that OSMF is proposing here. As a point of comparison, iD was initially developed with a $575,000 grant from the Knight Foundation in 2012, so roughly $646,000 now. Very conservatively estimating the cost of employing 1-2 developers to code on iD since then, you get a development cost of roughly €0.004 per (2020) changeset for iD vs $0.0002 for P2, which is kind of fun.

(I'm actually pleasantly surprised that P2 still has so many changesets - 20 million last year, and I'm guessing high teens this year - given how difficult it is to get Flash Player running in most browsers these days. That suggests that P2's users are using it because they want to do so, not because they are magically unaware of the existence of other editors. I suspect if you could find another way of getting 20 million edits for €2500 then we would snap your hand off.)

Looking forward, and continuing the theme of ROI, the other benefit of the project is that it enables development work to continue on P2. The reason I have bid for funding for this, for the first time in 14 years of developing editors for OpenStreetMap, is that it will take a solid chunk of sustained work to do the AIR conversion and a bunch of other stuff I believe will make P2 more sustainable into the future, and

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione Jo

The way I read this, is that there is money that will be used toward
advancing the 3 projects and funding is being sought to finance continued
development of iD. So I'd say there is a difference.

I take it all as good news. Of course, I would also like to see some
financial support for JOSM and Vespucci, but one can only spend each
euro/dollar/pound once, so choices must be made.

Polyglot

On Sun, Aug 2, 2020 at 2:53 PM JB  wrote:

> So, with sarcasm (at least half-)on, and english not being my
> mothertongue: the osm2pgsql/Nomatim/Potlatch grants were just Troyan
> horses to enable the OSMF funding of (ex or not ex?) Mapbox developer,
> with contributors not screaming too loudly? And explaining the iD
> conflict resolution process that was proposed lately (and, surprise,
> accepted by Mapbox iD developers)?
> Much thanks to the iD developers for having kept long, trustful and
> peaceful relationships with the community over the years of iD development.
> Just saying out loud what some people may or may not think, but would
> not dare to write. It does not expect answers.
> JB.
>
> Le 02/08/2020 à 13:44, Mikel Maron a écrit :
> > Hello
> >
> > The OSMF board is working to make OSM's core software and infrastructure
> more stable and sustainable by supporting paid roles for priority needs,
> such as the Senior Site Reliability role (
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html),
> and the pilot to fund "OSM Infrastructure" projects (
> https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html
> ).
> >
> > As part of this focus, we want to organise coordinated funding to
> support continued maintenance and development of the iD editor, as iD's
> strong continuous development over the past several years has served the
> OSM community well. Quincy Morgan is iD's maintainer and lead developer.
> Unfortunately, full-time support of his work recently ended. He'd very much
> like to continue, and the OSMF Board wants to see that happen. He has
> written up this proposal (
> https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
> with his ideal plans for iD over the next year, along with notes about how
> he'll organise, grow the developer base, communicate, and set priorities,
> and make iD better. The final priorities for the year will be made in
> consultation with the community.
> >
> > To help fund this project, as well as the SSRE role, we're looking at
> earmarked donations from companies, chapters and organisations.
> Administratively, we believe this is easier than other methods of pooled
> funding, as the OSMF is already in most companies' procurement systems, and
> it would limit paperwork to one contract for iD. Initial contract would be
> for 1 year, and that's what the OSMF would look to raise now.
> >
> > With the OSMF holding the contract, the Board would take a key
> accountability role, reviewing work done on the contract and assessing
> progress on the plans Quincy develops for the project. Additionally, the
> OSMF is working in cooperation with Quincy to establish a formal appeal
> process (
> https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
> for the relatively rare community issues iD cannot resolve itself.
> >
> > The OSMF would not see its role as a traditional "boss", instructing iD
> to focus on this or that feature. We would not be prescriptive about
> priorities. This does not mean work in a vacuum. Our expectation is that
> Quincy, in addition to following our hiring framework's principles for
> transparent service to the community, would regularly convene stakeholders
> from the community to share their priorities and feedback. Quincy would
> assess all priorities holistically as he decides on a workable plan for the
> project.
> >
> > Over the course of the year, we'll evaluate and learn from how the
> arrangement is working for all, as we look towards year 2 and beyond. For
> future years, we are looking at developing an overall plan for long-term
> support for all parts of the OSMF infrastructure. We want to be able to
> offer similar support to other OSM editors. Our early focus on iD is to
> ensure continued development.
> >
> > We want to find out what you, the OSM community, think. Do you have any
> feedback?
> >
> > If you know of an organisation that might want to fund this, please feel
> free to ask them to contact the OSMF Board.
> >
> > -Mikel, for the OSMF Board
> >
> > * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >
> > ___
> > osmf-talk mailing list
> > osmf-t...@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione James

Personally I use Linux and I fail to see why funding an application that
isn't multiplatform. I choose to use linux as scripting/data manipulation
is easier than windows.

I will not install adobe air as it's discontinued on linux since
2011(security bugs anyone?).  Development and bug fixes on AIR have come to
a crawl on other platforms, if you can't seen it's impending death with
Web2.0 as well as web assembly, clearly you cannot read the market.

On Sun., Aug. 2, 2020, 9:53 a.m. john whelan,  wrote:

> If Air is proprietary and an Adobe product I strongly suggest avoiding it
> purely from a security point of view.  Adobe does not have a good
> reputation in the security world.  Comments certainly have been made about
> Flash.
>
> I don't think we should be encouraging the installation of software that
> could cause problems for our mappers.
>
> I accept that for many who know potlatch well there is a cost of learning
> something new and many are experienced editors who we'd like to see
> continue but there are tradeoffs and I think security of the software we
> are asking people to install should be taken into account.
>
> Cheerio John
>
> On Sun, Aug 2, 2020, 08:54 pangoSE  wrote:
>
>> Is this the platform you are targeting?
>> https://en.m.wikipedia.org/wiki/Adobe_AIR
>>
>> Its proprietary which makes it prone to the same fate as Flash Player.
>> Why even consider such a move?
>>
>> I never use nonfree software like flash so I never tried P2. What is so
>> special about it? Is there something hindering adding that specialness (as
>> a plugin perhaps) to JOSM?
>>
>> The JOSM devs seem very helpful, supporting and have a friendly culture.
>>
>> I suggest letting this code die as it lures people to install nonfree and
>> therefore dangerous software. Alternatively that you team up with your 20
>> mio edits-peers and port the code to something that does not require
>> proprietary software.
>>
>> You did not present a single usecase that is not covered already by one
>> of the other free software editors so I'm guessing you will have a hard
>> time convincing your peers to team up around yet another editor, but I
>> might be wrong.
>>
>> I don't care about your ROI arguments because they are based on the not
>> outspoken premise that economics of software development is more important
>> when making decisions than freedom, which is false IMO.
>> If you had compared 2 free software projects like iD and JOSM that run
>> without any proprietary code, then it might have been relevant.
>>
>> I suggest declining support of any software project that is or requires
>> proprietary software to run.
>>
>> Cheers
>> pangoSE
>> PS I use 4 different editors to edit in the database: JOSM, OsmAnd,
>> StreetComplete and rarely iD.
>>
>>
>> Richard Fairhurst  skrev: (2 augusti 2020 10:28:22
>> CEST)
>>>
>>> Skyler Hawthorne wrote:
>>> > Sorry if this sounds harsh, but I think using any funds at all to
>>> > continue support for a tool that 1% of editors use would be wasteful.
>>> > Flash is, for all intents and purposes, a dead technology. This
>>> > money is better spent on other uses.
>>>
>>> The entire point is to move away from a dead technology (Flash Player)
>>> to a supported one (AIR).
>>>
>>> On the percentage stat, it's worth bearing in mind that the P2 project
>>> is by a long chalk the smallest sum (€2500) of the three that OSMF is
>>> proposing here. As a point of comparison, iD was initially developed with a
>>> $575,000 grant from the Knight Foundation in 2012, so roughly $646,000 now.
>>> Very conservatively estimating the cost of employing 1-2 developers to code
>>> on iD since then, you get a development cost of roughly €0.004 per (2020)
>>> changeset for iD vs $0.0002 for P2, which is kind of fun.
>>>
>>> (I'm actually pleasantly surprised that P2 still has so many changesets
>>> - 20 million last year, and I'm guessing high teens this year - given how
>>> difficult it is to get Flash Player running in most browsers these days.
>>> That suggests that P2's users are using it because they want to do so, not
>>> because they are magically unaware of the existence of other editors. I
>>> suspect if you could find another way of getting 20 million edits for €2500
>>> then we would snap your hand off.)
>>>
>>> Looking forward, and continuing the theme of ROI, the other benefit of
>>> the project is that it enables development work to continue on P2. The
>>> reason I have bid for funding for this, for the first time in 14 years of
>>> developing editors for OpenStreetMap, is that it will take a solid chunk of
>>> sustained work to do the AIR conversion and a bunch of other stuff I
>>> believe will make P2 more sustainable into the future, and there is a hard
>>> deadline for that sustained work (i.e. Flash Player switch-off at the end
>>> of the year). It's not a project that can just be done in evenings here and
>>> there. That enables further, unfunded developments in the future, and in
>>> turn I hope the

Re: [Talk-at] Haben Kirchen eine Hausnummer?

2020-08-02 Per discussione Johann Haag

Gegenüber der Kirche ist das Gemeindeamt der Gemeinde Thal,
Dessen Bauamt verwaltet die Hausnummern in einer Software genannt AGWR, jedes 
Objekt hat eine ID.
Du solltest für diese Frage daher am besten direkt bei der Gemeinde Thal 
anrufen, diese wird Dir sicher gerne Auskunft erteilen

Lg Johann.


> Am 28.07.2020 um 23:44 schrieb Robert Grübler :
> 
> Mir ist das bei der Fuchs-Kirche in Thal aufgefallen: 
> https://www.openstreetmap.org/way/131989836 
> 
> Die Adresse Am Kirchberg 1 ist identisch zum alten Pfarrhof. Wurde sie
> vielleicht von dort übertragen?
> Wegen der Erweiterung der Volksschule wurde der alte Pfarrhof verkauft und
> an andere Stelle neu errichtet. Die Adresse ist nun Am Kirchberg 3.
> 
> Was folgt daraus für die Kirche?
> 
> LG Robert
> 
> 
> ___
> 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] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione john whelan

If Air is proprietary and an Adobe product I strongly suggest avoiding it
purely from a security point of view.  Adobe does not have a good
reputation in the security world.  Comments certainly have been made about
Flash.

I don't think we should be encouraging the installation of software that
could cause problems for our mappers.

I accept that for many who know potlatch well there is a cost of learning
something new and many are experienced editors who we'd like to see
continue but there are tradeoffs and I think security of the software we
are asking people to install should be taken into account.

Cheerio John

On Sun, Aug 2, 2020, 08:54 pangoSE  wrote:

> Is this the platform you are targeting?
> https://en.m.wikipedia.org/wiki/Adobe_AIR
>
> Its proprietary which makes it prone to the same fate as Flash Player. Why
> even consider such a move?
>
> I never use nonfree software like flash so I never tried P2. What is so
> special about it? Is there something hindering adding that specialness (as
> a plugin perhaps) to JOSM?
>
> The JOSM devs seem very helpful, supporting and have a friendly culture.
>
> I suggest letting this code die as it lures people to install nonfree and
> therefore dangerous software. Alternatively that you team up with your 20
> mio edits-peers and port the code to something that does not require
> proprietary software.
>
> You did not present a single usecase that is not covered already by one of
> the other free software editors so I'm guessing you will have a hard time
> convincing your peers to team up around yet another editor, but I might be
> wrong.
>
> I don't care about your ROI arguments because they are based on the not
> outspoken premise that economics of software development is more important
> when making decisions than freedom, which is false IMO.
> If you had compared 2 free software projects like iD and JOSM that run
> without any proprietary code, then it might have been relevant.
>
> I suggest declining support of any software project that is or requires
> proprietary software to run.
>
> Cheers
> pangoSE
> PS I use 4 different editors to edit in the database: JOSM, OsmAnd,
> StreetComplete and rarely iD.
>
>
> Richard Fairhurst  skrev: (2 augusti 2020 10:28:22
> CEST)
>>
>> Skyler Hawthorne wrote:
>> > Sorry if this sounds harsh, but I think using any funds at all to
>> > continue support for a tool that 1% of editors use would be wasteful.
>> > Flash is, for all intents and purposes, a dead technology. This
>> > money is better spent on other uses.
>>
>> The entire point is to move away from a dead technology (Flash Player) to
>> a supported one (AIR).
>>
>> On the percentage stat, it's worth bearing in mind that the P2 project is
>> by a long chalk the smallest sum (€2500) of the three that OSMF is
>> proposing here. As a point of comparison, iD was initially developed with a
>> $575,000 grant from the Knight Foundation in 2012, so roughly $646,000 now.
>> Very conservatively estimating the cost of employing 1-2 developers to code
>> on iD since then, you get a development cost of roughly €0.004 per (2020)
>> changeset for iD vs $0.0002 for P2, which is kind of fun.
>>
>> (I'm actually pleasantly surprised that P2 still has so many changesets -
>> 20 million last year, and I'm guessing high teens this year - given how
>> difficult it is to get Flash Player running in most browsers these days.
>> That suggests that P2's users are using it because they want to do so, not
>> because they are magically unaware of the existence of other editors. I
>> suspect if you could find another way of getting 20 million edits for €2500
>> then we would snap your hand off.)
>>
>> Looking forward, and continuing the theme of ROI, the other benefit of
>> the project is that it enables development work to continue on P2. The
>> reason I have bid for funding for this, for the first time in 14 years of
>> developing editors for OpenStreetMap, is that it will take a solid chunk of
>> sustained work to do the AIR conversion and a bunch of other stuff I
>> believe will make P2 more sustainable into the future, and there is a hard
>> deadline for that sustained work (i.e. Flash Player switch-off at the end
>> of the year). It's not a project that can just be done in evenings here and
>> there. That enables further, unfunded developments in the future, and in
>> turn I hope the tradition of other editors taking inspiration from P2 can
>> continue - it's not for nothing that JOSM has a Potlatch 2 style and a
>> "Potlatch mode" for editing.
>>
>> But you are, of course, welcome to develop and put forward a project to
>> OSMF which you believe will have more bang for the buck. "Other uses" is
>> easy to type but doesn't actually mean anything until you identify what
>> those uses are, and crucially, find someone who is prepared to do them.
>>
>> Richard
>>
> ___
> talk mailing list
> talk@openstreetmap.org
>

Re: [OSM-talk-be] Help to young active men in kivu

2020-08-02 Per discussione Georges Khaznadar

Hello Nicolas, hello everybody,

using Riot rather than Telegram does not change much when one cannot
master the web servers which are providing the service.

As far as I undestood, the high prices of Internet access in Kivu are
due to foreign companies trusting the scarse hardware network.

If I live in Kivu, and if I want to create a small communication
company, what would be the cost of opening a regional communication
service, eventually featuring Riot? Can I do it independently, or must I
accept the conditions of Orange, Airtel or Vodacom?

Best regards,   Georges.

Nicolas Pettiaux a écrit :
> Hello,
> 
> A team of active young men in kivu with very limited internet access are 
> looking for help to map better their city of Bukavu and surroundings.
> 
> They have smatphones and expensive connections with low bandwidth.
> 
> They use telegram and email, but I don't know for riot.
> 
> Some are in cc and more are on the mailing list k...@educode.ne
> 
> Much thanks to everyone who van guide and help thème better than I can or do.
> 
> Regards,
> 
> Nicolas
> 
> -- 
> Nicolas Pettiaux
> --
> Nicolas Pettiaux, PhD - tel +32.496.24.55.01
> Collaborer pour mieux enseigner - https://wiki.educode.be
> Educode accompagne les écoles face aux défis du numérique
> Envoyé de mon fairphone - veuillez excuser la brièveté
> 

-- 
Georges KHAZNADAR et Jocelyne FOURNIER
22 rue des mouettes, 59240 Dunkerque France.
Téléphone +33 (0)3 28 29 17 70



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

Re: [OSM-talk-fr] Pourquoi inventer un aire urbaine imaginaire ?

2020-08-02 Per discussione rmehut

Bonjour,

Pour info, j'ai supprimé tous les polygones boundary=urban sur la France 
métropolitaine. J'aimerais également supprimer les traffic_sign=city_limit 
créés par le contributeur à l'origine des polygones mais uniquement ceux restés 
en version 1. Comment faire cette distinction dans overpass turbo ?

Et est-ce que le contributeur a été informé des échanges sur talk-fr ?

Romain


Bonjour,

Pour information, j'ai eu la désagréable surprise de voir ressurgir ces
abominations que nous avions patiemment supprimées au cours de ces derniers
mois du territoire de l'Ille-et-Vilaine (cf. ce changeset :
https://www.openstreetmap.org/changeset/87258927?way_page=3 par exemple).
La méthode est toujours la même que celle pointée par Christian R il y a un
an et demi : tracé approximatif (il passe allègrement à travers des
quartiers d'habitation, voire des maisons), chevauchement de ses polygones,
absence de fondement administratif alors qu'il les range dans un
"admin_level", pas de concertation avec les locaux.
À cette liste, il faut ajouter que des appli comme OSMand fait apparaître
ces limites avec la même symbologie que les vraies limites communales, ce
qui rend la carte particulièrement illisible dans certains cas.

Pour ma part, je dégage à vue sur le territoire de mon EPCI, mais il
faudrait sans doute trouver une solution plus efficace pour traiter ce
problème.

Bonne journée,

P-Y

_
Sent from http://gis.19327.n8.nabble.com


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione pangoSE

Is this the platform you are targeting? 
https://en.m.wikipedia.org/wiki/Adobe_AIR

Its proprietary which makes it prone to the same fate as Flash Player. Why even 
consider such a move?

I never use nonfree software like flash so I never tried P2. What is so special 
about it? Is there something hindering adding that specialness (as a plugin 
perhaps) to JOSM?

The JOSM devs seem very helpful, supporting and have a friendly culture.

I suggest letting this code die as it lures people to install nonfree and 
therefore dangerous software. Alternatively that you team up with your 20 mio 
edits-peers and port the code to something that does not require proprietary 
software. 

You did not present a single usecase that is not covered already by one of the 
other free software editors so I'm guessing you will have a hard time 
convincing your peers to team up around yet another editor, but I might be 
wrong.

I don't care about your ROI arguments because they are based on the not 
outspoken premise that economics of software development is more important when 
making decisions than freedom, which is false IMO. 
If you had compared 2 free software projects like iD and JOSM that run without 
any proprietary code, then it might have been relevant.

I suggest declining support of any software project that is or requires 
proprietary software to run.

Cheers 
pangoSE
PS I use 4 different editors to edit in the database: JOSM, OsmAnd, 
StreetComplete and rarely iD.

Richard Fairhurst  skrev: (2 augusti 2020 10:28:22 CEST)
>Skyler Hawthorne wrote:
>> Sorry if this sounds harsh, but I think using any funds at all to
>> continue support for a tool that 1% of editors use would be wasteful.
>> Flash is, for all intents and purposes, a dead technology. This
>> money is better spent on other uses.
>
>The entire point is to move away from a dead technology (Flash Player)
>to a supported one (AIR).
>
>On the percentage stat, it's worth bearing in mind that the P2 project
>is by a long chalk the smallest sum (€2500) of the three that OSMF is
>proposing here. As a point of comparison, iD was initially developed
>with a $575,000 grant from the Knight Foundation in 2012, so roughly
>$646,000 now. Very conservatively estimating the cost of employing 1-2
>developers to code on iD since then, you get a development cost of
>roughly €0.004 per (2020) changeset for iD vs $0.0002 for P2, which is
>kind of fun.
>
>(I'm actually pleasantly surprised that P2 still has so many changesets
>- 20 million last year, and I'm guessing high teens this year - given
>how difficult it is to get Flash Player running in most browsers these
>days. That suggests that P2's users are using it because they want to
>do so, not because they are magically unaware of the existence of other
>editors. I suspect if you could find another way of getting 20 million
>edits for €2500 then we would snap your hand off.)
>
>Looking forward, and continuing the theme of ROI, the other benefit of
>the project is that it enables development work to continue on P2. The
>reason I have bid for funding for this, for the first time in 14 years
>of developing editors for OpenStreetMap, is that it will take a solid
>chunk of sustained work to do the AIR conversion and a bunch of other
>stuff I believe will make P2 more sustainable into the future, and
>there is a hard deadline for that sustained work (i.e. Flash Player
>switch-off at the end of the year). It's not a project that can just be
>done in evenings here and there. That enables further, unfunded
>developments in the future, and in turn I hope the tradition of other
>editors taking inspiration from P2 can continue - it's not for nothing
>that JOSM has a Potlatch 2 style and a "Potlatch mode" for editing.
>
>But you are, of course, welcome to develop and put forward a project to
>OSMF which you believe will have more bang for the buck. "Other uses"
>is easy to type but doesn't actually mean anything until you identify
>what those uses are, and crucially, find someone who is prepared to do
>them.
>
>Richard
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] [Osmf-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione JB

So, with sarcasm (at least half-)on, and english not being my
mothertongue: the osm2pgsql/Nomatim/Potlatch grants were just Troyan
horses to enable the OSMF funding of (ex or not ex?) Mapbox developer,
with contributors not screaming too loudly? And explaining the iD
conflict resolution process that was proposed lately (and, surprise,
accepted by Mapbox iD developers)?
Much thanks to the iD developers for having kept long, trustful and
peaceful relationships with the community over the years of iD development.
Just saying out loud what some people may or may not think, but would
not dare to write. It does not expect answers.

JB.

Le 02/08/2020 à 13:44, Mikel Maron a écrit :

Hello

The OSMF board is working to make OSM's core software and infrastructure more stable and
sustainable by supporting paid roles for priority needs, such as the Senior Site
Reliability role
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html), and the
pilot to fund "OSM Infrastructure" projects
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html).

As part of this focus, we want to organise coordinated funding to support
continued maintenance and development of the iD editor, as iD's strong
continuous development over the past several years has served the OSM community
well. Quincy Morgan is iD's maintainer and lead developer. Unfortunately,
full-time support of his work recently ended. He'd very much like to continue,
and the OSMF Board wants to see that happen. He has written up this proposal
(https://github.com/quincylvania/quincylvania.com/blob/main/resources/Morgan%20iD%20work%20proposal%207_27.pdf)
with his ideal plans for iD over the next year, along with notes about how
he'll organise, grow the developer base, communicate, and set priorities, and
make iD better. The final priorities for the year will be made in consultation
with the community.

To help fund this project, as well as the SSRE role, we're looking at earmarked
donations from companies, chapters and organisations. Administratively, we
believe this is easier than other methods of pooled funding, as the OSMF is
already in most companies' procurement systems, and it would limit paperwork to
one contract for iD. Initial contract would be for 1 year, and that's what the
OSMF would look to raise now.

With the OSMF holding the contract, the Board would take a key accountability
role, reviewing work done on the contract and assessing progress on the plans
Quincy develops for the project. Additionally, the OSMF is working in
cooperation with Quincy to establish a formal appeal process
(https://blog.openstreetmap.org/2020/06/08/toward-resolution-of-controversies-related-to-id/)
for the relatively rare community issues iD cannot resolve itself.

The OSMF would not see its role as a traditional "boss", instructing iD to
focus on this or that feature. We would not be prescriptive about priorities. This does
not mean work in a vacuum. Our expectation is that Quincy, in addition to following our
hiring framework's principles for transparent service to the community, would regularly
convene stakeholders from the community to share their priorities and feedback. Quincy
would assess all priorities holistically as he decides on a workable plan for the project.

Over the course of the year, we'll evaluate and learn from how the arrangement
is working for all, as we look towards year 2 and beyond. For future years, we
are looking at developing an overall plan for long-term support for all parts
of the OSMF infrastructure. We want to be able to offer similar support to
other OSM editors. Our early focus on iD is to ensure continued development.

We want to find out what you, the OSM community, think. Do you have any
feedback?

If you know of an organisation that might want to fund this, please feel free
to ask them to contact the OSMF Board.

-Mikel, for the OSMF Board

* Mikel Maron * +14152835207 @mikel s:mikelmaron

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

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

Re: [OSM-talk] Funding of iD Development and Maintenance

sent from a phone

> On 2. Aug 2020, at 13:49, Mikel Maron  wrote:
> 
> As part of this focus, we want to organise coordinated funding to support 
> continued maintenance and development of the iD editor, as iD's strong 
> continuous development over the past several years has served the OSM 
> community well.

this is very exciting news. Part of the work could be invested to align iD’s 
tagging suggestions with the community expectations for established tags. 
There’s also this impressive list of contested decisions from the past, which 
could merit looking at when thinking about the direction that iD shall go to:

https://wiki.openstreetmap.org/wiki/ID/Controversial_Decisions

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

[Talk-pt] key capital= (Padronização das localidades)

2020-08-02 Per discussione Hugo Valentim

s://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png
>
> Este padrão, no entanto, não está a ser usado de maneira uniforme nas
> edições que os contribuidores têm feito.
> Em geral, a dúvida mais comum é como aglomerar 5 conceitos diferentes
> (capital de distrito/sede de município/cidade/vila/freguesia) em 3 tags
> possíveis (city/town/village).
> Neste momento e, segundo a wiki, a tag "city" está reservada a capitais de
> distrito, a tag "town" a todas as sedes de município, cidades e vilas, e a
> tag "village" a freguesias ou sedes de município que não sejam pelo menos
> vila (não conheço nenhum caso).
>
> Actualmente esta regra, se aplicada à risca, cria alguns casos caricatos.
> É fácil encontrar casos no Grande Porto e Grande Lisboa em que uma cidade
> tenha várias freguesias que são elas próprias cidades ou vilas. Num exemplo
> prático, a cidade de Vila Nova de Gaia partilhará a tag town com mais de
> uma mão cheia de freguesias do seu concelho, o que a nível de renderização
> pode trazer problemas - em zooms mais baixos/distantes Vila Nova de Gaia,
> apesar de cidade e sede de concelho, poderá desaparecer em favor de uma
> freguesia sua que seja vila.
>
> O que proponho é uma alteração à regra existente, de forma à divisão ser
> esta:
>
> Capital de Distrito? -> place = city
> Cidade ou Capital Administrativa de Município? -> place = town
> Vila ou Capital Administrativa de Freguesia (não urbana)? -> place =
> village
> Capital Administrativa de Freguesia (urbana)? -> place = neighbourhood
>
> Esta mudança efectivamente cria distinções entre cidades e vilas, ao mesmo
> tempo que preserva uma hierarquia em termos de divisões administrativas,
> sem criar casos caricatos como o acima descrito.
>
> Numa nota final, questiono se fará sentido despromover todas as sedes de
> freguesia para place=neighbourhood, por uma questão lógica. Não incluí essa
> distinção no caso acima, incluindo apenas as freguesias urbanas nessa tag,
> porque no contexto nacional a maioria das sedes de freguesia rurais têm
> efectivamente a identidade e contexto histórico de um povoado distinto, ao
> contrário da maioria (e aqui podemos argumentar) das sedes de freguesia
> urbanas, que são historicamente vistas como sendo parte integrante da
> cidade a que pertencem.
>
> Agradeço desde já a vossa participação nesta discussão, pois é necessário
> chegar a alguma conclusão neste tema, que já foi debatido várias vezes.
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


--
Alexandre Moleiro
  alexandre.mole...@gmail.com
-- next part --
An HTML attachment was scrubbed...
URL: 
<http://lists.openstreetmap.org/pipermail/talk-pt/attachments/20200802/ad186ac3/attachment-0001.htm>

--

Subject: Digest Footer

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


--

End of Talk-pt Digest, Vol 127, Issue 1
***

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

[OSM-talk] Funding of iD Development and Maintenance

2020-08-02 Per discussione Mikel Maron

Hello

The OSMF board is working to make OSM's core software and infrastructure more
stable and sustainable by supporting paid roles for priority needs, such as the
Senior Site Reliability role
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-July/006973.html),
and the pilot to fund "OSM Infrastructure" projects
(https://lists.openstreetmap.org/pipermail/osmf-talk/2020-August/006987.html).

The OSMF would not see its role as a traditional "boss", instructing iD to
focus on this or that feature. We would not be prescriptive about priorities.
This does not mean work in a vacuum. Our expectation is that Quincy, in
addition to following our hiring framework's principles for transparent service
to the community, would regularly convene stakeholders from the community to
share their priorities and feedback. Quincy would assess all priorities
holistically as he decides on a workable plan for the project.

We want to find out what you, the OSM community, think. Do you have any
feedback?

If you know of an organisation that might want to fund this, please feel free
to ask them to contact the OSMF Board.

-Mikel, for the OSMF Board

* Mikel Maron * +14152835207 @mikel s:mikelmaron

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

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Mark Goodge




On 02/08/2020 11:58, Jez Nicholson wrote:
My initial thought was also "conspiracy!". Licence problem is more 
likely, or perhaps they were concerned that someone might poll the URL 
with every available UPRN.


I'm certain that it's been done to prevent people using the EA site as a 
means of looking up an address from a UPRN. That's the only plausible 
explanation for a change which both makes the site more complex from an 
operator point of view (instead of a single database lookup, it now 
needs to do several to identify the property from the postcode and 
sequence ID) and less useful from a user perspective (because you can no 
longer bookmark and share a link to a specific property).


If it is a licence issue, then that's going to have ramifications beyond 
the EA. A lot of local authorities use the UPRN in the URL for 
property-related information. For example, if you live in Cambridge, you 
can check when your bins will be emptied by appending the UPRN to the page:


https://www.cambridge.gov.uk/check-when-your-bin-will-be-emptied#id=24173390

and if you live in Worcestershire, you can check lots of useful stuff 
about your property:


http://e-services.worcestershire.gov.uk/MyLocalArea/MyLocalAreaResults.aspx?uprn=100120673306

It seems to me that this is precisely how the UPRN should be used by 
government and other organisations. To quote Matt Hancock from when he 
was the secretary of state for DCMS:


"The UPRN is the jewel at the heart of the addressing system. It links 
address data across a diverse range of systems and services facilitating 
greater accuracy and immediate data sharing"


and the government's own statement on open UPRNs states that

"Users need property and street information with identifiers that remain 
the same over time and are easy to exchange between systems."


and

"Systems, services and applications that store or publish data sets 
containing property and street information must use the UPRN and USRN 
identifiers."


https://www.gov.uk/government/publications/open-standards-for-government/identifying-property-and-street-information

So it seems to me that there should be no licensing issues with using 
the UPRN as a unique identifier in a public URL. If anything, the 
requirement to use UPRNs in any published dataset seems to pretty much 
make it the simplest means of compliance.


(I appreciate that this is going a bit off topic for OSM, so I think 
I'll leave it there unless there's anything else directly 
mapping-related, but it's worth noting that this change has already been 
mentioned on social media and I suspect it's an issue which will gain 
more traction over time).


Mark

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

[Talk-cu] semanarioOSM Nº 523 2020-07-21-2020-07-27

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

https://www.weeklyosm.eu/es/archives/13451/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

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

[Talk-es] semanarioOSM Nº 523 2020-07-21-2020-07-27

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

https://www.weeklyosm.eu/es/archives/13451/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

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

[OSM-co] semanarioOSM Nº 523 2020-07-21-2020-07-27

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

https://www.weeklyosm.eu/es/archives/13451/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

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

[Talk-cl] semanarioOSM Nº 523 2020-07-21-2020-07-27

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

https://www.weeklyosm.eu/es/archives/13451/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

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º 523 2020-07-21-2020-07-27

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

https://www.weeklyosm.eu/es/archives/13451/

¡Disfruta!

¿Sabías que también puedes enviar mensajes para la nota semanal sin ser 
miembro? Simplemente ingresa a https://osmbc.openstreetmap.de/login con tu 
cuenta de OSM. Lee más sobre cómo escribir una publicación aquí: 
http://www.weeklyosm.eu/es/this-news-should-be-in-weeklyosm 

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

[Talk-it] weeklyOSM #523 2020-07-21-2020-07-27

Il settimanale di notizie su OSM, numero # 523, è ora disponibile online in 
italiano, 
fornendo come sempre un riassunto di molte cose che accadono nel mondo 
OpenStreetMap: 

https://www.weeklyosm.eu/it/archives/13451/

Buona lettura! 

Sai che possono anche inviare messaggi per il weeklyOSM? Basta effettuare il 
login 
su https://osmbc.openstreetmap.de/login con il tuo account OSM. 

Per saperne di più su come scrivere un messaggio, leggi qui: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 
weeklyOSM? 

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

[Talk-ca] hebdoOSM Nº 523 2020-07-21-2020-07-27

Bonjour,

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

https://www.weeklyosm.eu/fr/archives/13451/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Nick

Hi Jez

You can limit the number of requests to a specific URL (or set of URLs) 
by IP address - so polling "every available UPRN" would not be an issue 
(e.g. can limit the number of requests from a given IP over a given time 
period).

Cheers

Nick

On 02/08/2020 11:58, Jez Nicholson wrote:

My initial thought was also "conspiracy!". Licence problem is more 
likely, or perhaps they were concerned that someone might poll the URL 
with every available UPRN.

On Sun, 2 Aug 2020, 11:38 Nick, > wrote:

I have no problem with licencing but the UPRN and related data is
managed by Authority custodians - do they not retain ownership of that 
data?

If the authorities sell it to OS, then should this be raised with The Rt
Hon Alok Sharma MP (he owns 100% of the shares of OS)?

N.B. there are some aspects to address data that is subject to other IP
rights but the remainder. is surely of public interest and value.

On 02/08/2020 10:34, Russ Garrett wrote:
> On Sun, 2 Aug 2020 at 10:20, Andy Mabbett > wrote:

>> Do you have a plausible hypothesis to explain the removal of UPRNs
>> from the flood warning pages, that also gives us a reason to trust the
>> organisation that enacted that change?
> It's almost certainly because some lawyer or other spotted that it's a
> violation of the PSGA (formerly PSMA) license under which the
> AddressBase data is made available to the Environment Agency.
>
> 
https://www.ordnancesurvey.co.uk/documents/licensing/psga-member-licence.pdf

>
> There's no conspiracy here beyond OS zealously protecting its data, as
> it always has done.
>

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

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

[OSM-talk-fr] hebdoOSM Nº 523 2020-07-21-2020-07-27

Bonjour,

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

https://www.weeklyosm.eu/fr/archives/13451/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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º 523 2020-07-21-2020-07-27

Bonjour,

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

https://www.weeklyosm.eu/fr/archives/13451/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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-africa] hebdoOSM Nº 523 2020-07-21-2020-07-27

Bonjour,

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

https://www.weeklyosm.eu/fr/archives/13451/

Bonne lecture !

Saviez-vous que vous pouvez vous aussi soumettre des messages pour la note 
hebdomadaire sans être membre ? Il vous suffit de vous connecter sur 
https://osmbc.openstreetmap.de/login avec votre compte OSM. Pour en savoir plus 
sur la rédaction d'un article, cliquez ici: 
http://www.weeklyosm.eu/fr/this-news-should-be-in-weeklyosm

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-africa mailing list
Talk-africa@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-africa

[Talk-br] semanárioOSM Nº 523 2020-07-21-2020-07-27

Bom dia,

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

https://www.weeklyosm.eu/pb/archives/13451/

Aproveite!

Você sabia que também pode enviar mensagens para o OSM semanal/semanárioOSMſ 
sem ser membro? Basta fazer login em https://osmbc.openstreetmap.de/login com 
sua conta OSM e usar a conta de convidado. Leia mais sobre como escrever um 
post aqui: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm

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

[Talk-pt] semanárioOSM Nº 523 2020-07-21-2020-07-27

Bom dia,

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

https://www.weeklyosm.eu/pb/archives/13451/

Aproveite!

Você sabia que também pode enviar mensagens para o OSM semanal/semanárioOSMſ 
sem ser membro? Basta fazer login em https://osmbc.openstreetmap.de/login com 
sua conta OSM e usar a conta de convidado. Leia mais sobre como escrever um 
post aqui: http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm

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-us] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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

[OSM-talk] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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-GB] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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 #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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-africa] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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

[Talk-in] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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 #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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-ca] weeklyOSM #523 2020-07-21-2020-07-27

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

 https://www.weeklyosm.eu/en/archives/13451/

Enjoy! 

Did you know that you can also submit messages for the weeklyOSM? Just log in 
to https://osmbc.openstreetmap.de/login with your OSM account. Read more about 
how to write a post here: 
http://www.weeklyosm.eu/this-news-should-be-in-weeklyosm 

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-de] weeklyOSM #523 2020-07-21-2020-07-27

Die Wochennotiz Ausgabe Nr. # 523, ist nun verfügbar - 
wie immer mit vielen Nachrichten aus dem OSM-Universium:

https://www.weeklyosm.eu/de/archives/13451/

Viel Spaß beim Lesen.  

Euer Wochennotizteam

Wusstet ihr, dass ihr auch selbst Meldungen für die Wochennotiz
einreichen könnt? Einfach auf https://osmbc.openstreetmap.de/ 
mit eurem OSM-Benutzerkonto anmelden und dann den Gastzugang benutzen. 

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-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Andy Mabbett

On Sun, 2 Aug 2020 at 11:58, Jez Nicholson  wrote:

>>> the Environment Agency flood risk website no longer
>>> allows you to link directly to a property by UPRN

> perhaps they were concerned that someone might poll the URL with every 
> available UPRN.

If that were the case, I'm confident the government web team have the
knowledge and wherewithal to apply rate limiting.

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

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

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Jez Nicholson

My initial thought was also "conspiracy!". Licence problem is more likely,
or perhaps they were concerned that someone might poll the URL with every
available UPRN.

On Sun, 2 Aug 2020, 11:38 Nick,  wrote:

> I have no problem with licencing but the UPRN and related data is
> managed by Authority custodians - do they not retain ownership of that
> data?
>
> If the authorities sell it to OS, then should this be raised with The Rt
> Hon Alok Sharma MP (he owns 100% of the shares of OS)?
>
> N.B. there are some aspects to address data that is subject to other IP
> rights but the remainder. is surely of public interest and value.
>
> On 02/08/2020 10:34, Russ Garrett wrote:
> > On Sun, 2 Aug 2020 at 10:20, Andy Mabbett 
> wrote:
> >> Do you have a plausible hypothesis to explain the removal of UPRNs
> >> from the flood warning pages, that also gives us a reason to trust the
> >> organisation that enacted that change?
> > It's almost certainly because some lawyer or other spotted that it's a
> > violation of the PSGA (formerly PSMA) license under which the
> > AddressBase data is made available to the Environment Agency.
> >
> >
> https://www.ordnancesurvey.co.uk/documents/licensing/psga-member-licence.pdf
> >
> > There's no conspiracy here beyond OS zealously protecting its data, as
> > it always has done.
> >
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Nick

I have no problem with licencing but the UPRN and related data is 
managed by Authority custodians - do they not retain ownership of that data?


If the authorities sell it to OS, then should this be raised with The Rt 
Hon Alok Sharma MP (he owns 100% of the shares of OS)?


N.B. there are some aspects to address data that is subject to other IP 
rights but the remainder. is surely of public interest and value.


On 02/08/2020 10:34, Russ Garrett wrote:

On Sun, 2 Aug 2020 at 10:20, Andy Mabbett  wrote:

Do you have a plausible hypothesis to explain the removal of UPRNs
from the flood warning pages, that also gives us a reason to trust the
organisation that enacted that change?

It's almost certainly because some lawyer or other spotted that it's a
violation of the PSGA (formerly PSMA) license under which the
AddressBase data is made available to the Environment Agency.

https://www.ordnancesurvey.co.uk/documents/licensing/psga-member-licence.pdf

There's no conspiracy here beyond OS zealously protecting its data, as
it always has done.



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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch

2020-08-02 Per discussione mmd

On 2020-08-02 11:55, Richard Fairhurst wrote:
> The other is that 
> 2020's P2 users, contrary to the cliche of 2010, are actually pretty
> skilled and experienced (by definition the beginner users use iD
> these days) - many of them have a four-figure number of 
> changesets - so installing AIR shouldn't be beyond them.

Right, my intention wasn't really to allude to any skill level (although
I agree my statement very much reads like it). It's more that casual
mappers typically have lots of other hobbies, and have limited time
available for OSM. As a consequence they'd appreciate an editor that is
easy to work with and accessible without much hassle. Flash was widely
known outside of OSM before Potlatch was available, and I believe having
Flash as a prerequisite was never much of an issue in the last 10+
years, at least initially back in ~2010.

With AIR, I just don't know. I've never used it, and I also don't know
what casual mappers will think about it. Let's be positive, and assume
installation works just like a charm :)

-- 

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Simon Poole


Am 02.08.2020 um 01:03 schrieb Skyler Hawthorne:
> ...
>
> Sorry if this sounds harsh, but I think using any funds at all to
> continue support for a tool that 1% of editors use would be wasteful.
> Flash is, for all intents and purposes, a dead technology. This money
> is better spent on other uses.
> ...

Extending this a bit further, you could just as well say, given that all
current and actively maintained general purpose editors require 1-2
FTEs, the OSMF should simply block all non-iD editors and tell the
developers to either work on iD or go home.

In reality things are not quite that simple,  it starts with measuring
how much use an app actually gets.

While iD outstrips JOSM substantially wrt users (JOSM has less than 10%
market share), a majority of the iD users have a very small number of
edits and are non recurring contributors. This reflects itself in the
edit counts too where the ratio is ~2/3 JOSM and 1/3 id. Naturally JOSM
-currently- tends to get used for larger edits which is likely a major
factor. Given that P2 users are mostly long time OSM contributors that
edit regularly, a similar pattern can be seen, and I think that a one
time update at the proposed cost can easily be justified.

Now medium term, that is 1-2 years, this is likely going to change
substantially. iD is branching out in to more and more niches, reducing
the breathing space for anything else massively and other editor use has
effectively been stagnating for a long time. While people will
automatically try to start listing special use cases that can "only" be
done with editor XX, the problem is that these are special cases and
unlikely to be worth spending a couple of $100k on per year (virtually
or real) for the small number of users that will remain as iD gains more
and more features.

Simon




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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch

2020-08-02 Per discussione Richard Fairhurst

mmd wrote:
> I'm wondering if some of the changes that are now needed for AIR
> would make it more difficult to switch to Ruffle later on.

The short answer is (based on the POC work I've done so far) no. :)
The slightly longer answer is that I hope, as part of this project,
to make a number of changes that are not directly AIR-related but
will make P2 maintenance more sustainable into the future.

> I'm a bit worried about AIR being (too) difficult to install
> and run for an average Potlatch user, but that's just a gut feeling.

Couple of things here. One is that AIR isn't any more difficult to
install than Flash Player, but with the difference that it doesn't
break every time there's a browser upgrade and the browser
manufacturer tries to get you to switch it off. The other is that
2020's P2 users, contrary to the cliche of 2010, are actually pretty
skilled and experienced (by definition the beginner users use iD
these days) - many of them have a four-figure number of
changesets - so installing AIR shouldn't be beyond them.

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

Re: [Talk-pt] Padronização das localidades em Portugal

2020-08-02 Per discussione Alexandre Moleiro

Eu concordo com a proposta, notando que apenas nas Freguesias urbanas fará
sentido usar o neghbourhood.

Também há que levantar as questões de fundo:
-Haverá falta de tags para estes conceitos? Podem ser criadas? De certeza
já há discussão noutros países.
-Não fará sentido uma hierarquia com níveis, não se poderia usar a tag
admin_level também para places ?

Saudações
Alexandre

On Sat, 1 Aug 2020 at 22:02, Sílvio Matos  wrote:

>
> Boa noite. Gostaria de trazer uma discussão a este grupo de modo a tentar,
> de alguma forma, chegar a um consenso sobre o melhor padrão a usar em
> Portugal para a tag place=*.
>
> Neste momento, segundo a wiki, o padrão a usar é este:
> https://wiki.openstreetmap.org/wiki/File:Fluxograma_Localidades.png
>
> Este padrão, no entanto, não está a ser usado de maneira uniforme nas
> edições que os contribuidores têm feito.
> Em geral, a dúvida mais comum é como aglomerar 5 conceitos diferentes
> (capital de distrito/sede de município/cidade/vila/freguesia) em 3 tags
> possíveis (city/town/village).
> Neste momento e, segundo a wiki, a tag "city" está reservada a capitais de
> distrito, a tag "town" a todas as sedes de município, cidades e vilas, e a
> tag "village" a freguesias ou sedes de município que não sejam pelo menos
> vila (não conheço nenhum caso).
>
> Actualmente esta regra, se aplicada à risca, cria alguns casos caricatos.
> É fácil encontrar casos no Grande Porto e Grande Lisboa em que uma cidade
> tenha várias freguesias que são elas próprias cidades ou vilas. Num exemplo
> prático, a cidade de Vila Nova de Gaia partilhará a tag town com mais de
> uma mão cheia de freguesias do seu concelho, o que a nível de renderização
> pode trazer problemas - em zooms mais baixos/distantes Vila Nova de Gaia,
> apesar de cidade e sede de concelho, poderá desaparecer em favor de uma
> freguesia sua que seja vila.
>
> O que proponho é uma alteração à regra existente, de forma à divisão ser
> esta:
>
> Capital de Distrito? -> place = city
> Cidade ou Capital Administrativa de Município? -> place = town
> Vila ou Capital Administrativa de Freguesia (não urbana)? -> place =
> village
> Capital Administrativa de Freguesia (urbana)? -> place = neighbourhood
>
> Esta mudança efectivamente cria distinções entre cidades e vilas, ao mesmo
> tempo que preserva uma hierarquia em termos de divisões administrativas,
> sem criar casos caricatos como o acima descrito.
>
> Numa nota final, questiono se fará sentido despromover todas as sedes de
> freguesia para place=neighbourhood, por uma questão lógica. Não incluí essa
> distinção no caso acima, incluindo apenas as freguesias urbanas nessa tag,
> porque no contexto nacional a maioria das sedes de freguesia rurais têm
> efectivamente a identidade e contexto histórico de um povoado distinto, ao
> contrário da maioria (e aqui podemos argumentar) das sedes de freguesia
> urbanas, que são historicamente vistas como sendo parte integrante da
> cidade a que pertencem.
>
> Agradeço desde já a vossa participação nesta discussão, pois é necessário
> chegar a alguma conclusão neste tema, que já foi debatido várias vezes.
> ___
> Talk-pt mailing list
> Talk-pt@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-pt
>


-- 
Alexandre Moleiro
  alexandre.mole...@gmail.com
___
Talk-pt mailing list
Talk-pt@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-pt

Re: [OSM-talk] Proper use of route relations?

2020-08-02 Per discussione Yves via talk

Operator or network tags are often quoted for this kind of network. However I 
find it difficult not to wish for putting 'name=Boulder Valley Ranch Trails' 
somewhere, and a relation seems a good candidate.
  network:name=Boulder Valley Ranch Trails? But the network tag and its 
acronyms values make it quite technical at first sight.
Yves ___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Russ Garrett

On Sun, 2 Aug 2020 at 10:20, Andy Mabbett  wrote:
> Do you have a plausible hypothesis to explain the removal of UPRNs
> from the flood warning pages, that also gives us a reason to trust the
> organisation that enacted that change?

It's almost certainly because some lawyer or other spotted that it's a
violation of the PSGA (formerly PSMA) license under which the
AddressBase data is made available to the Environment Agency.

https://www.ordnancesurvey.co.uk/documents/licensing/psga-member-licence.pdf

There's no conspiracy here beyond OS zealously protecting its data, as
it always has done.

-- 
Russ Garrett
r...@garrett.co.uk

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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione mmd

On 2020-08-01 12:42, Richard Fairhurst wrote:
> Ruffle is showing promise (https://github.com/ruffle-rs/ruffle) and is
> under very active development, but does not yet support AS3 or the Flash
> Player features that P2 needs. I would anticipate that P2 will be able
> to run as WebAssembly when Ruffle reaches feature parity with AIR 2.6.

Yes, exactly, that's one of the two approaches I had in mind: rewriting
from scratch preferably also in Rust (which obviously wouldn't fit in
the proposed budget or timeframe), or use Ruffle with the existing code.

I'm wondering if some of the changes that are now needed for AIR would
make it more difficult to switch to Ruffle later on. I clearly see AIR
as some temporary solution to keep running even after Dec 2020, as long
as Ruffle isn't ready yet.

In a more mid-term, I really like to see a move away from such
proprietary platforms to an editor that runs in a browser
out-of-the-box. I'm a bit worried about AIR being (too) difficult to
install and run for an average Potlatch user, but that's just a gut feeling.

-- 

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

Re: [OSM-talk-fr] Parking fermé aux camping cars la nuit

2020-08-02 Per discussione osm . sanspourriel


Le 02/08/2020 à 10:45, Philippe Verdy - ver...@gmail.com a écrit :

Sauf que "dusk" et "dawn" sont aussi mal documentés et supportés. Et
donc pourquoi pas simplement "@night" au lieu des deux mots
"@(dusk-dawn)" ?


Parce que c'est ce qui est documenté ! Mais je suis d'accord, ça aurait
pu être plus simple sauf que "dusk" et "dawn" sont des limites utilisées.

https://taginfo.openstreetmap.org/search?q=dusk#values

Alors qu'on a plus de 50 000 dusk/dawn on n'a que :

118

traffic_signals:operating_times


off @ *night*



Supposons que l'interdiction de parking "la nuit" s'applique
réellement et est contrôlée, ce sera de toute façon en fonction des
horaires de travail plus que sur la nuit réelle.

J'aime cette supposition^^.

Des interdictions comme ça, sans horaire précis, ce n'est pas vraiment
valable...


Ça va "marcher" en fonction de la volonté du maire et des services
municipaux.

Aussi du comportement du voisinage : si à 3 h du mat' quelqu'un prend
une photo et la passe au policier municipal, l'excuse du café sera plus
difficile à faire valoir.

Si le campingcariste peut dire où il était pendant la nuit et s'il n'est
pas agressif, ça passera mieux.

Si ce n'est pas assez respecté, le maire pourra proposer des heures sup'
à un fonctionnaire. Quelles bonnes opération coup de poing et les
personnes iront passer la nuit "où que de droit".

Ceci dit, ce n'est pas parce que c'est peu appliqué et difficilement
applicable que ce n'est pas à mettre dans OSM. Sinon on va commencer à
supprimer pas mal d'informations : combien de bandes cyclables restent
occupées exclusivement par les occupants légitimes à Paris par exemple ?
Et avoir l'info des OSM est un moyen de faciliter le respect des règlements.

/Petite correspondance : Yves, ce n'est pas mooring=no !/

Jean-Yvon

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

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Andy Mabbett

On Sun, 2 Aug 2020 at 09:41, Nick  wrote:

> On 01/08/2020 21:19, Mark Goodge wrote:

> > I'm pretty certain this is deliberate, in order to stop people using
> > their site as a way to look up addresses from a UPRN. And I suspect
> > it's part of the same attempts by GeoPlace to deliberately minimise
> > the utility of the Open UPRN database.

> the current situation regarding openness leads
> to speculation and as Mark so clearly states to "deliberately minimise
> the utility of the Open UPRN database" - the risk is that this sort of
> speculation leads to a lack of trust

Do you have a plausible hypothesis to explain the removal of UPRNs
from the flood warning pages, that also gives us a reason to trust the
organisation that enacted that change?

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

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

Re: [OSM-talk] {Disarmed} Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Christian Quest


Le 01/08/2020 à 02:27, Guillaume Rischard a écrit :



  Hi all,

The OSMF Board wants to facilitate and support improving 
infrastructure. During the Microgrants process, there were proposals 
that didn’t make it, but would together be a good pilot for a “OSM 
infrastructure” process, to learn how supporting osm infrastructure 
projects works well.


The OSMF Board wants to fund a limited number of projects proposed by 
trusted long-term volunteers whose work we know and enjoy. We have 
selected the osm2pgsql and Potlatch microgrant proposals, and have a 
new proposal from Nominatim.


In the long term, we want to re-activate the Engineering Working Group 
(EWG) by making it a place for decision making, project guidance and 
budget management for such projects.


The Board would like your feedback on these three specific 
infrastructure projects:




Very good news !

Infrastructure is not only hardware and network, it's also code and 
humans to make all this run as smoothly as possible.


If enough funds are available for all project, they should all be funded.


For a long term view, helping new devs to get familiar with old code is 
a key to maintain legacy code when it still represent a large dependance 
in the infrastructure. By infrastructure I see the OSMF one, but also 
all the OSM ecosystem.



osm2pgsql is a good example of a key tool used by a lot of people (not 
only OSMF). We've seen recently with a single changeset causing failed 
updates how dependant a lot of people can be from that "old code". I'm 
also thinking the same about mod_tile/renderd, where maintenance seems 
minimal.


nominatim seems less broadly used, but it still is an important tool on 
OSMF web site.


potlatch... I don't really put it in the infrastructure, but if funds 
are available why not give it a few more years life even if a tiny 
portion of changesets are made with it.


--
Christian Quest - OpenStreetMap France

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

Re: [OSM-talk-fr] Parking fermé aux camping cars la nuit

2020-08-02 Per discussione Philippe Verdy

Sauf que "dusk" et "dawn" sont aussi mal documentés et supportés. Et donc
pourquoi pas simplement "@night" au lieu des deux mots "@(dusk-dawn)" ?

c'est vrai aussi que 20:00-08:00 c'est pas vraiment ça non plus pour
indiquer la "nuit" dont la durée varie sans arrêt dans l'année, mais aussi
n'est pas centrée de la même façon entre heure d'été et d'hiver. Ici ça
ressemble plus à un horaire en heure légale (d'été ou d'hiver),
correspondant aux horaires de travail de bureau en France (donc 4 heures
avant minuit et 8 heures après, le tout incluant un sommeil normal de 7-8
heures et au moins 1 heure au lever ; mais ce total de 12 heures, n'est pas
la durée de la "nuit" sauf aux équinoxes et n'est jamais centré non plus
sur la nuit réelle).

Supposons que l'interdiction de parking "la nuit" s'applique réellement et
est contrôlée, ce sera de toute façon en fonction des horaires de travail
plus que sur la nuit réelle. Mais ce sera verbalisé éventuellement s'il
fait effectivement nuit durant le contrôle. Ce genre de panneau de toute
façon est très contestable: supposons qu'un camping car arrive en hiver et
se gare le matin à 7h30 pour aller prendre un petit-déjeuner au chaud dans
un café. Mais c'est en hiver, il fait encore nuit mais "l'activité" est
déjà repartie, n'importe qui vient déjà utiliser le parking (y compris
d'autres clients du même café). Un policier arrive, voit le véhicule garé
et le verbalise lui seul parce que c'est un camping-car) ? Pour le
conducteur, il n'a pas compris le sens du mot "nuit", au sens où il n'est
pas resté la nuit sur le parking mais venait d'une aire de service, ou
roulait encore sur la route...
Des interdictions comme ça, sans horaire précis, ce n'est pas vraiment
valable...



Le sam. 1 août 2020 à 21:07,  a écrit :

> S'il n'y a pas d'horaires c'est que ça varie suivant l'époque de l'année.
>
> De plus Mo-Su c'est tous les jours donc inutile de préciser.
>
> Donc plutôt :
>
> *motorhome*:conditional=no @ (*d**usk**-dawn*).
>
> Ceci dit je doute qu'un logiciel s'en serve mais comme c'est une
> information classique sur les parkings des zones touristiques.
>
> Si les horaires avaient été précis ils auraient été simplifiables en
> 20:00-08:00.
>
> N. B. : je doute que JOSM aime mais tu peux ouvrir un ticket sur la
> validation si personne ne dit que c'est faux.
> Le 01/08/2020 à 17:00, Arnaud Champollion -
> arnaud.champoll...@linux-alpes.org a écrit :
>
> Bonjour,
>
> Pour un parking fermé aux camping cars la nuit (pas d'horaire précis) j'ai
> composé cet attribut :
>
> caravans:conditional=no @ (Mo-Su 00:00-08:00,20:00-24:00)
>
> en essayant de suivre cette page de wiki :
>
> https://wiki.openstreetmap.org/wiki/FR:Restrictions_conditionnelles
>
> ce qui donne :
>
> https://www.openstreetmap.org/way/643839038
>
> Je ne suis pas sûr de moi, en plus JOSM n'aime pas trop.
>
> Pouvez-vous regarder et me dire ce que vous en pensez ?
>
> Merci
>
> Arnaud
>
> ___
> 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
>
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] UPRN Locations Map

2020-08-02 Per discussione Nick

Personally, I don't think that classifying UPRNs (e.g. historic, parent, 
non-addressable etc.) nor publishing dynamically the allocations to the 
custodians of batches of UPRNs would detract from the commercial value 
derived by Ordnance Survey (OS). I fully understand that as a limited 
company, OS is perhaps less motivated to collaborate with the public. 
However, public bodies such as the Environment Agency surely have a 
broader responsibility to the public?


Why I get on my high horse about this is the knowledge that UPRNs and 
related data have errors but perhaps even more tragically, the lack of 
openness can lead to direct impact to people's lives. I also realise 
that the OSM Foundation is a non-profit organisation whose purpose is to 
support the OSM project - my reading is that this is technical rather 
than political. I also re-read Owen Boswarva's blog 
https://www.owenboswarva.com/blog/post-addr1.htm and end up feeling that 
the publishing of Open Data is a bit like the comment "When information 
is missing, we speculate about what the government might be hiding, or 
fill in the gaps with anecdotes." 
[https://www.theguardian.com/commentisfree/2020/apr/02/government-publish-data-coronavirus-deaths]


I therefore believe that the current situation regarding openness leads 
to speculation and as Mark so clearly states to "deliberately minimise 
the utility of the Open UPRN database" - the risk is that this sort of 
speculation leads to a lack of trust


On 01/08/2020 21:19, Mark Goodge wrote:



On 01/08/2020 20:24, Nick wrote:
As a follow up, Robert Whittaker also submitted an FOI asking for 
"... a list of all UPRNs that are classified as 'historic', and a 
separate list of all those classified as a 'parent' ". the 
logicto me was that this would help users of Open Data to then filter 
these out. The response that this was "exempt from disclosure under 
section 21 of the FOIA" - if you are interested follow the link to 
https://www.whatdotheyknow.com/request/lists_of_historic_and_parent_upr


In another move, the Environment Agency flood risk website no longer 
allows you to link directly to a property by UPRN. You used to be able 
to construct a link in this format:


https://flood-warning-information.service.gov.uk/long-term-flood-risk/risk?address=[uprn] 



But that no longer works. Now, you have to search by postcode, and 
when you select an address the site then sets a cookie which 
determines which property details you will be shown. And, checking the 
source of the postcode page, it no longer has the UPRN as a variable 
for each property. Instead, it's a simple sequential number. For 
example, if there are ten properties in a postcode, then the variables 
will be numbered 0 to 9.


I'm pretty certain this is deliberate, in order to stop people using 
their site as a way to look up addresses from a UPRN. And I suspect 
it's part of the same attempts by GeoPlace to deliberately minimise 
the utility of the Open UPRN database.


Mark

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


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

Re: [OSM-talk] Funding of three infrastructure projects : Nominatim, osm2pgsql, Potlatch 2

2020-08-02 Per discussione Richard Fairhurst

Skyler Hawthorne wrote:
> Sorry if this sounds harsh, but I think using any funds at all to
> continue support for a tool that 1% of editors use would be wasteful.
> Flash is, for all intents and purposes, a dead technology. This
> money is better spent on other uses.

The entire point is to move away from a dead technology (Flash Player) to a 
supported one (AIR).

On the percentage stat, it's worth bearing in mind that the P2 project is by a 
long chalk the smallest sum (€2500) of the three that OSMF is proposing here. 
As a point of comparison, iD was initially developed with a $575,000 grant from 
the Knight Foundation in 2012, so roughly $646,000 now. Very conservatively 
estimating the cost of employing 1-2 developers to code on iD since then, you 
get a development cost of roughly €0.004 per (2020) changeset for iD vs $0.0002 
for P2, which is kind of fun.

(I'm actually pleasantly surprised that P2 still has so many changesets - 20 
million last year, and I'm guessing high teens this year - given how difficult 
it is to get Flash Player running in most browsers these days. That suggests 
that P2's users are using it because they want to do so, not because they are 
magically unaware of the existence of other editors. I suspect if you could 
find another way of getting 20 million edits for €2500 then we would snap your 
hand off.)

Looking forward, and continuing the theme of ROI, the other benefit of the 
project is that it enables development work to continue on P2. The reason I 
have bid for funding for this, for the first time in 14 years of developing 
editors for OpenStreetMap, is that it will take a solid chunk of sustained work 
to do the AIR conversion and a bunch of other stuff I believe will make P2 more 
sustainable into the future, and there is a hard deadline for that sustained 
work (i.e. Flash Player switch-off at the end of the year). It's not a project 
that can just be done in evenings here and there. That enables further, 
unfunded developments in the future, and in turn I hope the tradition of other 
editors taking inspiration from P2 can continue - it's not for nothing that 
JOSM has a Potlatch 2 style and a "Potlatch mode" for editing.

But you are, of course, welcome to develop and put forward a project to OSMF 
which you believe will have more bang for the buck. "Other uses" is easy to 
type but doesn't actually mean anything until you identify what those uses are, 
and crucially, find someone who is prepared to do them.

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

Re: [OSM-talk] Proper use of route relations?

2020-08-02 Per discussione Mateusz Konieczny via talk




2 Aug 2020, 09:25 by dieterdre...@gmail.com:

>
>
> sent from a phone
>
>> On 2. Aug 2020, at 03:19, Warin <61sundow...@gmail.com> wrote:
>>
>> An indication that all these things are maintained by one organization?
>>
>
>
> there is the operator tag for this. Don’t use relations where tags can do the 
> trick...
>
+1
thiswould be using relations for
categories what is wrong___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSRM-talk] OSRM Decentralized

2020-08-02 Per discussione Nikhil VJ

Hi Folks,

Here are easy docker recipes for deploying your own OSRM instance for any
base area. And a live demo page where OSRM for different areas can be
brought together.

https://osrm-decentralized.github.io/


--
Cheers,
Nikhil VJ
https://nikhilvj.co.in
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk] Proper use of route relations?