Re: [OSM-dev-fr] Test Osmose-Mapillary

[Frédéric Rodrigo]

Le 10/07/2017 à 10:38, PanierAvide a écrit :

Bonjour,

Ça a dû être un sacré chantier pour faire ce rapprochement, les 
résultats sont pertinents donc bien joué !

En fait non ça a été facile. C'est le même outillage que pour l'OpenData.



Je me disais que ce type de corrections se prêterai bien à un 
challenge MapRoulette, et là je vois qu'Osmose propose déjà toutes 
sortes de fichiers à l'export... On vit à une époque formidable ;-) 
Hâte que ce soit disponible à une échelle plus large.



Moi aussi ! reste à convaincre Mapillary..


Cordialement,

Adrien.


Le 09/07/2017 à 19:53, Julien balas a écrit :

Le 08/07/2017 à 20:11, Frédéric Rodrigo a écrit :

Salut,

J'ai obtenu de Mapillary un mini dump du résultats de la détection des
panneaux dans la région de Rennes.

C'est rapproché des données OSM comme c'est fait avec de l'OpenData.

Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans
les données OSM.


cool, j'ai ajouté quelques stops



Comme ce n'est pas toujours simple j'ai pour l'instant limité à 
certains

types de panneau dont l'effet se traduit par un seul tag, ça essaye de
retrouver ce tag à proximité. La distance est variable en fonction du
panneau.


Mais il y a plusieurs problème:

- la localisation des panneaux est approximative


en effet, la rocade déborde jusque le long du chemin de halage ;)
https://www.mapillary.com/app/?lat=48.10593859663507=-1.7144116702545489=17=true=map%5B%5D=regulatory--maximum-speed-limit-70--g1 





- souvent dédoublé

- les panonceaux ne sont pas pris en compte

- pas différence entre un panneau d'application et un panneau 
d'approche


ca detecte parfois un peut trop aussi :)

- une vitesse de bus qui deviens une limitation
https://www.mapillary.com/app/?lat=48.1312010610244=-1.67386871309325=17=true=map%5B%5D=regulatory--maximum-speed-limit-90--g1 



- ça remonte aussi bien des problèmes dans OSM que des problèmes 
dans la

reconnaissance des panneaux (on peut marquer les faux positif dans
Mapillary ?)


Je n'ai pas trouvé, mais je connais mal mapillary.



On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou
leur effets.


http://dev.osmose.openstreetmap.fr/en/map/#item=8300=true=14=48.12522=-1.67435=Mapnik=T 



En tout cas c'est prometteur.

Est ce que dans mapillary l'icone de hauteur est générique ?
si non les hauteurs ne sont pas toujours détectées (3.1 au lieu de 2.5)
https://www.mapillary.com/app/?lat=48.12780824036=-1.683399190456=17=true=map%5B%5D=regulatory--height-limit--g1=wuf09rJKjlpb2F_78Lv6YA=0.5091192026214278=0.515137058569636=0 




ps : si le lien mapillary etait cliquable dans osmose ca serait top!

Merci de ton travail.




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




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

Re: [OSM-dev] Andy Allan joining web site maintainers

[Tom Hughes]

On 10/07/17 13:25, Matthijs Melissen wrote:

On 10 July 2017 at 11:14, Andy Allan  wrote:

Thanks Tom. My intentions for the next few months are to continue to
do whatever I can to encourage new contributors. I've done a lot of
refactoring recently which will help whoever tries to make code
changes, but there's other things I think I can do too.


Currently, the openstreetmap-website is both responsible for the
openstreetmap.org web application, and for the API.

How hard would it be to separate these two functions, perhaps even
into two projects?


That's exactly what we're working on with cgimap.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

Re: [OSM-dev] Andy Allan joining web site maintainers

[Matthijs Melissen]

On 10 July 2017 at 11:14, Andy Allan  wrote:
> Thanks Tom. My intentions for the next few months are to continue to
> do whatever I can to encourage new contributors. I've done a lot of
> refactoring recently which will help whoever tries to make code
> changes, but there's other things I think I can do too.

Currently, the openstreetmap-website is both responsible for the
openstreetmap.org web application, and for the API.

How hard would it be to separate these two functions, perhaps even
into two projects?

Would there be any advantages in doing so? Intuitively both functions
seem to be separate projects. I could imagine having two smaller
applications might make maintenance easier. It would also mean we
could, for example phase Ruby out for the app but not for the api or
vice versa. Lastly, making the website make only use of well-defined
api endpoints instead of interface with the database directly might
also makes things clearer.

Have there been any thoughts in this direction?

-- Matthijs

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

Re: [OSM-dev] Andy Allan joining web site maintainers

[Martin Koppenhoefer]

sent from a phone

> On 10. Jul 2017, at 11:48, Frederik Ramm  wrote:
> 
> It could be a low-hanging fruit
> to create feature parity between website and API at least in some areas.


+1, few people know you can request specific versions like the previous one, 
with big objects often running in timeout for the full history it would be 
convenient to offer a link to the previous version rather than the full history 
or after a timeout occurred.

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

Re: [OSM-dev] Andy Allan joining web site maintainers

[Frederik Ramm]

Hi,

On 10.07.2017 11:14, Andy Allan wrote:
> My intentions for the next few months are to continue to
> do whatever I can to encourage new contributors. 

I think it would be helpful for new contributors if the following two
points could be explained:

* What kinds of changes to the API are acceptable while still being "API
0.6"? Is anything that adds new API calls automatically on hold until we
do "0.7", or should we just refrain from breaking existing API calls?

One reason I'm asking this is that there's a bunch of things that have
an API call but are not accessible through the web site (e.g. "show me a
specific version of this object" - website has just full history or
latest), and vice versa (web site can show all changesets by a given
user, but no API call exists for that). It could be a low-hanging fruit
to create feature parity between website and API at least in some areas.
Maybe this is even on some mental roadmap somewhere - I heard people
talking about making the web site actually *use* API calls, rather than
accessing the database directly.

* What is the relationship between "cgimap" and the web site, and in how
far are contributions that touch an area handled by "cgimap" required to
cover both the C++ and the Rails implementation?

One reason why this is of interest to me is that I'm still very much
interested in being able to access deleted objects through the API and
through the web site. I've made a few half-baked attemtps at
implementing that in the past
(https://github.com/woodpeck/openstreetmap-cgimap/tree/deleted_call,
https://github.com/woodpeck/openstreetmap-website/tree/browse-deleted-objects)
and would appreciate guidance of how to "do this right", if at all
possible within the constraints of "0.6".

Bye
Frederik

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

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

Re: [OSM-dev] Andy Allan joining web site maintainers

[Andy Allan]

On 22 June 2017 at 21:15, Tom Hughes  wrote:
> I'm pleased to be able to invite you all to join me in welcoming Andy Allan
> as the new co-maintainer on the code base for the OpenStreetMap web site.
>
> Going forward we intend to look to add additional maintainers to further
> diversify and spread the load, so we will be actively looking for candidates
> among those working on the code base.
>
> Please continue to open issues and pull requests on GitHub as before.

Thanks Tom. My intentions for the next few months are to continue to
do whatever I can to encourage new contributors. I've done a lot of
refactoring recently which will help whoever tries to make code
changes, but there's other things I think I can do too. So it will
likely be a combination of:

* My own refactoring priorities, which will pay off for developers in
the long term but aren't very visible to most people.
* Working through the PR and issue backlogs, to try and help some
straightforward things get "over the line" - hopefully motivating for
developers.
* Work on a few end-user facing tasks, so that we're making visible progress.

Thanks,
Andy

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

Re: [OSM-dev-fr] Test Osmose-Mapillary

[PanierAvide]

Bonjour,

Ça a dû être un sacré chantier pour faire ce rapprochement, les 
résultats sont pertinents donc bien joué !


Je me disais que ce type de corrections se prêterai bien à un challenge 
MapRoulette, et là je vois qu'Osmose propose déjà toutes sortes de 
fichiers à l'export... On vit à une époque formidable ;-) Hâte que ce 
soit disponible à une échelle plus large.


Cordialement,

Adrien.


Le 09/07/2017 à 19:53, Julien balas a écrit :

Le 08/07/2017 à 20:11, Frédéric Rodrigo a écrit :

Salut,

J'ai obtenu de Mapillary un mini dump du résultats de la détection des
panneaux dans la région de Rennes.

C'est rapproché des données OSM comme c'est fait avec de l'OpenData.

Ça signalement donc quand l'effet d'un panneau n'est pas retrouvé dans
les données OSM.


cool, j'ai ajouté quelques stops



Comme ce n'est pas toujours simple j'ai pour l'instant limité à certains
types de panneau dont l'effet se traduit par un seul tag, ça essaye de
retrouver ce tag à proximité. La distance est variable en fonction du
panneau.


Mais il y a plusieurs problème:

- la localisation des panneaux est approximative


en effet, la rocade déborde jusque le long du chemin de halage ;)
https://www.mapillary.com/app/?lat=48.10593859663507=-1.7144116702545489=17=true=map%5B%5D=regulatory--maximum-speed-limit-70--g1 





- souvent dédoublé

- les panonceaux ne sont pas pris en compte

- pas différence entre un panneau d'application et un panneau d'approche


ca detecte parfois un peut trop aussi :)

- une vitesse de bus qui deviens une limitation
https://www.mapillary.com/app/?lat=48.1312010610244=-1.67386871309325=17=true=map%5B%5D=regulatory--maximum-speed-limit-90--g1 




- ça remonte aussi bien des problèmes dans OSM que des problèmes dans la
reconnaissance des panneaux (on peut marquer les faux positif dans
Mapillary ?)


Je n'ai pas trouvé, mais je connais mal mapillary.



On pourrait aussi chercher à cartographier les panneaux eux mêmes et/ou
leur effets.


http://dev.osmose.openstreetmap.fr/en/map/#item=8300=true=14=48.12522=-1.67435=Mapnik=T 



En tout cas c'est prometteur.

Est ce que dans mapillary l'icone de hauteur est générique ?
si non les hauteurs ne sont pas toujours détectées (3.1 au lieu de 2.5)
https://www.mapillary.com/app/?lat=48.12780824036=-1.683399190456=17=true=map%5B%5D=regulatory--height-limit--g1=wuf09rJKjlpb2F_78Lv6YA=0.5091192026214278=0.515137058569636=0 




ps : si le lien mapillary etait cliquable dans osmose ca serait top!

Merci de ton travail.




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