Re: [OSM-talk] The end of waterway map

[François Lacombe]

Hi Amanda,

Thank you for this additional piece of very useful tool :)

> WWM/ends excludes canals.
It's ok but it includes pressurised waterways and these nodes are flagged
as ends : https://www.openstreetmap.org/node/2255728449/
I'd like to include canals instead of removing pressurised waterways (which
connect to upstream rivers and it could lead to other mistaken ends too).

Isn't this an opportunity to check the appropriate usage of inlet/outlet
values and man_made=outfall as well?
https://wiki.openstreetmap.org/wiki/Key:inlet
https://wiki.openstreetmap.org/wiki/Key:outlet
https://wiki.openstreetmap.org/wiki/Tag:man_made%3Doutfall

Best regards

François

Le lun. 29 janv. 2024 à 21:04, Amanda McCann  a
écrit :

> I've added a new feature to [WaterwayMap.org: A map showing where
> waterways end](https://waterwaymap.org/ends/), i.e. a map of the
> ends-of-waterways 🙂.
>
> It shows nodes which are “the end” of a waterway, i.e. where the water
> can't go anywhere else. Uniquely, it calculates the total upstream length
> of waterway ways which end at a point. It uses the direction of OSM ways,
> and how they are connected. This should make larger mistakes more visible.
> Like the rest of WaterwayMap.org, data is updated daily, at the same time.
>
> It's normal for there to be ends, like when a river ends at a coastline.
> This will rightly show up on WWM:Ends. When a river empties into a lake,
> this will also show up, unless we've mapped a waterway through the lake.
> There's [active discussion](
> https://community.openstreetmap.org/t/should-river-lines-be-mapped-through-lakes-estuaries-gulfs-and-other-large-water-bodies/104438)
> on when & how to do that.
>
> # Merging & Splitting
>
> When 2+ waterways come together, the upstream value is added together.
> When 2+ waterways split, the upstream value is split equally. This mostly
> works well, e.g. when a river splits through a side channel, and then
> rejoins.
>
> If you have a small stream going into a large river, and it's in the wrong
> direction, then half the upstream value from the big river will go off to
> the side stream. This is a mapping mistake, and this tool makes it easier
> to find them. e.g. [way 962171457](
> https://www.openstreetmap.org/way/962171457/history) is mapped as flowing
> *out* of the Nile, so it's taking 17,000 km of upstream away! [on
> `wwm/ends`](https://waterwaymap.org/ends/#map=13.8/17.96527/33.98571).
> This direction should probably be reversed.
>
> Conversely, [this way](
> https://www.openstreetmap.org/way/67963223#map=19/52.66517/-8.62906) is
> taking half (930 km) of the Shannon [wwm/ends](
> https://waterwaymap.org/ends/#map=15.34/52.66393/-8.627153). I don't
> think this should count as an “end”, but the mapping looks ok. WWM/ends
> excludes canals. I'm unsure if it's possible to calculate the right value.
> Perhaps more advanced tag calculations. What do yous think?
>
> I hope you enjoy this new map & we all improve OSM together. 🙂
>
> # See also
>
>  • a short description of [how it works](
> https://waterwaymap.org/ends/help/).
>  • [News about WaterwayMap.org](
> https://en.osm.town/@amapanda/tagged/WaterwayMapOrg) can be found on
> Mastodon/Fediverse (incl. [Atom/RSS feed](
> https://en.osm.town/@amapanda/tagged/WaterwayMapOrg.rss)):
>  • This code is on Github: [`amandasaurus/waterwaymap.org`](
> https://github.com/amandasaurus/waterwaymap.org). [New issue reports](
> https://github.com/amandasaurus/waterwaymap.org/issues) are welcome.
>  • The programme which generates it is [`osm-lump-ways`](
> https://github.com/amandasaurus/osm-lump-ways)
>
> --
> Amanda
>
> ___
> 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] Quality and the Openstreetmap value chain

[François Lacombe]

Hi Jean-Marc,

Long time no see!

Le mer. 13 mai 2020 à 17:08, Jean-Marc Liotier  a écrit :

> On 5/12/20 3:50 PM, Colin Smale wrote:
>
> The role I expect of the data consumers is to articulate how they would
> like to view the data (including what attributes they are expecting), and
> not to dictate how that data is stored/represented internally. Cartography,
> geography, statistics etc are very different skills to data modelling and
> database design.
>
> Indeed, technical implementations take functional requirements into
> account but have many other inputs and a different class of actors.
> Consumers, tell us what you want - not how to do it ! Same as any software
> project...
>
As a data consumer, telling you what I want directly often relates to how
tagging is built as I consume raw osm data without filters or
transformation done by any API (and that's fortunate).

"Same as any software project"
Corporate software projects can be designed to preserve silos and
inefficiency due to any so-called-valid excuse of dysfunctional middle
management (rude, but... change my mind)
OSM is a good opportunity to change practices and show some solutions that
would be really hard to provide at company scale.
So, respectably no, not like any software project please.

All the best

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

Re: [OSM-talk] New diary: 10 years of French power transmission network mapping

[François Lacombe]

You're welcome Christine :)

I'll try to setup some viz tool which use network topology. This is kind of
occupation during current lockdown ;)
Such tool would be interesting to investigate quality issues beside
warnings from osmose as well in a few months

All the best

François

Le lun. 20 avr. 2020 à 00:40, Christine Karch  a
écrit :

> Chapeau and thank you for that interesting work and the documentation!
>
> Am 20.04.20 um 00:25 schrieb François Lacombe:
> > Hi all,
> >
> > This link to look back at 10 years of mapping of French power
> > transmission network
> > https://www.openstreetmap.org/user/InfosReseaux/diary/392777
> >
> > OSM demonstrates a large potential to improve official opendata and
> > bring valuable data back to operators.
> > Official opendata brings real situations inspiring our tagging model.
> > This article was originally posted in French on OSM France website last
> > week.
> > Find dedicated render on OpenInfraMap :
> > https://openinframap.org/#5.64/46.723/2.944
> >
> > Hope to see this continuing in coming years. Thank you all to make this
> > possible :)
> >
> >
> > Best regards
> >
> > François
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
>
>
> ___
> 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] Fwd: Re[2]: Tag:manhole=telecom

[François Lacombe]

Given problem is you argue with pictures showing what is under the cap.
On the tag page picture - and on the ground - we can't say what is under
and if a man can't get down a ladder into a room.

I think all this stuff would require a formal proposal to discuss about
vocabulary and have opinions of several people.
We need standard definitions more than legal actually.

All the best

Le lun. 20 avr. 2020 à 01:02, <80hnhtv4a...@bk.ru> a écrit :

> I am trying to say the tag page is wrong,
> https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> the picture is a fiber optics splice enclosure not a manhole
>
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
> https://www.thefoa.org/tech/ref/appln/Prefab-underground.jpg
>
> this is a fiber splice manhole,
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
> can we change the picture or put both on the same page with the legal
> industry names.
> https://www.lexico.com/en/definition/manhole
> ( a man goes into the hole) [manhole]
>
>
>
> Sunday, April 19, 2020 5:02 PM -05:00 from François Lacombe <
> fl.infosrese...@gmail.com>:
> To me, manhole applies in the two situations.
> We should make a distinction between the "cap" visible from the surface
> and the facility underground.
> Same shape of "cap" (I call it the manhole actually) can hide really
> different kind of stuff underground you won't be able to define without
> removing the cap.
> In OSM, most mappers will only be able to describe what is visible on
> surface. So this distinction would really be valuable.
> When I look for "cable manhole" in google, I see both pavement and road
> manholes.
> Then I found this :
> https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html
> The body below surface, buried underground would be called a "cable room".
> All the best
> François
>
> Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk <
> talk@openstreetmap.org
> > a écrit :
>
>  this is an enclosure just put in the ground, level 3 fiber.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
>
> this is a manhole, ameritech, a t & t.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
>
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
>
> Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer <
> t.pfei...@computer.org>:
> Dear 80hnhtv4agou,
> As OpenStreetMap is a worldwide project, we have to agree on a tagging
> scheme for an object that
> is worldwide comprehensible.
> We prefer to use the same tag for the same kind of thing.
> Thus we prefer not to introduce synonyms or regional variations.
> To make a feature be found more easily, "related terms" can be added in
> the wiki.
> In the particular case, some friendly colleague has already added ‹buried
> cable enclosure›
> to the manhole=telecom wiki page.
> Kind regards
> Tom
>
> On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
> > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> > in the united states this is not what it is called, so it was hard for
> me to find to use.
> > can the name be changed.
> >
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> > to what it is ?
> ___
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] New diary: 10 years of French power transmission network mapping

[François Lacombe]

Hi all,

This link to look back at 10 years of mapping of French power transmission
network
https://www.openstreetmap.org/user/InfosReseaux/diary/392777

OSM demonstrates a large potential to improve official opendata and bring
valuable data back to operators.
Official opendata brings real situations inspiring our tagging model.
This article was originally posted in French on OSM France website last
week.
Find dedicated render on OpenInfraMap :
https://openinframap.org/#5.64/46.723/2.944

Hope to see this continuing in coming years. Thank you all to make this
possible :)


Best regards

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

Re: [OSM-talk] Fwd: Re[2]: Tag:manhole=telecom

[François Lacombe]

To me, manhole applies in the two situations.

We should make a distinction between the "cap" visible from the surface and
the facility underground.
Same shape of "cap" (I call it the manhole actually) can hide really
different kind of stuff underground you won't be able to define without
removing the cap.
In OSM, most mappers will only be able to describe what is visible on
surface. So this distinction would really be valuable.

When I look for "cable manhole" in google, I see both pavement and road
manholes.
Then I found this :
https://www.archiexpo.com/prod/dakota-group/product-150519-1693688.html

The body below surface, buried underground would be called a "cable room".

All the best

François

Le dim. 19 avr. 2020 à 23:14, 80hnhtv4agou--- via talk <
talk@openstreetmap.org> a écrit :

>  this is an enclosure just put in the ground, level 3 fiber.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/4KIBU1qe2CfjtcKtPHegeg/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587328637&Signature=8%2FzNiW16zbU9FjWy0JD17cNwIns%3D
> https://www.thefoa.org/tech/ref/install/Microtrenching/Pages/25.html
>
> this is a manhole, ameritech, a t & t.
>
> https://s3-eu-west-1.amazonaws.com/mapillary.private.images/dSk9MhzCx0L0AAFzD-WqYQ/uploaded.jpg?AWSAccessKeyId=AKIAR47SN3BMII5SHG7V&Expires=1587329086&Signature=o%2F0CqAKQC1ltl0F2vCqXVIecRP4%3D
>
>
> https://www.jensenprecast.com/AT-T-Northern-California-a840/Telecom-Utility-Structures/Manholes-p14890/AT-T-4-x4-x4-fiber-optic-Intercept-Manhole-Page-1-of-2-d2315.pdf
>
>
> Sunday, April 19, 2020 3:06 PM -05:00 from Tom Pfeifer <
> t.pfei...@computer.org>:
>
> Dear 80hnhtv4agou,
>
> As OpenStreetMap is a worldwide project, we have to agree on a tagging
> scheme for an object that
> is worldwide comprehensible.
>
> We prefer to use the same tag for the same kind of thing.
>
> Thus we prefer not to introduce synonyms or regional variations.
>
> To make a feature be found more easily, "related terms" can be added in
> the wiki.
>
> In the particular case, some friendly colleague has already added ‹buried
> cable enclosure›
> to the manhole=telecom wiki page.
>
> Kind regards
> Tom
>
> On 19.04.2020 17:20, 80hnhtv4agou--- via talk wrote:
> > https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
> >
> > in the united states this is not what it is called, so it was hard for
> me to find to use.
> >
> > can the name be changed.
> >
> >
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
> >
> > to what it is ?
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
> --
>
>
>
> ___
> 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] Tag:manhole=telecom

[François Lacombe]

Hi

To me there are two separate concepts :
* The enclosure : the underground chamber hosting several equipment
including cable splices
* The manhole : The way technicians get into the enclosure.

For smaller ones, the manhole has the same dimension than enclosure but
there are bigger ones where human can get into.

Then, what do you want to map?

All the best

François

Le dim. 19 avr. 2020 à 17:23, 80hnhtv4agou--- via talk <
talk@openstreetmap.org> a écrit :

> https://wiki.openstreetmap.org/wiki/Tag:manhole=telecom
>
> in the united states this is not what it is called, so it was hard for me
> to find to use.
>
> can the name be changed.
>
>
> https://www.multicominc.com/product/pencell-pem-2436-24x36x24-buried-cable-enclosure/
>
> to what it is ?
>
>
> ___
> 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] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

[François Lacombe]

Hi all

My 2cts : "in use" status and statuslink to the import proposal would be
enough, right?
Point is to determine where does the tag come from, and it's done by
statuslink, not status which reflect the current state of use.

All the best

François

Le mar. 17 mars 2020 à 10:55, Warin <61sundow...@gmail.com> a écrit :

> On 17/3/20 8:22 pm, Marc M. wrote:
>
> Hello Joseph,
>
> it may give the impression that this is the way it should be done.
> I agree to identify these "Noise" or poor quality tags, but with a
> keyword to show that it's a problem. e.g. status=bad, disputed, error, ...
> it would be necessary to find a word that is not as strong as error,
> but which nevertheless clearly indicates that this is not an example to
> follow.
>
>
>
> Agree with both.
>
> Possible values?
>
> obsolete
>
> abandoned
>
> discarded
>
>  <https://www.collinsdictionary.com/dictionary/english-thesaurus/forsaken>
>
> archaic
>
> passe
>
> stale
>
>
>
> <https://www.collinsdictionary.com/dictionary/english-thesaurus/forsaken>
> ___
> 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] Acknowledgement for the wiki documentation

[François Lacombe]

Hi Daniel,

Thank you for your message, very encouraging to provide high quality of
documentation
Even if it consumes high amount of time sometimes

Translations are important also, great to see people involved in this :)

All the best

François

Le sam. 8 févr. 2020 à 22:22, Daniel Capilla  a écrit :

> Hi,
>
> I've been working on the translation of the wiki into Spanish for a long
> time, both creating new translations and updating the translations that
> become obsolete. In all this time I have been able to check the
> evolution of some pages of documentation in English, the way in which
> they have expanded in content over time and clarifying cases of use of
> tags that could be confusing initially.
>
> I have sent this message to the mailing list just to thank all users and
> contributors who help documenting the use of tags, projects, mappers'
> guides and other documentation pages on the OSM Wiki. It is an important
> work, a much appreciated and very valuable effort.
>
> Thanks to all of you!
>
> Greetings from Spain.
>
> Regards,
>
> Daniel
>
>
> ___
> 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] Deleting template parameters copied to data items

[François Lacombe]

Hi Frederik

Le ven. 17 janv. 2020 à 16:05, Frederik Ramm  a écrit :

> Over the years, a couple of people have time and time again suggested
> that we get down and make a nice, curated, text-based catalogue of tags
> maintained by a team, potentially on a git-like system where pull
> requests can be submitted by everyone, but maintainers have to approve
> them.
>
> I was always on the fence about this, because it would install a
> maintainer team with more powers than the average user. But in the face
> of a wiki that is more and more moving into a direction where you need
> to have a degree in Wikidata to even participate, and where anything you
> contribute will be mowed over three times by this bot and that bot in
> order to fit into some structure that someone else has devised with
> practically zero community oversight, I think I'll prefer the git-based
> human-readable "tag atlas".
>

Could you please elaborate a bit more on why by human for human is the only
thing that exists in our landscape?
Don't we have tools that actually rely on that documentation to work and we
should take care of this as well?

In a really practical approach, I'm fed up to maintain sync in dozen of
translated pages containing the exact same template with the exact same
information.
DataItems would keep anyone able to document the tag as we do now instead
of a centralised git system with pull requests.
It's ok to say that as any brand new thing it will require further
development to be perfect. IMHO my contributions are more usable and
efficient on items than on many-same-wikitemplates.

OSM semantics and tagging model are also a thing and delivering it in a
structured database could make it usable at a really larger scale than now.
It's more about organizing knowledge than human readable documentation.
Time is short to make both in separates repositories.

Best regards

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

Re: [OSM-talk] French OpenData improvements for distribution power networks

[François Lacombe]

Hi Joseph,

It's not currently planned to automatically import all of this into OSM
(hopefully)
The main point is to bring data that enable contributors to go look on
ground or solve aerial imagery lacks.

Integrate 800k substations on existing buildings can't be done
automatically and will last many years I think (public dataset currently
don't contains a distinction between buildings and street cabinet for
instance)
Just like transmission underground power cables, geometries of distribution
lines and cables will have to be reworked to match aerial imagery or to be
connected to relevant supports.
We achieve this manually for now and OSM survey tradition brings high value
to publicly available data.

Further figures regarding transmission network will be available in coming
weeks

All the best

François

Le sam. 21 déc. 2019 à 01:51, Joseph Eisenberg 
a écrit :

> I imagine you are following the import guidelines?
>
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct
>
> - Joseph Eisenberg
>
> On 12/21/19, François Lacombe  wrote:
> > Hi all
> >
> > I'd like to let you know about a recent and good opendata improvement in
> > France regarding power networks we use to map in OSM.
> > Two biggest distribution grid operators in metropolitan France, Enedis
> and
> > Geredis, had released under Open License both overhead and underground
> > network maps
> >
> > You may browse them here
> > https://www.enedis.fr/cartographie-des-reseaux-denedis
> > http://www.geredis.fr/open-data
> >
> > I've been involved in this seek of open data for years and found key
> > insiders that understood the benefits of opening their datasets. Until
> now,
> > community had pushed approx 800k poles and dozen of thousand km of
> overhead
> > lines to convince operators it makes sense to check GIS against ground
> data
> > and make it freely available.
> > As a result, 800k distribution substations are now processed by osmose to
> > enable anyone to integrate them directly on appropriate buildings
> >
> > It's not the first time such efforts are made. Power substations imports
> > has been seen in Poland recently and maybe in other countries which is
> good
> > news.
> >
> > This complete the already available overhead/underground French
> > transmission grid map released by RTE in early 2017
> >
> https://opendata.reseaux-energies.fr/explore/dataset/lignes-souterraines-rte/map/?disjunctive.etat&disjunctive.tension&location=15,43.31032,5.38377&basemap=f91575
> >
> > Finally, there is still approximately 100 DSO companies remaining to
> > convince to join this effort. They cover less than 5% of metropolitan
> land
> > (for ~200k subscribers) to reach 100% of existing networks.
> >
> > All the best
> >
> > François
> >
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] French OpenData improvements for distribution power networks

[François Lacombe]

Hi all

I'd like to let you know about a recent and good opendata improvement in
France regarding power networks we use to map in OSM.
Two biggest distribution grid operators in metropolitan France, Enedis and
Geredis, had released under Open License both overhead and underground
network maps

You may browse them here
https://www.enedis.fr/cartographie-des-reseaux-denedis
http://www.geredis.fr/open-data

I've been involved in this seek of open data for years and found key
insiders that understood the benefits of opening their datasets. Until now,
community had pushed approx 800k poles and dozen of thousand km of overhead
lines to convince operators it makes sense to check GIS against ground data
and make it freely available.
As a result, 800k distribution substations are now processed by osmose to
enable anyone to integrate them directly on appropriate buildings

It's not the first time such efforts are made. Power substations imports
has been seen in Poland recently and maybe in other countries which is good
news.

This complete the already available overhead/underground French
transmission grid map released by RTE in early 2017
https://opendata.reseaux-energies.fr/explore/dataset/lignes-souterraines-rte/map/?disjunctive.etat&disjunctive.tension&location=15,43.31032,5.38377&basemap=f91575

Finally, there is still approximately 100 DSO companies remaining to
convince to join this effort. They cover less than 5% of metropolitan land
(for ~200k subscribers) to reach 100% of existing networks.

All the best

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

Re: [OSM-talk] Wiki templates and DataItems

[François Lacombe]

Hi Yuri,

Le ven. 22 nov. 2019 à 18:31, Yuri Astrakhan  a
écrit :

> I would love to fully transition to data items, as it would make
> translation and cross-language tag consistency far easier.
>

So am I!


> We now have a data item editor you can enable by going to preferences /
> gadgets, and enabling it.
>
This is a great improvement. It make the edition easier and may convince
more users to move towards data items.

I don't understand why WEF links between Key and Tag give the same editor
when used on a tag page?

The biggest need in short term regards TagInfo, which currently can't catch
the benefits of dataitems
It requires Ruby capabilities to help, but I'm not enough knowledgeable of
this language I'm afraid.

All the best

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

[OSM-talk] Wiki templates and DataItems

[François Lacombe]

Hi all,

It's been a while we use to complete templates KeyDescription and
ValueDescription on wikipages which are then crawled by a bot completing
DataItems
https://wiki.openstreetmap.org/wiki/Data_items

According to topics like : https://github.com/taginfo/taginfo/issues/263
and last SOTM discussions, there is still a lack of consensus about
DataItems usage.

Where are we going now?
Is there something else than consensus, TagInfo and mainstream editors
connectors missing preventing us to move?

I find DataItems really relevant to tackle the translation challenge, just
like WIkipedia did with WikiData.
Editors and QA could take a great advantage to get data from standard
properties instead of parsing wikicode, couldn't you?

All the best

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

Re: [OSM-talk] Split power netorks mapping project in two: networks and generation

[François Lacombe]

Hi everyone,

So it's now live on wiki :
https://wiki.openstreetmap.org/wiki/Power_generation
https://wiki.openstreetmap.org/wiki/Power_networks

Each page has links to relevant local project pages about generation or
networks respectively.

I've merged some subpages to the corresponding local page in the same time
as they were more a chapter in the whole project than requiring a dedicated
page.
There is still a lot of cleanup or writing to do on every page which
everyone is encouraged to spent a little time on it.

Anyway WikiProject_ prefix has been wiped out for those two.

All the best

François

Le dim. 1 sept. 2019 à 15:12, François Lacombe 
a écrit :

> Hi all
>
> Please find here a proposal to split the page WikiProject_Power_networks
> (and local ones too) in two on wiki
>
> https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Power_networks#Split_networks_and_power_generation
>
> Activities could be easily split since you can map power generation
> facilities without have a concern about networks (e.g see recent UK solar
> power mapping)
>
> For instance :
> https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France =>
> network + generation
> https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/Tanzania
> => network only
>
> https://wiki.openstreetmap.org/wiki/Norway/Norwegian_Infrastructure_networks
> => network + generation
>
> How do you feel about this point?
> Without further objections, I'll make the split in 15 days
> No change in meanings and no loss of documentation.
>
> All the best
>
> François
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Split power netorks mapping project in two: networks and generation

[François Lacombe]

Hi all

Please find here a proposal to split the page WikiProject_Power_networks
(and local ones too) in two on wiki
https://wiki.openstreetmap.org/wiki/Talk:WikiProject_Power_networks#Split_networks_and_power_generation

Activities could be easily split since you can map power generation
facilities without have a concern about networks (e.g see recent UK solar
power mapping)

For instance :
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/France =>
network + generation
https://wiki.openstreetmap.org/wiki/WikiProject_Power_networks/Tanzania =>
network only
https://wiki.openstreetmap.org/wiki/Norway/Norwegian_Infrastructure_networks
=> network + generation

How do you feel about this point?
Without further objections, I'll make the split in 15 days
No change in meanings and no loss of documentation.

All the best

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

[OSM-talk] Comparing INSPIRE and OpenStreetMap data conference paper

[François Lacombe]

Hi all,

Noticed this content today, I don't think this has already been posted
here. If not, sorry for noise.

People of JRC (Joint Research Center) from European Commission released a
research paper about conflating the two approaches of INSPIRE (European
public data) and OSM.
https://www.int-arch-photogramm-remote-sens-spatial-inf-sci.net/XLII-4-W14/167/2019/

It gives many insights of usability and accessibility of data in the two
worlds from user perspective which is really interesting - for instance -
to drive change and improvement policies.
I don't made any conclusion from it for now, it may be interesting to
discuss about that.

A talk about it will be given tomorrow at FOSS4G conference.
https://twitter.com/MarcoMinghini/status/1166255122827157504?s=20

All the best

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

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[François Lacombe]

Le lun. 10 juin 2019 à 18:54, Yuri Astrakhan  a
écrit :

> Thank you François!  The bot is very cautious - it will not touch anything
> that users have edited
>

That's ok for this Yuri, thanks

Le lun. 10 juin 2019 à 19:03, mmd  a écrit :

> This idea was recently discussed on Slack US #id channel. To quote Bryan
> on this: "We will never use the wikibase for our presets, sorry".
>
> See: https://osmus.slack.com/archives/CBK3JLUJU/p1556725015059000

Consistent with what he answers me about validaton rules on iD
https://github.com/openstreetmap/iD/issues/6206#issuecomment-487230605

Caution would be understandable regarding an upcoming feature in
production, but "never" is too strong to me.

Wait and see.

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

Re: [OSM-talk] Wikibase items instead of usual templates for wiki pages?

[François Lacombe]

Hi Yuri

First of all, Data Items are great add to OSM wiki and as said this already
brought real benefits.
Count on my support to go further with them.

Le lun. 10 juin 2019 à 18:38, Yuri Astrakhan  a
écrit :

> (please fix them in the wiki pages in the corresponding languages, the bot
> will automatically update the data items)
>

What if we update data items directly?
Will the modification be overwritten by outdated information of wikipages
or will wikipages be updated according to edit dates?

All the best

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

Re: [OSM-talk] FCC public documents license and submarine cables mapping

[François Lacombe]

 Hi all

Well, these are great inputs so thank you

I agree that the document were committed by Google to FCC.

Le dim. 14 avr. 2019 à 10:51, Kathleen Lu via talk 
a écrit :

>
> For Berne counties, I think it technically depends on where the
> "infringement" takes place, whatever that would mean in this scenario, but
> the idea that Google would go to another country to spend $$$ to sue over
> this one line is preposterous to me.
> Let me put it this way: I would be comfortable taking the "risk" myself.
>

Indeed, and furthermore "A cable is coming between A and B" sounds like
public information since Google and third parties published about it.
Drawing a pretty straight line between landing points won't sounds like
copyright violation.

This is not so clear for landing paths between beach to stations, until we
see technicians rolling out the cable, let's try to be there at the right
time

All the best

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

[OSM-talk] FCC public documents license and submarine cables mapping

[François Lacombe]

Hi all,

Google is currently rolling out several submarine telecommunication cable
systems and Amercian FCC actually publishes application documents
describing them.

Such one regards the Dunant system between Virginia Beach and
Saint-Hilaire-de-Riez in France
https://licensing.fcc.gov/myibfs/download.do?attachment_key=1650796

As the application document shows maps of landings and global Atlantic
Ocean route, I'm technically able to add it to OSM as several other
submarine systems already exists there.

Are you aware of license issues regarding FCC documents which would prevent
us to take data from them?

All the best

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

Re: [OSM-talk] Overpass API turned off due to Upload Filter thread

[François Lacombe]

Hi Steve,

Le jeu. 21 mars 2019 à 16:46, Steve Doerr  a
écrit :

> On 21/03/2019 05:21, Roland Olbricht wrote:
> > the Overpass API shows only an informative
> > result today. This will last until about 20:00 UTC.
>
> Could this be affecting nrenner.github.io/achavi, does anybody know?
>

Yes it does
I currently get  as answer.

All the best

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

[OSM-talk] OpenStreetMap at CES

[François Lacombe]

Hi all

As the CES ends by the end of today, I'd find great to list any interesting
insight or uses some of you may have seen during this week there.

I wasn't in Las Vegas and I didn't notice many reuse of renders nor data.

What about you?

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

Re: [OSM-talk] What use is OpenStreetMap?

[François Lacombe]

Hi

Big use cases for utilities, network operators and urban planning

English: https://www.openstreetmap.org/user/InfosReseaux/diary/47030
French:
https://www.openstreetmap.fr/cartographier-mondialement-linfrastructure-avec-openstreetmap/

Furthermore, OSM is the only one to build and share a worldwide tagging
model. Users can take the data but they can take the tagging model also and
use it to refine third party data.

All the best

François

Le ven. 4 janv. 2019 à 08:40, Oleksiy Muzalyev 
a écrit :

> A detailed map is an essential tool for firefighters, ambulance, and
> police. And not only of the town itself but also of the countryside
> especially along railways and automobile roads.
>
> The city of Stockholm built an interactive public transportation map on
> the basis of OSM: https://sl.se/en/ . People can see still at home when
> their bus is arriving at the stop.
>
> The city of Odessa created the similar public transportation map but on
> the basis of a commercial map: http://transport.odessa.ua/ . It was
> extremely useful web-application, one could see how the trams' geo-markers
> were moving on the map. The web-application became very popular, and the
> commercial map underneath stopped working normally for some, probably also
> commercial, reason.
>
> I mean a  municipal project which is based on an open data map running on
> the municipal server could be more resilient and affordable, especially if
> it becomes popular.
>
> A big separate topic is e-commerce delivery services. A rookie delivery
> driver may search for an address in a city in some cases for hours. This
> excessive driving could be reduced significantly if a driver could see a
> delivery address on the map. It would mean less pollution, accidents,
> pavement wear.
>
> Best regards,
> Oleksiy
>
> On 03.01.19 22:07, John Whelan wrote:
>
> I got a phone call from someone who works for a municipality who was
> passed my phone number.  Basically asking from a municipal government point
> of view was there any advantage to the municipality in having their
> municipality mapped in detail in OpenStreetMap.
>
> Off the top of my head businesses etc can provide map of where they are
> located without payment and list their web sites and phone numbers etc.
>
> Is there a web page somewhere that covers this?
>
> It is quite a serious question and I suspect will be used to justify some
> expenditure and effort to help enrich the map.
>
> Thanks John
>
>
> --
> Sent from Postbox
> <https://www.postbox-inc.com/?utm_source=email&utm_medium=siglink&utm_campaign=reach>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
> ___
> 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] Ground truth for non-physical objects

[François Lacombe]

Le sam. 15 déc. 2018 à 14:04, Colin Smale  a écrit :

> First time I have heard that as a (documented) rationale behind "ground
> truth".
>
> Surely the stronger requirement is public verifiability, from a freely
> accessible, objectively reliable source. What is physically present in situ
> is a subset of that - but so are public records. This would make the
> mapping objective, in the sense that a random second mapper would be able
> to verify the correctness of the data and/or come to the same conclusion.
>

+1
In France underground power lines maps are publicly available (and it
should be a standard practice, INSPIRE from EU encourage it)
https://opendata.reseaux-energies.fr/explore/dataset/lignes-souterraines-rte/map/?disjunctive.etat&disjunctive.tension&location=13,47.2096,-1.51929&basemap=f91575

Most of them aren't visible from the surface, sometimes you have red
markers and that's all.
Nevertheless it's useful to add them (with careful integration as to not
interfer with roads or something not related to) in OSM and there are no
issue with verifiability since the operator gives many information
https://openinframap.org/#13.22/48.85796/2.41832

All the best

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

Re: [OSM-talk] LinuxFoundation Energy Summit 2018 in Edinburgh (too few OSM inside)

[François Lacombe]

Le dim. 7 oct. 2018 à 08:27, Mateusz Konieczny  a
écrit :

> I wonder whatever they know that this way their datasets become ODBL (or
> copyright violations).
>

Good point but not so simple
OSM data isn't pushed in legacy and main datasets yet. It's only ponctual
cleanups on temporary chunks.
Currently, at least in France, such an argument won't encourage anyone
(especially industrial operators) to produce sustainable opendata since
they may think they are forced to.
Convince and include people in the process is a long term journey.

That's why we should go and talk outside as often as possible about what we
do here
People usually join because they think it's good, not because the license
say so.

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

[OSM-talk] LinuxFoundation Energy Summit 2018 in Edinburgh (too few OSM inside)

[François Lacombe]

Hi all,

Recently some power grid operators join their efforts to build up strong
open source software designed for energy grid building and operating.
It's mainly intended for professionals, engineers, researchers...

The next LinuxFoundation Energy Summit will be held by next 24 October.
https://events.linuxfoundation.org/events/lfenergysummit2018/

Collaborative cartography may be really important to achieve development of
such complex systems: they need accurate and up to date data.
Following my current professional experience, it becomes more and more
usual to clean-up proprietary and inside dataset with OSM data (my job,
sometimes on power infrastructure)
Certainly thanks to the long time effort of the community.
I wouldn't be surprised to see some French DSOs (distribution grids)
updating part of their own GIS with OSM.

Wouldn't it be time to show up in such professional events?
OSMF should think about OSM representation in LinuxFoundation events,
shouldn't it?


All the best

*François*
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Really heavy browser load with Overpass-turbo map display

[François Lacombe]

Hi Dave
Thanks for your input

Is Leaflet aware and will fix the issue?
Switching to an older version of a browser isn't neutral and raise security
considerations as always.

I didn't find anything relative to this problem on Leaflet github

All the best

François

Le dim. 23 sept. 2018 à 21:13, Dave F  a
écrit :

> It appears it maybe Leaflet &/or Firefox related. Reports are it doesn't
> occur in Chrome/IE.
>
> If your turn off Firefox auto updates & install an older version (I used
> v60.0 from FileHippo) it prevents it.
>
> Cheers
> DaveF
>
> On 23/09/2018 17:41, François Lacombe wrote:
>
> HI all,
>
> It's been a few days that my browser bear a heavy load when running many
> queries like https://overpass-turbo.eu/s/yUw, with overpass turbo.
>
> Was any change done on the frontend to get such a load on client side?
>
> Tested on firefox 62 64bits
>
> All the best
>
> François
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Really heavy browser load with Overpass-turbo map display

[François Lacombe]

HI all,

It's been a few days that my browser bear a heavy load when running many
queries like https://overpass-turbo.eu/s/yUw, with overpass turbo.

Was any change done on the frontend to get such a load on client side?

Tested on firefox 62 64bits

All the best

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

Re: [OSM-talk] Waterway=* and Waterways wiki pages merge

[François Lacombe]

There are many way of thinking about this.

Mixing waterways and culverts or gates in the same list isn't so clear.
If I want to know which are the possible waterways I can map, it's not a
concern they can be under a culvert or through a gate.

The point is to give essential features and let people find more precise
things on keys pages if and only if they want to.

This is what is done on power features list.
https://wiki.openstreetmap.org/wiki/Key:power

François

2018-03-23 18:02 GMT+01:00 Martin Koppenhoefer :

>
>
> 2018-03-23 17:58 GMT+01:00 Martin Koppenhoefer :
>
>> 2018-03-23 17:01 GMT+01:00 François Lacombe :
>>
>>>
>>> One additional issue is the "additional attributes for waterways" in the
>>> feature table here : https://wiki.openstreetmap.org/wiki/Key:waterway
>>> It's not a good idea to put attributes in the feature table since they
>>> can be related to other tags as well.
>>> Can they get removed from this list ?
>>>
>>
>>
>>
>> I would keep a reference to the attributes there, it could be a different
>> table or a list if you prefer, it is only for reference, as far as I have
>> seen all of those attributes already have their own tag / key page where
>> they are defined, and if you want to include references to them from other
>> feature pages, you can do it with the standard tag templates like
>> {{Tag|tunnel|culvert}}.
>>
>>
>
> the scheme seems to be used for other key pages as well, see for example
> https://wiki.openstreetmap.org/wiki/Key:highway
>
> Cheers,
> Martin
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Waterway=* and Waterways wiki pages merge

[François Lacombe]

Hi Martin,

Understood, I won't merge the overview page, and will only move stuff
between two page as to remove redundancies.

One additional issue is the "additional attributes for waterways" in the
feature table here : https://wiki.openstreetmap.org/wiki/Key:waterway
It's not a good idea to put attributes in the feature table since they can
be related to other tags as well.
Can they get removed from this list ?

François

2018-03-23 16:20 GMT+01:00 Martin Koppenhoefer :

>
>
> 2018-03-23 15:45 GMT+01:00 François Lacombe :
>
>> Hi,
>>
>> I'm currently thinking about wiki improvement about waterways.
>>
>> It would be great to move (with caution) the content of the Waterways
>> page to Key:waterway
>> https://wiki.openstreetmap.org/wiki/Key:waterway
>> https://wiki.openstreetmap.org/wiki/Waterways
>>
>> This would prevent redundancy and ease tagging documentation maintenance.
>> There are many translations which aren't up to date currently.
>> Waterways page will be redirected to Key:waterway
>>
>> Does anyone have a concern about this ?
>>
>
>
> I am a bit unsure about this. Some years ago (actually 7), those
> "collector" / "overview" pages have been set up. They were (if I interpret
> it right) not thought as specific tagging documentation, but as overview
> pages about a certain topic, with references to tag definition pages, so
> you could find the right tag page.
>
> The key:waterway page should be mainly about the key waterway and should
> contain exhaustive information about this key. It has a reference to the
> more generic Waterways overview page, where you can find references to the
> main concepts and tags, not only waterway=* tags but including man_made
> tags, natural=* tags and others.
>
> Clearly all relevant information regarding the waterway key and its
> meaning, application and interpretation, should be on the key:waterway
> page. If such information is only on the overview page, it should be
> verified/discussed and transferred.
> It is also not needed to repeat all the waterway specific information on
> the overview page, its purpose is different: give an overview and lead to
> relevant tag pages.
>
> I can imagine that this initial distinction may have been blurred in the
> years since it was created, so a review surely makes sense, but generally I
> think it is a good idea to have the overview pages (about topics, rather
> than keys).
>
> Btw., what I wrote is not only referring to waterways, but in analogy also
> to other topics like these:
>
> https://wiki.openstreetmap.org/wiki/Speed_limits
> https://wiki.openstreetmap.org/wiki/Highways
> https://wiki.openstreetmap.org/wiki/Landuse
> https://wiki.openstreetmap.org/wiki/Landcover
> https://wiki.openstreetmap.org/wiki/Places
> https://wiki.openstreetmap.org/wiki/Addresses
> https://wiki.openstreetmap.org/wiki/Public_transport
> https://wiki.openstreetmap.org/wiki/Power
> and maybe more
>
> None of these pages has ever been voted, naturally.
>
> I'm generally in favor of keeping them, but they should be reviewed to
> make sure the overview pages are concise overview pages, and relevant
> information is on the key and tag pages.
>
> They should also get a disclaimer what they are meant to be, so that
> people aren't confused.
>
> Regarding missing and out of date translations: this is the standard
> situation in the wiki, even for the "main languages", with maybe very few
> exceptions. We should care for the English version here, and leave
> translations to the local communities, who could also decide not to
> translate some pages (because they know they are so few they will not be
> able to keep it updated).
>
> Cheers,
> Martin
>
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Waterway=* and Waterways wiki pages merge

[François Lacombe]

Hi,

I'm currently thinking about wiki improvement about waterways.

It would be great to move (with caution) the content of the Waterways page
to Key:waterway
https://wiki.openstreetmap.org/wiki/Key:waterway
https://wiki.openstreetmap.org/wiki/Waterways

This would prevent redundancy and ease tagging documentation maintenance.
There are many translations which aren't up to date currently.
Waterways page will be redirected to Key:waterway

Does anyone have a concern about this ?

Water Management page would stay and be completed with recent hydropower
tagging adding
https://wiki.openstreetmap.org/wiki/Water_management

All the best

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

Re: [OSM-talk] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

[François Lacombe]

2018-03-19 0:38 GMT+01:00 Michael Kugelmann :

> Am 18.03.2018 um 20:45 schrieb Richard:
>
>> fundamental decission - maybe osm and osm-wiki accounts should be the
>> same?
>>
> This had been independent in the very old history. And now you have
> conflicts => will not work w/o huge effort...
> There had been requests like this 5 years ago or so w/o success. Not
> because nobody wanted to implement but because it was not possible.
>

This is a great idea.

Can you sum up what are the technical issues which make it not possible
please ?

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

Re: [OSM-talk] Power Lines and topological error detection

[François Lacombe]

Hi all,

Osmose-QA also display such bad connection between power lines and non
power features
http://osmose.openstreetmap.fr/fr/error/16446522057 (item 7040 class 4)

We also have this issue related to unterminated lines like this occurence
(7040 class 2) :
http://osmose.openstreetmap.fr/fr/error/16430655499
https://github.com/osm-fr/osmose-backend/issues/229

It causes a lot of false positive alerts because occuring on T connections
(not only for power lines)
No offense intended towards devs who do a lot of good work anyway :)

All the best

François

2018-03-07 5:30 GMT+01:00 Roland Olbricht :

> Hi,
>
> > Various topological errors related to power lines are not detected by
> > OSM editors. Monitoring the High Voltage power network for Quebec I
> > often find nodes connecting crossing waterbody, highways, landuse to the
> > power lines.
>
> FWIW, you can find them with a query like
> https://overpass-turbo.eu/s/wLQ
>
> If you want to only get highways, there is still enough to do:
> https://overpass-turbo.eu/s/wLR
>
> For practical work in JOSM, you can get power lines and the connected
> objects: paste
>
> way[power=line]({{bbox}});
> node(w);
> way(bn);
> (._;>;);
> out meta;
>
> and choose a meaningful bounding box. Please do not do other things than
> disconnecting, because you cannot see to what the other objects are
> connected. But for disconnecting, this should be fine.
>
> Cheers,
> Roland
>
> ___
> 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] Mapping rivers that flow into/through lakes?

[François Lacombe]

Hi

2018-02-27 13:10 GMT+01:00 Martin Koppenhoefer :

> I would facilitate things if navigable waterways are connected.
> Small streams should maybe only connect to the water body (lake).
>
> In theory you could do waterway routing similar to how pedestrian routing
> is done with squares in the cheapest version (around the square).
>

Given problem is there are sometimes waterways wich feed lakes from the
bottom, or under the shoreline
https://www.openstreetmap.org/way/562902636

Then I prefer to always connect even in lakes.


All the best

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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[François Lacombe]

2018-02-23 15:36 GMT+01:00 Rory McCann :

> If OSM takes a "all rivers must be connected through lakes", then data
> consumers have a simple job. If OSM says "some will and some won't", then
> data consumers have to process the data to add intra-lake connections. If
> they have to do it some of the time, why bother connecting *any* rivers?
>

IMHO rivers should always connect through lakes. I'm always mapping like
this, no exception.


> I think I'll change to not connecting rivers, unless it's very obvious,
> and leaving data consumers to connect rivers themselves.
>
This may be a very hard task, especially if rivers don't share nodes witk
lakes waterbody.

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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[François Lacombe]

 (Sorry Rory, resent this to Talk ML)

2018-02-23 11:35 GMT+01:00 Rory McCann :

> On 23/02/18 06:53, Maarten Deen wrote:
>
>> I see nothing wrong with those examples, I would do it the same,
>> especially if the rivers can be sailed on by boat. Then you absolutely need
>> the rivers to be connected to a central river (or fairway) in the lake.
>>
>
> But then how far do you go? Should every stream be connected to the
> central river? e.g. what about here ( http://tools.geofabrik.de/osmi
> /?view=water&lon=28.57869&lat=-16.75136&zoom=11 )?
>

Yes: http://tools.geofabrik.de/osmi/?view=water&lon=28.57869&;
lat=-16.75136&zoom=11


> If some rivers/streams shouldn't be connected, then some data consumers
> will have to do an automatic connection anyway. When measuring water run
> off and pollution, you probably want to know that "stuff going into
> stream X will eventually get to point Y downstream" (right?).
>

I don't get this, which situation do you think of when you say " If some
rivers/streams shouldn't be connected " ?


> Connecting all means that large lakes will be full of a "skeleton" of
> joining rivers/streams, and a small 1km stream could get a lot longer.

Yes they do http://tools.geofabrik.de/osmi/?view=water&lon=28.57869&;
lat=-16.75136&zoom=11

This can be solved by removing waterways sections which intersect with
lakes water body.
It could be done on consumer purpose for a particular usage.
Topology is also a really useful data and waterways should definetly
connect downstream sections.

2018-02-23 11:45 GMT+01:00 Joseph Reeves :

> Slightly off topic, but I was recently wondering if there was a waterway
> routing tool available? As in, I'd like to click a point in a waterway and
> have the downstream route plotted, presumably to the sea. It appears to me
> that a tool like that could be useful in this discussion?
>

You can achieve this with OSRM with a proper routing profile, or even
pg-routing if you are at ease with it.

All the best

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

Re: [OSM-talk] Mapping rivers that flow into/through lakes?

[François Lacombe]

2018-02-23 6:53 GMT+01:00 Maarten Deen :

> On 2018-02-22 22:59, Rory McCann wrote:
>
> If you asked someone "Where does this river end?" they'd probably point
>> to where it joins the lake. Connecting the river to the "central river"
>> breaks this. And it can result in odd long ways. I might have gone a
>> little OTT here (
>> http://tools.geofabrik.de/osmi/?view=water&lon=27.98062&lat=
>> -16.95179&zoom=11
>> ) or here (
>> http://tools.geofabrik.de/osmi/?view=water&lon=-8.26705&lat=
>> 52.99047&zoom=11
>> ).
>>
>
> I see nothing wrong with those examples, I would do it the same,
> especially if the rivers can be sailed on by boat. Then you absolutely need
> the rivers to be connected to a central river (or fairway) in the lake.
>

I agree too and this is how I use to map rivers in lakes.

This is great thing to have comprehensive topology for waterways.

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

Re: [OSM-talk] OSM tagging validation lib

[François Lacombe]

Hi Bryan

Le 24 déc. 2017 4:45 PM, "Bryan Housel"  a écrit :

Have you looked at https://github.com/osmlab/osmlint ?
Of all the current validation efforts, that seems like the most promising.


I didn't know OSMLint and OSM QA tiles before
Very promising indeed for parallel processing
Issue I see it's relations aren't available unfortunately


I’d definitely echo what other people are saying about avoiding the osm
wiki if possible.

Can you elaborate please ?
I just don't know elsewhere anyone can find comprehensive and consistent
information about tags despite wiki is not always perfect
Wiki got good functionalities to log contributions and revert vandalism too.


It works on vector tiles though, so to stuff it into an editor like iD, we
would need to write some kind of pipeline that does:
“current view of stuff in editor” -> "vector tile" -> "osmlint engine" ->
“results (geojson)” -> “back to the editor for user to see"

It might work?

It can clearly work :)
Nevertheless it's one usecase out of plenty
Validation systems can be used to do data audit too
That's why focusing on rules formatting is more versatile than writing
implementation unlinke what i was originally suggesting



Also… This problem of “validating OSM” is really unbounded.  You should
know that before you start working on it!  I’m not one to tell people not
to work on something but.. It’s really hard!  Tags are just made up all the
time by people.


I agree and it's a different problem
Focusing on rules formalism doesn't assume what rules should be.
Even if tags are made by people, some definitions can be commonly accepted
and they can be refined after some discussion. Validation can follow the
same peocess also.


Can a `highway=residential` connect to a `power=line`?  - no!
Can a `highway=service` connect to a `power=substation`  - uhh, I guess!
Can a `highway=??` connect to a `power=thing_i_just_made_up`? - haha!

These are rules, not the description we should build to make them
understandable by software

All the best

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

Re: [OSM-talk] OSM tagging validation lib

[François Lacombe]

Thanks for answers :)

I said a lib, but indeed the diversity of projects would be too problematic
for implementation and rollouts.
JSON, xml, text are fine
https://twitter.com/VincentPrivat/status/944923315831033856

As Simon said, taginfo is a great tool to extract data from wiki.
Even if it's not perfect, the wiki is the only reference I know and where
data consumers go to get information. Then it's relevent to improve it
It would be hard to put all practicies and rules in wiki keys scorecard
templates (from where taginfo get most of its input). Should we complete it
in taginfo itself ?

All the best

François

Le 24 déc. 2017 1:47 PM, "Simon Poole"  a écrit :

> On the one hand lots of the in principle useful information in the wiki is
> not really easily extractable and on the other hand it is prone to
> manipulation in more than one way (current fad is to add big warnings about
> tagging errors what are not).
>
> IMHO addressing the first issue would likely be more helpful and perhaps
> allow the generation of at least rudimentary presets directly from the wiki
> (potentially with support from taginfo).
>
> Simon
>
>
>
> On 24.12.2017 12:54, Mateusz Konieczny wrote:
>
> > conform validation to wiki
>
> Sometimes wiki is wrong and should be changed.
>
> Note also that authors of different tools have different opinions how and
> what should be reported as errors.
>
>
> On 24 Dec 2017 11:12 a.m., "François Lacombe" 
> wrote:
>
> Hi
>
> Here is an idea I got regarding tagging validation in editors (iD, JOSM,
> others).
> Subsequently to wiki proposal voting and cleanups, it's currently
> necessarily to open issues in each editor repository to ask for new tagging
> validation rules.
>
> It can sometimes be time consuming to develop those new rules and such a
> work is done independently by each project maintainer. While each project
> have its own specific components, background logic is the same.
>
> Would a new lib called like osmtagvalidator or so in charge of doing
> conform validation to wiki be useful?
> It may be shared by any project involved in osm editing and preserve its
> resources for other valuable developments.
>
> For me, validation doesn't prevent users to use tags they want, but only
> warn them about possible mistakes.
>
> How would devs and users feel about this?
>
> All the best
>
> François
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] OSM tagging validation lib

[François Lacombe]

Hi

Here is an idea I got regarding tagging validation in editors (iD, JOSM,
others).
Subsequently to wiki proposal voting and cleanups, it's currently
necessarily to open issues in each editor repository to ask for new tagging
validation rules.

It can sometimes be time consuming to develop those new rules and such a
work is done independently by each project maintainer. While each project
have its own specific components, background logic is the same.

Would a new lib called like osmtagvalidator or so in charge of doing
conform validation to wiki be useful?
It may be shared by any project involved in osm editing and preserve its
resources for other valuable developments.

For me, validation doesn't prevent users to use tags they want, but only
warn them about possible mistakes.

How would devs and users feel about this?

All the best

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

Re: [OSM-talk] OSM Tag History updates - call for help

[François Lacombe]

Hi Daniel,

Thnx for this message, this is a great tool I like to use

Can't taginfo feed or even completely include the tool functionnalities ?
I don't know how taginfo got its data from OSM.

It would be great to show up tags usage evolution beside current
volumetries.


Good luck to Martin to find a proper datasource anyway

François

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2017-11-25 16:52 GMT+01:00 Daniel Koć :

> OSM Tag History is a great service which shows the changes of a given tag
> used in the OSM database. Probably some of you already know it:
>
> http://taghistory.raifer.tech
>
> The problem is however that it needs a full database, which includes tag
> history. The author is not willing to run it himself, so updates are manual
> and not too frequent, which makes the service less useful than it could be.
>
> He looks for somebody who "already runs a (daily) updated OSM DB which
> could produce deltas of the counts of tags in their db (for little extra
> processing cost)":
>
> https://github.com/tyrasd/taghistory/issues/10#issuecomment-346945069
>
> If someone is able to do it, please contact him. I would be happy to see
> more frequent, possibly automatic updates, that's why I pass the message.
>
> --
> "My method is uncertain/ It's a mess but it's working" [F. Apple]
>
>
> ___
> 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] JOSM Custom Presets - Combo to set multiple tags

[François Lacombe]

Hi Mike

I don't think so since the combo box has a unique key name set in its
definition

What you can do though is to set the first key with a fixed value
(religion=chrisitian) and let user pick for denomination

Let us know how is it going

François


Le 29 août 2017 5:44 PM, "Mike Thompson"  a écrit :

I am learning how to create custom presets for JOSM.

Is there a way to have a "combo" list set multiple tags? For example (just
to illustrate the question), to make it so that if the user picks "Roman
Catholic", religion=christian and denomination=roman_catholic are both set?

Thanks,
Mike

___
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] OSM Wikidata SPARQL service updated

[François Lacombe]

Hi

2017-08-14 11:18 GMT+02:00 mmd :

> Hi,
>
> Am 13.08.2017 um 19:49 schrieb Yuri Astrakhan:
>
> > * all ways now store "osmm:loc" with centroid coordinates, making it
> > possible to crudely filter ways by location
>
> out of curiosity, can you say a few words on how your overall approach
> to calculate centroids for ways? As we all know it's an endless pain to
> get that information out of minutely diffs :)
>

Out of curiosity, can you explain how relations are processed also ?
Is this relevant to look for a representative point for a relation or a
more complex search have to be done for specific members (roles) ?

I don't know Shapely enough to say if it can handle this standalone and it
would be greate to elaborate a bit what is done from line 260 to 280 of
osm2rdf.py :)


All the best

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

Re: [OSM-talk] adding Wikimedia videos to OpenStreetMap objects

[François Lacombe]

Hi Oleksiy,

It'e surely useful to link OSM objects and wikimedia content.

As you mentionned, OSM objects can easilly be linked to wikidata with a
simple scalar value.
Since wikimedia video can also refer to wikidata object, a link between OSM
and video sounds redundent.

Such a link shouldn't be done as to ensure of data quality and its
maintenance


All the best

Francois


2017-01-30 9:52 GMT+01:00 Oleksiy Muzalyev :

> Dear fellow mappers,
>
> It is possible now to upload to the Wikimedia Commons the videos which
> illustrate Wikipedia articles. On Saturday I went to the highest summit of
> the Swiss portion of the Jura mountains, Mont Tendre
>  , and filmed a short, 4
> minutes, video about it.
>
> Then I added this video to the respective Wikimedia category and to the
> Wikidata page, and added wikidata=* and wikimedia commons=* tags to the OSM
> node of the summit: http://www.openstreetmap.org/node/343335042
>
> I used for filming the cameras Sony RX100 V and DJI Osmo, and for the
> aerial footage the latest DJI Phantom 4 Pro+ quad-copter. The Wikimedia
> accepts videos in the free open WEBM format, so I converted the MP4 file
> into WEBM with the ffmpeg  command line tool.
>
> The quality of the resulting WEBM video:
>
> https://commons.wikimedia.org/wiki/File:Mont_Tendre_Jura.webm (select at
> least 1080P resolution in the player for viewing)
>
> is comparable with its Youtube version:
>
> https://youtu.be/pgNiCYzr7sg
>
> The DJI Phantom 4 Pro+ has got a camera with one inch image sensor and
> improved lenses. In my opinion, it is the first aircraft of this class
> capable to film really useful aerial photos and 4K aerial videos. Creating
> a good video is not a trivial task, still there is a lot of information on
> it, and the quality equipment is readily available.
>
> And it is kind of interesting. In fact, we could climb on the Mont Tendre
> only from the third attempt. Two first attempts failed due to the snow,
> wind, low outside temperature, and the remoteness of a location (it is also
> the most isolated mountain of the canton of Vaud), besides we had to carry
> the equipment. Probably, I would never did it in winter, if it were not for
> filming.
>
> A video may convey much of significant information about a location. It
> may provide not only ground and aerial footage, but also some practical
> advice and insights via a microphone. Perhaps, in future we may think about
> creating a video=* key for direct linking to the videos with a Creative
> Commons license. But even now it is possible to do it via wikidata=* and
> wikimedia_commons=*.
>
> With best regards,
>
> Oleksiy
>
> ___
> 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] OSM then and now revived

[François Lacombe]

Hi Martin,

Thank you, great job :)




*François*
2017-01-28 17:25 GMT+01:00 Maarten Deen :

> What would be really wonderful is a yearly layer so you can see the
> history changing. Just like http://topotijdreis.nl/
>
> Maarten
>
> On 2017-01-28 16:08, joost schouppe wrote:
>
>> Any chance we'll see some middle version there too in the future?
>> (say, 2012. And than later, 1/1/20**)
>>
>> You gave us a finger, let me grab your entire arm :)
>>
>> 2017-01-26 23:17 GMT+01:00 Martijn van Exel :
>>
>> Hi all,
>>>
>>> I resuscitated the OSM then and now service, where you can compare
>>> OSM as it was in October 2007 with now.
>>> The service is a bit slow because 2007 tiles above z10 are not
>>> pre-rendered. This will improve as tiles get cached.
>>> Here is the location of SOTM 2016 as an example:
>>> http://mvexel.github.io/thenandnow/#15/50.8178/4.3971 [1]
>>>
>>> Martijn van Exel
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk [2]
>>>
>>
>> --
>>
>> Joost Schouppe
>> OpenStreetMap [3] | Twitter [4] | LinkedIn [5] | Meetup [6]
>>
>> Links:
>> --
>> [1] http://mvexel.github.io/thenandnow/#15/50.8178/4.3971
>> [2] https://lists.openstreetmap.org/listinfo/talk
>> [3] http://www.openstreetmap.org/user/joost%20schouppe/
>> [4] https://twitter.com/joostjakob
>> [5] https://www.linkedin.com/pub/joost-schouppe/48/939/603
>> [6] http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Wiki TagList and TagKey/exists templates

[François Lacombe]

Hi,

I'm seeking information about the TagKey/exists template which is currently
rolled out on several wiki pages.

We use to use the Tag template which adapts the link color whether the
corresponding page exists or not.
Why have we to add the "exists" key word? I find this redundant although an
existing page will rarely disappear.

In the same time, the TagList template provide less redundant information
by using taginfo database.
Prior to use this template, we should create every value pages distinctly
to allow TagInfo to get according description and picture.
This template was added yesterday to this page :
https://wiki.openstreetmap.org/wiki/Key:substation and the first table
removal was reverted.
Why ?

If a new colour scheme is preferred than the simpler {{Tag}} one, how can
we adapt TagList tables to look similar ?

Thanks in advance for any answer, all the best

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

Re: [OSM-talk] JOSM 11223 won't start : expired certifcate

[François Lacombe]

Thanks Simon,

Indeed, duplicate
Sorry for noise

All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2016-11-25 10:36 GMT+01:00 Simon Poole :

> See https://josm.openstreetmap.de/ticket/14029
>
> Am 25.11.2016 um 09:03 schrieb François Lacombe:
>
> Hi all,
>
> Starting yesterday evening, JOSM 11223 jnlp won't start on my laptop.
>
> JAVA 8 upd111 arguing me it doesn't find any valid certifcate to challenge
> application security.
> The last cert I know actually expires on 2016 novembre 22 CET 01:00
>
> josm-tested.jar doesn't produce much effect, no splash screen and no GUI.
>
> Is anyone facing the same problem or is this a local Java update issue ?
>
> Ticket #14044 opened
> https://josm.openstreetmap.de/ticket/14044
>
> Cheers to the team which deliver extremly good and useful work
>
>
> All the best
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
>
> ___
> talk mailing 
> listtalk@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] JOSM 11223 won't start : expired certifcate

[François Lacombe]

Hi all,

Starting yesterday evening, JOSM 11223 jnlp won't start on my laptop.

JAVA 8 upd111 arguing me it doesn't find any valid certifcate to challenge
application security.
The last cert I know actually expires on 2016 novembre 22 CET 01:00

josm-tested.jar doesn't produce much effect, no splash screen and no GUI.

Is anyone facing the same problem or is this a local Java update issue ?

Ticket #14044 opened
https://josm.openstreetmap.de/ticket/14044

Cheers to the team which deliver extremly good and useful work


All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

2016-10-01 16:23 GMT+02:00 Paul Norman :

>
> OpenStreetMap Carto is given special treatment on osm.org by being the
> default layer, so the wiki should reflect that.
>

OSM Carto doesn't render all features the wiki describes
Will we left a blank space when there is no osm carto style?

No rendering in the infobox can also be a solution.


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

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

Understood Dalibor,

Obviously, no offense intended while replacing the whole template like I
did few days ago.

The problem isn't the taglist itself but the lack of translation of keys'
pages on wiki, I agree with that too.

Nevertheless I think it's a bad idea to wait for all translations of all
templates in all languages : we'll never implement this useful feature from
taginfo.
Can't we take this as an advantage to encourage wiki contributors to move
to this new format by creating local translations for the key they use ?
I mean no one will ever move if we say "ok there is a new way of defining
features lists but we put it aside for a while". And the wiki will be
messier.

Is there any other problem I didn't see regarding this ?


All the best

François

2016-09-26 10:51 GMT+02:00 Dalibor Jelínek :

> Hi Francois,
>
> it seems that we are talking about two different things.
>
> Yes, you are right that when all the tags in Taglist table
>
> are translated then it shows them correctly in given language.
>
> But when the tags themselves are not translated then
>
> there is nothing to show in that language.
>
[...]
>
>
>
> Regards,
>
> Dalibor (chrabros)
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

Hi Matthijs,

2016-09-23 14:27 GMT+02:00 Matthijs Melissen :

> Yes, for the moment it is necessary to create a new page under a
> different name. If you move over the current template to TagList,
> non-English language wiki pages will break.
>

For me It worked like a charm.
I don't see that problem on power features list. The list is ok for
English, French and Italian languages.

http://wiki.openstreetmap.org/wiki/Map_Features#Power

Can you show me an example of bad case please ?

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

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

Hi Jochen

2016-09-21 10:08 GMT+02:00 Jochen Topf :

> No, count isn't a criteria at all. man_made=mill is simply not included
> automatically, because there is no wiki page for it.
>

Understood, thanks for clarification


>
> I recommend giving an explicit list of all tags that you want to have in
> your list. Just using the key only is more of a short-cut to help get
> you going.
>

100% percent agreed

I'll move power features to this new template format soon

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

Re: [OSM-talk] Map features page on wiki

[François Lacombe]

Hi Matthijs,

I find this stuff interesting for power features and thinking to move the
current template to this new system.

You deal with pages like Template:Map_Features/XXX but power template is
currently known as Template:Map_Features:power
Have we to rename the template to Template:Map_Features/Power ?

The way the list is built isn't clear to me : for man_made example you just
give tags=man_made as template parameter but taginfo doesn't return the
whole set of values.
I see a man_made=mill value on taginfo which is not visible on the wiki
loaded template
Is count the only criteria ?


All the best

François

2016-09-21 1:40 GMT+02:00 Matthijs Melissen :

> On 1 September 2016 at 10:01, Matthijs Melissen
>  wrote:
> > As a firs step, I included the list here on the Geological map features
> page:
> > http://wiki.openstreetmap.org/wiki/Geological
> > it seems to work well there.
>
> We now have TagList templates for the following keys:
> http://wiki.openstreetmap.org/wiki/Template:Map_Features/natural
> http://wiki.openstreetmap.org/wiki/Template:Map_Features/geological
> http://wiki.openstreetmap.org/wiki/Template:Map_Features/man_made
> http://wiki.openstreetmap.org/wiki/Template:Map_Features/emergency
> http://wiki.openstreetmap.org/wiki/Template:Map_Features/office
>
> I could use some help with creating TagList templates for the other
> keys. Is anybody interested?
>
> Creating the template page itself is easy. Just create a page name
> Template:Map_Features/XXX where XXX is the key; have a look at one of
> the existing pages for more information.
>
> Now we need to check if the TagList is correct and complete. To do so,
> check if all entries on the old map features page have an entry on the
> TagList page (this should be the case if they have wiki entries).
> Also, check if the definition and photo on the new page is not worse
> than the definition on the old page.
>
> (Note: by convention, definitions typically start with 'a' or 'an',
> and avoid repeating the name of the object itself. For example for
> natural=wetland, do not use "the wetland tag is used for natural areas
> subject to inundation or with waterlogged ground" but "a natural area
> subject to inundation or with waterlogged ground".)
>
> It would be great if other people would be interested in working on
> this as well.
>
> -- Matthijs
>
> ___
> 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] Map features page on wiki

[François Lacombe]

Hi Matthijs,

+1 to keep Map Feature pages up to date.

It would be great to sync definitions with info boxes (with some template
tricks but it more looks like wiki-data than simple wikimedia templates)
TagInfo already got it from wiki

All the best
Francois
Le 1 sept. 2016 12:45 AM, "Matthijs Melissen"  a
écrit :

> Hi,
>
> We have currently a Map Features page on the wiki:
> http://wiki.openstreetmap.org/wiki/Map_Features
>
> The page also contains definitions for all features. We therefore
> store the definitions now in two places: in the map features tables
> and in the infoboxes on the pages themselves.
>
> Duplication of definitions seems not ideal to me. Even though a lot of
> people try to update this, there are still quite a lot differences
> between the definitions on the map feature pages and the definitions
> in the infoboxes.
>
> Do we want to keep the Map Features page? If yes, do we have technical
> means to keep the definitions synchronised? Could we perhaps generate
> it from Taginfo, or somehow include the definition from the Infobox on
> the Map Features page?
>
> -- Matthijs
>
> ___
> 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] The New Cloud Atlas - Mapping Physical Infrastructure of the Internet with OSM

[François Lacombe]

Hi Tim,

This is really impressive, can't wait to test this special instance of iD :)
The road you went along since early 2015 brings a lot of positive things

Telecom tags consistency needs to be tidier, especially for towers, masts,
poles or whatever.
Your tools may help a lot to do so and find missing objects.


2016-08-17 19:22 GMT+02:00 Florian Lohoff :

>
> For Germany all phone exchanges from Deutsche Telekom have been imported
> some time ago but you dont seem to show them.
>
> This is an example for Exchange "ONKZ 5241 ASB 4":
>
> https://www.openstreetmap.org/way/151237643


I remember of a talk about man_made=MDF and imho it doesn't sound to be the
best solution.

Because main distribution frame is only a particular component inside a
whole central office.
http://www.infos-reseaux.com/photos/image.php?id=190


MDF can be mapped with dedicated features if mappers know exactly where
they are in (sometimes) big buildings.
The example you show is a building hosting many different kind of devices
and equipment and we'd better call them "central office".
telecom=central_office and building=yes (at least).

That's the point of this proposal
http://wiki.openstreetmap.org/wiki/Proposed_features/Telecom_local_loop



All the best

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

[OSM-talk] Wiki power pages merging

[François Lacombe]

Hi all,

The power substations wiki page hasn't been edited since end of 2013.
http://wiki.openstreetmap.org/wiki/Power_substations

It sounds redundant with the content of the power=substation key page
http://wiki.openstreetmap.org/wiki/Tag:power%3Dsubstation

I see no point to preserve these two pages since the second one is far
more complete and translated in several languages

Would you have any objection to redirect "Power substations" to
Key:power=substation ?
May other items be in the same situation ?

The merging will be done without further comments until 15 days.


All the best

François


--
François Lacombe

fl dot infosreseaux At gmail dot com
@InfosReseaux

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

[OSM-talk] Feature proposal - Voting - Location transitions : a little more feedback are needed

[François Lacombe]

Hi all,

Just to inform you that the location transitions proposal is still
under voting until next Saturday.
http://wiki.openstreetmap.org/wiki/Proposed_features/Location_transitions

Several people have already express their feeling about it, what about you ?
A few more feedbacks are needed to better establish the community
opinion about this document.

Many thank in advance for any contribution


cheers


François

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

Re: [OSM-talk] VisualEditor on the OSM wiki

[François Lacombe]

Hi,

A big thank you to the sysadmin team for enabling this on the OSM wiki :)
It's a really useful tool and it will surely help people to improve
the page content.

Happy new year everyone :)


François
François Lacombe

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


2016-01-03 23:02 GMT+01:00 Rob Nickerson :
> Hi,
>
> Not sure when this happened (some time recently) but I wanted to thank our
> wiki system admins for adding the VisaulEditor extension to the OSM wiki.
> For those that don't know the extension is a rich text editor for wiki's and
> came about following concern over declining new contributors to the
> wikimedia projects. It has taken many years to develop this extension but it
> is great to see it now being used on the OpenStreetMap wiki (as well as the
> WikiMedia sites).
>
> If you have never edited a wiki page before now is the time to try it out.
> No longer do you have to remember the wiki syntax to make an edit :-)
>
> Rob
>
> ___
> 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] A big debate about OSM quality in Strava community

[François Lacombe]

Hi
This mail is sent from a phone

At a first glance, I would to suggest to invite the ones who are
complaining at the quality of maps to improve it, aren't they ?
Especially when they are riding bike on path not so many people walk on.

For imagery issues, it's more MapBox business than OSM but I understand it
can be a problem when users come from other services

Just my 2 cents, all the best

François
Le 18 sept. 2015 18:31, "Ian Dees"  a écrit :

> Feedback thread on Strava is here:
>
>
> https://strava.zendesk.com/entries/95423147-Feedback-for-Strava-s-new-maps-OpenStreetMap-?page=5#post_39574047
>
> On Fri, Sep 18, 2015 at 12:21 PM, John Doe  wrote:
>
>> Interesting debate about the recent adoption of OSM:
>> http://cyclingtips.com.au/2015/09/strava-users-remain-frustrated-by-switch-from-google-maps-to-openstreetmap/
>>
>> ___
>> talk mailing list
>> talk@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk
>>
>>
>
> ___
> 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] Antennas and radio networks supports mapping

[François Lacombe]

Thank you Dave,


2015-07-15 14:15 GMT+02:00 Dave Stanley :

> Hi
>
> I map quite few radio sites in connection with my work.  Usually it is
> just mast/tower locations using the 'man_made=tower +
> tower:type=communication' tags with name/operator information. There are
> quite few things for these towers that could be improved.  For example the
> difference between a tower and a mast - a mast in the UK is normally
> considered to have guy wires to hold it up. where as a tower supports
> itself.  May masts are big enough to justify the guy wires being mapped
> with their ground anchor points. I am not aware of anything suitable to do
> that.
>

Ok to say definitions and keys are a bit messy. It's only about supports
which can be refined independently.


>
> There is also their feed line systems.  I have used power=line to map some
> of these, as in this example in Burma:
>
> https://www.openstreetmap.org/#map=18/16.86624/96.16177
>
> It is not ideal, but the closest I could think of.  Medium-wave broadcasts
> sites typically have very long feeder systems that can be mapped, as in the
> example.
>

This is interesting
I didn't see the use of power=line like that but it can be adjusted.
Wouldn't you add frequency=* and usage=radio on such lines ? It may allow
consumers to distinguish them from standard electricity transmission lines.

RF can be used at high power rates : The CERN currently use them at hundred
of MW to power up its accelerator.



> As for the antennas mounted on a mast/tower, you then may need to consider
> the frequencies and operators that use the antennas.  In some cases there
> will be multiple frequencies and operators. Physically, you would need the
> antenna height above ground level, direction, possibly which leg it is on
> and so on.
>

Antennas have many characteristics but only a few are relevant in OSM.
It may be better to give a manufacturer name and model reference to get
such details directly from other databases.

Azimuth (if applicable), position and model information are the only data
required there, aren't you ?
If the antenna works on several frequencies (based upon it's model number
and manufacturer capabilities), the usage of those frequencies can depend
on the "radio stations" relations the antenna is member of.


Lots to think about.
>
Indeed, can't wait to go forward about this topic


Regards

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Antennas and radio networks supports mapping

[François Lacombe]

Hi,

I just wanted to share some thoughts about antennas and radio supports
mapping on this list.

There are currently several tags in use to map telecommunication or radio
broadcast supports :
man_made=tower + tower:type=communication
man_made=telecommunication_tower
and so on...

but this won't allow us to add antennas on them at all or describe how
these supports are used.
Antennas and stations (relations of supports + antennas + cabinets) may be
interesting too.

Some French mappers and I are currently looking for a sustainable model to
map radio sites, radio stations, supports and antennas since our regulator
allows free datasets to be downloaded and part of them can be added on the
map (Etalab license compatible with OdBL).
The point is to add references (ref:FR:ANFR) on right objects first as for
linking to the whole dataset which shouldn't be imported in OSM (only
technical data and not so geographical)

I've proposed such things (unfortunately only in French for the moment) but
it's not finalized or transposable on the map
http://wiki.openstreetmap.org/wiki/File:Radio_antennas_mapping_proposal.png

The problem is to add several antennas on the support itself (sometimes on
masts, sometimes at the top of buildings).
Supports can be composed of several decks and several antennas can share
same lat/lng (but different elev) and currently can't be added as nodes.
Relations can really be a pain to maintain in such situation too.

May someone have idea and help solving the issue without adding 3rd
dimension to OSM model?


Cheers

François

--
*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Neat use of OpenStreetMap

[François Lacombe]

Hi paul,

Can you detail a little more how this could be a real powerhouse please ?

Is this just a use case for map renders or something with more OSM services
interaction ?


All the best

François

2015-05-28 11:21 GMT+02:00 Paul Johnson :

> OpenBMap <http://radiocells.org/>
>
> It's similar to Google's location services or Mozilla's location service,
> but free.  You can make use of it as a location provider in Android using
> the OpenBMap plugin
> <https://f-droid.org/repository/browse/?fdfilter=unifiednlp&fdid=org.openbmap.unifiedNlp>
> for microG unified NLP.  And you can contribute data as well using the 
> Radiobeacon
> app <https://f-droid.org/repository/browse/?fdid=org.openbmap>.  Seems to
> be in it's very early stages right now, but could be a real powerhouse with
> a little extra effort.
>
> ___
> 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] Tagging FOR the renderer

[François Lacombe]

Such topics are curently discussed during the voting of a power tagging
proposal on the wiki.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_supports_refinement
Have a look to the voting section.

As I understand, renders is A (out of plenty) way to look at the data.
It sounds very restrictive to make the data look like just a few people
want to see it. What about ones who just want to produce data without
looking at it from a narrow window ?

The main argument opposed is often "oh wait, this would cause a rendering
issue". Thus, why the render can't adapt if the information is available in
the data ?

I totally agree with people who separate data from renders (structure from
styles). It can be very frustrating to often prevent a good structure from
existing because styles won't match.

OSM should look at this problem deeply and make strong choices, before
letting other sorts of contributors to leave the boat.


All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2015-05-18 12:19 GMT+02:00 moltonel 3x Combo :

> On 18/05/2015, Daniel Koć  wrote:
> > I think the mission will be accomplished once we have it integrated with
> > OSM website somehow, just like we did with routing: there were already a
> > few routing services using our data, so we may not care, but for average
> > user they were just not here. And so is uMap.
>
> Routing is different in that it is immediately useful to
> *contributors*, who can now check that the OSM data is correct for
> routing, just like the slippymap is useful to check that the data
> looks good. uMap not so much : as a contributor, I'd rather use josm,
> taginfo, overpass, or even data dumps.
>
> As nice as it'd be, http://osm.org/ is not trying to be
> http://maps.google.com/. It's not trying to be the One True Map Portal
> that caters to every needs.
>
> Some reasons off the top of my head, some strong and some weak :
>  * The needs of contributors and users can easily conflict, and
> priority is/should be given to the contributors.
>  * Even without conflicts, the size of the contributor-focused todo
> list means that enduser-focused features get constantly pushed back.
> Help welcome.
>  * Becoming the internet's one-stop map website would require huge
> server ressources. Getting the kind of money required to run them
> would require huge changes to the way OSM is run, which'd be dangerous
> for OSM's freedom.
>  * Similarly for manpower requirements; volunteers wouldn't be enough
> anymore.
>  * A healthy ecosystem of commercial users is important for OSM. And
> they should be able to do a better job of serving the end-user, so
> it's probably a bad idea to compete with their use-case.
>
> ___
> 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] [HOT] Mapping high tension power lines in Nepal

[François Lacombe]

Hi Pierre,

I will take a look at it this evening.

Is there a live discussion taking place on IRC or wherever else than HOT ML
to get other contributors in touch ?
I'm not so at ease with HOT organisation.

It would be great to do this collectively and share the experience around
tagging schema.

Cheers from Lyon ;)

François
Le 15 mai 2015 17:08, "Pierre Béland"  a écrit :

> Hi François
>
> We need various expertises to answer quickly and produce data of quality
> It would be great if you could extract the Nepal powers in the area of the
> response around Kathmandu and revise the tagging schema.
> And  say Bonjour to the OSM Lyon contributors meeting at the charming Chez
> Thibault café.
>
> regard
>
> Pierre
>
>   --
>  *De :* François Lacombe 
> *À :* Brad Neuhauser 
> *Cc :* "HOT@OSM (Humanitarian OpenStreetMap Team)" ;
> OSM ; Jean-Guilhem Cailton ;
> OpenStreetMap in India ; OpenStreetMap
> Community in Nepal 
> *Envoyé le :* Vendredi 15 mai 2015 6h26
> *Objet :* Re: [HOT] [OSM-talk] Mapping high tension power lines in Nepal
>
> Hi,
>
> The power generation model was refined in 2013 and include some
> distinction between a power plant and a power generator.
> It would be convenient and sustainable to take care of this for this
> concern.
>
> http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement
>
> Power generator only regard any kind of device which convert energy from
> one sort to another. It should be mapped with power=generator
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dgenerator
>
> Power plant is the whole site and can be mapped with an area or a relation
> if the power plant isn't enclosed with a fence (which is often the case for
> hydro power plant).
> power=plant is the tag currently approved.
> http://wiki.openstreetmap.org/wiki/Tag:power%3Dplant
>
>
> The hydropower_project tag may be redundant with power=plant.
> Currently, it may be useful to map power=plant sites features only.
> Generators are supplementary information only used by specialized mappers.
>
> It would be great to don't use any other custom power=* value to allow the
> largest amount of mapper to work with these datas.
>
> I'll add some in my spare time.
>
> All the best
>
>
> *François Lacombe*
>
> fl dot infosreseaux At gmail dot com
> www.infos-reseaux.com
> @InfosReseaux <http://www.twitter.com/InfosReseaux>
>
>
>
> 2015-05-14 17:23 GMT+02:00 Brad Neuhauser :
>
> Fyi, user GautamPratik already started entering some hydro sites using the
> tag hydropower_project:name. Here's a search for that:
> http://overpass-turbo.eu/s/9lJ
>
> And one for power=generator generally in Nepal:
> http://overpass-turbo.eu/s/9lN
>
> Cheers, Brad
>
> On Thu, May 14, 2015 at 9:03 AM, Steve Bower  wrote:
>
> The Nepal Electric Authority would likely already have such a map, or
> relevant data:
> http://www.nea.org.np/
>
> Page 106 of their annual plan has a transmission line map:
> http://www.nea.org.np/images/supportive_docs/Annual%20Report-2014.pdf
>
> I did not find anything better in a quick search of their web site, but
> they could probably provide something.
>
> Steve
>
>
> On Thu, May 14, 2015 at 7:26 AM, Jean-Guilhem Cailton 
> wrote:
>
> Hi,
>
> As you may know, helicopters play a critical role in bringing help to
> Nepalese people affected by April 25 7.8 earthquake, and May 12 7.4
> aftershock, with roads blocked or made dangerous by landslides and
> unstable terrain.
>
> A USMC helicopter that was taking part in this effort is missing since
> May 12. Other helicopters involved in the search and rescue mission
> report that: "A primary concern for ongoing search and rescue efforts is
> unmarked high tension power lines, which have been reported and bisect
> many of the valleys in the search area".
>
> Some high tension power lines have already been mapped
> (http://overpass-turbo.eu/s/9lx , passed along to those conducting the
> searches). Starting from electrical dams makes it easier to spot them.
>
> If mappers experienced at mapping power lines could give a hand, this
> would be great. (Or others willing to learn, like me :) ).
>
> Bing is available for large parts of Nepal. A focus for current search
> and rescue effort is around Ghorthali (27.7517 N  86.0342 E) from where
> a Nepalese local reported seeing a helicopter crash. But of course high
> tension power lines would also be nice to have for Sindhupalchowk,
> Dolakha and other affected districts (see
> http://kathmandulivinglabs.github.io/quake-maps/).
>

Re: [OSM-talk] [HOT] Mapping high tension power lines in Nepal

[François Lacombe]

Hi,

The power generation model was refined in 2013 and include some distinction
between a power plant and a power generator.
It would be convenient and sustainable to take care of this for this
concern.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement

Power generator only regard any kind of device which convert energy from
one sort to another. It should be mapped with power=generator
http://wiki.openstreetmap.org/wiki/Tag:power%3Dgenerator

Power plant is the whole site and can be mapped with an area or a relation
if the power plant isn't enclosed with a fence (which is often the case for
hydro power plant).
power=plant is the tag currently approved.
http://wiki.openstreetmap.org/wiki/Tag:power%3Dplant


The hydropower_project tag may be redundant with power=plant.
Currently, it may be useful to map power=plant sites features only.
Generators are supplementary information only used by specialized mappers.

It would be great to don't use any other custom power=* value to allow the
largest amount of mapper to work with these datas.

I'll add some in my spare time.

All the best


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2015-05-14 17:23 GMT+02:00 Brad Neuhauser :

> Fyi, user GautamPratik already started entering some hydro sites using the
> tag hydropower_project:name. Here's a search for that:
> http://overpass-turbo.eu/s/9lJ
>
> And one for power=generator generally in Nepal:
> http://overpass-turbo.eu/s/9lN
>
> Cheers, Brad
>
> On Thu, May 14, 2015 at 9:03 AM, Steve Bower  wrote:
>
>> The Nepal Electric Authority would likely already have such a map, or
>> relevant data:
>> http://www.nea.org.np/
>>
>> Page 106 of their annual plan has a transmission line map:
>> http://www.nea.org.np/images/supportive_docs/Annual%20Report-2014.pdf
>>
>> I did not find anything better in a quick search of their web site, but
>> they could probably provide something.
>>
>> Steve
>>
>>
>> On Thu, May 14, 2015 at 7:26 AM, Jean-Guilhem Cailton 
>> wrote:
>>
>>> Hi,
>>>
>>> As you may know, helicopters play a critical role in bringing help to
>>> Nepalese people affected by April 25 7.8 earthquake, and May 12 7.4
>>> aftershock, with roads blocked or made dangerous by landslides and
>>> unstable terrain.
>>>
>>> A USMC helicopter that was taking part in this effort is missing since
>>> May 12. Other helicopters involved in the search and rescue mission
>>> report that: "A primary concern for ongoing search and rescue efforts is
>>> unmarked high tension power lines, which have been reported and bisect
>>> many of the valleys in the search area".
>>>
>>> Some high tension power lines have already been mapped
>>> (http://overpass-turbo.eu/s/9lx , passed along to those conducting the
>>> searches). Starting from electrical dams makes it easier to spot them.
>>>
>>> If mappers experienced at mapping power lines could give a hand, this
>>> would be great. (Or others willing to learn, like me :) ).
>>>
>>> Bing is available for large parts of Nepal. A focus for current search
>>> and rescue effort is around Ghorthali (27.7517 N  86.0342 E) from where
>>> a Nepalese local reported seeing a helicopter crash. But of course high
>>> tension power lines would also be nice to have for Sindhupalchowk,
>>> Dolakha and other affected districts (see
>>> http://kathmandulivinglabs.github.io/quake-maps/).
>>>
>>> (Please download and upload OSM data often, in case other mappers work
>>> on the same theme).
>>>
>>> Thanks,
>>>
>>> Jean-Guilhem
>>>
>>>
>>> ___
>>> HOT mailing list
>>> h...@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/hot
>>>
>>
>>
>> ___
>> HOT mailing list
>> h...@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/hot
>>
>>
>
> ___
> 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] MEP - pipelines

[François Lacombe]

I think there is a big difference between getting information from
templates (very guided and structured) and completely understand the whole
wiki.

Such software supplying information about tags would be to get them from
the ValueDescription template and give a link to the wiki page if human
want to read.

Many osmose tests may be aromatically setup just by reading the feature
restriction or the mandatory tags on a value description.
The same from presets, renders, ...


Cheers



*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2015-01-09 1:35 GMT+01:00 Martin Koppenhoefer :

>
> 2015-01-06 13:34 GMT+01:00 François Lacombe :
>
>> As Frederik suggested, I'm strongly in favor of software supplying
>> information about tags.
>> The wiki can be understood by humans but not so readable by machines.
>>
>
>
> I am not against software supplying information about tags, but we
> shouldn't expect miracles, machines are not only bad at understanding our
> wiki, they are generally bad at understanding the world.
> ;-)
>
> Cheers,
> Martin
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] MEP - pipelines

[François Lacombe]

+1 with Mike, there is nothing wrong with voting.

As Frederik suggested, I'm strongly in favor of software supplying
information about tags.
The wiki can be understood by humans but not so readable by machines.

We can imagine that draft of presets or renders can be dynamically
generated by software provided that a reference would be completed and
maintained.


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2015-01-06 12:56 GMT+01:00 Mike N :

> On 1/6/2015 6:47 AM, Chris Hill wrote:
>
>> If the new scheme is adopted in staged way that would be better than a
>> single mass edit, though it can still break data use for people who
>> don't follow OSM's mailing lists.
>>
>> I don't blame the proposer of the scheme; he's just following the daft
>> guidelines in the wiki. He probably hasn't realised what a phoney,
>> broken procedure voting is.
>>
>> Let's stop using voting.
>>
>
>   There's nothing wrong with voting - there just needs to be a well
> defined way to stage changes so that consumers are informed and can adapt
> to them as they come in.
>
>
> ___
> 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] MEP - pipelines

[François Lacombe]

2015-01-03 21:18 GMT+01:00 Chris Hill :

>
> I include some mechanical edits as vandalism, other than that, vandalism
> has not caused me any problems at all.
>

I was too.
And I don't understand why a static snapshot can't help you regarding
changes that don't suit your needs.


>
> If you must adjust tagging schemes that are in use, then you must devise a
> way to migrate to the new scheme in stages that doesn't break the existing
> processes that people use the data for. The proposer of the change is, IMO,
> fully responsible for this and if there is not a proper migration plan then
> the change should be quickly rejected. Simply replacing a tag with another
> tag via mechanical edit at an arbitrary point in time just isn't good
> enough to me.


I'm sorry, but I'm not very fond of bureaucracy.
My unpaid contribution is entirely done in free time (like many MANY people
here) and we won't spend it on personal interests considerations.

As Rainer rightly said, you're using free data without any guarantee.

My point isn't to not be user-friendly, but if I setup a "smooth" migration
process for YOU, it won't necessarily suit your neighbour's processes.
Why each data consumer can't adapt themselves and make an effort ?
Mechanical edits aren't bad if they are prepared and users informed about
it. Then a precise date can be discussed and everyone start using tags at
the same tags without letting the old ones in the DB for years.

Rainer, others and myself should be focused on consistency, versatility of
tags, doing things (like tag migration) once.

That's why OSM need a serious workflow refinement regarding tagging
reference. This new one should include mechanical edits and communication
about them toward data consumers.


*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] MEP - pipelines

[François Lacombe]

2015-01-03 18:22 GMT+01:00 Chris Hill :

>
> The values may need changing, e.g. type=sewer become substance=sewage
>

+1 indeed


>
>
> What about the maps I produce for my client? You're not likely to know
> about it as it is a private project. If you make a mechanical edit that
> breaks my render, should I send the bill for the changes to you rather than
> ask my client to pay? (This is not hypothetical I really do have a render
> using pipelines. I'm also using pipeline data to calculate approximations
> of distribution and aggregation).
>

The map your produce for private projects should be based on a static
export of OSM.
It will prevent any kind of vandalism to have impact on your valuable
services.

As data producer, may I ask you how can I refine any tagging scheme if so
called private projects have priority on information improvement and
general interest ?

Rainer, I doesn't avoid you contacting supp...@itoworld.com (and maybe any
other pipeline user) to inform them.


>
> If you must have a mechanical edit (which I don't see as vital), why not
> add substance=* tag alongside the type=* tag? That way existing renders and
> other uses will not be broken. Mech edits that are presumably intended to
> improve the quality of OSM data can badly damage confidence in the data by
> breaking existing use.
>

Why not. It will maintain type=* on features which shouldn't be described
with it and I think it's bad.

If we do so, the wiki must be assumed as a reference.
Because, when substance=* and type=* will be on every feature, who will be
able to make the distinguish between them both ?


All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] MEP - pipelines

[François Lacombe]

I don't see any objection to do as Rainer suggested.

Maybe someone can give us examples of conflict with any other data ?


All the best

*François Lacombe*

fl dot infosreseaux At gmail dot com
www.infos-reseaux.com
@InfosReseaux <http://www.twitter.com/InfosReseaux>

2015-01-03 17:50 GMT+01:00 Rainer Fügenstein :

>
> in accordance to the mechanical edit policy, I'd like to open the
> discussion on this list:
>
> a recently approved proposal introduced new tags for pipelines and
> marker [1] and changed an established tag:
>
> type=* was changed to substance=*
>
> the main reason for this change was a (possible) conflict with type=*
> as used in relations. also, type=* was considered to be too generic to
> describe the medium flowing within pipelines.
>
> this requires a mechanical update of existing data:
>
> nodes: containing pipeline=marker
> nodes: containing pipeline=substation
>   type=* --> substance=*
>
> ways: for man_made=pipeline
> ways: containing pipeline=substation
>   type=* --> substance=*
>
> As of now, I'm only aware of the ITO pipeline map (rendering), that is
> affected by this change.
>
> this affects data worldwide. I assume that this update will have to be
> executed several times in the near future, as mappers may continue to
> use type=* until they are aware of the new pipeline tagging scheme.
>
> cu
>
>
> ___
> 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] Wiki translate extension

[François Lacombe]

2014-07-24 22:47 GMT+02:00 Frederik Ramm :

> I wonder if it might be better to do what Wikipedia have done - instead
> of having one Wiki where the same articles exist in different languages
> (and often with wildly different content), have a Wiki for every
> language where the community using that language can build their own OSM
> reference (with Interwiki links where useful).
>


Not really the kindest idea for those who try to bring reusable tags
worldwide ;)

I'm ok to say all things aren't the same in each country. That's why wiki
and data should adapt in each translation/location.

According to you, we'd better split OSM in several projects, one for each
country and data consumers will do the rest.
That's not the same deal.
In my mind, OSM can't be break apart of its data reference if we want
consumers find our data useful. If you split the reference, you should
split the whole project.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Wiki translate extension

[François Lacombe]

Hi Andreas,

I agree with you about the automatic translation tool and that wasn't my
point.
Contributors should always translate documents by themselves without using
any automatic tool.

Nevertheless, some features of the extension would bring us some comfort
when dealing with translation topic.
I like the "percentage of translation for each language" indicator and the
capability to know when the English page is more accurate/up to date than
other ones.

May some alternative software can do the same job ?

Additionally to the visual editor (which is a really good tool too), it can
be a strong adding to the OSM wiki, don't you ?


Cheers.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-07-24 21:11 GMT+02:00 Andreas Goss :

> extension moved from requiring mediawiki 1.23 to requiring mediawiki 1.24
>> which is still in development.
>>
>
> Can't you just use the old version that worked with 1.23?
>
> __
> openstreetmap.org/user/AndiG88
> wiki.openstreetmap.org/wiki/User:AndiG88‎
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Wiki translate extension

[François Lacombe]

Hi all,

As for improving translation tasks on OSM wiki, how would you feel about
the Mediawiki Translate extension ?

https://www.mediawiki.org/wiki/Extension:Translate

I won't explain how important translated content is for non-english people
looking for reference or documentation.
This extension can really help us to maintain constant quality in this
localized content, especially tag pages.


I don't know if another better software extension exists for MediaWiki,
this one bring really good features.


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Upcoming openstreetmap-carto changes

[François Lacombe]

+1. Really great job, thank you guys :)


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-07-23 11:38 GMT+02:00 Janko Mihelić :

> It's great to see the default map layer finally moving forward!
>
>
> Janko
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] New ITO electricity distribution map

[François Lacombe]

Hi,

ITOWorld power & communication maps have been updated and are now online,
as a result of the feedback I gave to their support team.

Electricity Distribution map is now almost complete.
http://www.itoworld.com/map/4?lon=2.51848&lat=48.80986&zoom=10&open_sidebar=map_key&fullscreen=true

The main point was to deal with power substation inside stuff and pole
hosted features.
http://www.itoworld.com/map/4?lon=5.80635&lat=46.05588&zoom=17&fullscreen=true
http://www.itoworld.com/map/4?lon=6.19542&lat=46.07335&zoom=14&fullscreen=true

The map appearance will continuously be improved as long as proposals get
accepted.
Almost all mapped power=* features can be seen worldwide on this map, even
if it's not always the case (and doesn't have to be) on the main slippy map.

I want to thank them for time and resources investment. Everyone
contribution get a lot of value through it.


Cheers,

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Azimuth measurement

[François Lacombe]

I think the two GPS points method remains the best way to achieve azimuth
measurements, indeed.

Thank you gentlemen.

Any more advice ?

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-04-08 12:24 GMT+02:00 Christoph Hormann :

> On Tuesday 08 April 2014, François Lacombe wrote:
> > [...]
> > Is there a solution to that issue ?
> >
> > Measuring geographic north directly isn't so simple I think.
> >
>
> Probably the simplest and most accurate way is to use position
> measurements to determine the direction.  Look in what direction the
> feature you want to orient points, identify a point in that direction
> at suitable distance, go to that point and record the position (or use
> the already mapped data of it) and use both positions to determine the
> direction.
>
> With very simple tools (like piece of cardboard with an angular scale
> drawn on it) you can also record relative orientations and this way
> avoid the need to find a reference point in exactly the direction your
> object points to.  This is how you used to measure everything before
> the age of GPS.
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Azimuth measurement

[François Lacombe]

Hi,

Here is a topic discussed with a few people during State Of The Map FR last
week end in Paris.

Some features mapping would require to tag their azimuth as for knowing how
they are really installed in the environment.

For instance, benches mapped with nodes may be tagged with azimuth=*
because nodes don't tell which direction the bench follows.

But how contributors can measure it ?

Common devices like smart phones carry compass captors, used by compass
applications.
These captors only sense the magnetic north to determine the azimuth of the
device. The magnetic north is continuously diverting from the geographic
north.
Using the magnetic north isn't a good idea since the azimuth will be
continuously changing instead from the geographic azimuth.
There will be the same question regarding standard compasses.

Magnetic diversion is mathematically known and such azimuth could be
converted into geographic ones.

Is there a solution to that issue ?

Measuring geographic north directly isn't so simple I think.



Cheers.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Static render software working with OSM API-like

[François Lacombe]

Hi,

Thank you for objecting the OSM API is only there for editing. I wasn't
considering it properly.

Thus, writing a little translator for GeoJSON to use a Tilemill layer
sounds better to me since Tilemill is currently supported where
Halcyon/Potlach 2 seems deprecated.

It would be great that Tilemill allow users to specify a bounding box
associated to a geoJSON service request when adding a datastore, wouldn't
it ?


Cheers.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-03-25 13:12 GMT+01:00 Frederik Ramm :

> Hi,
>
> On 03/25/2014 12:21 PM, François Lacombe wrote:
> > I'm looking for a dedicated software, like Mapertive for instance, which
> > can directly connect to an OSM-api like (not xAPI, not overpass, just
> > the 0.6 original one) and render data statically (png, pdf...) according
> > to a MapCSS stylesheet in a given bounding box... like JOSM actually do
> > when downloading data.
>
> Since our own API would not allow such use (it is reserved for editing),
> people have had little incentive to code something like you describe,
> even though I understand how it would be of use in your particular
> situation.
>
> Closest I can think of is the original MapCSS demonstrator "Halcyon"
> (Flash) linked from here http://www.mapcss.org/
>
> 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
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Static render software working with OSM API-like

[François Lacombe]

Hi,

I'm looking for a dedicated software, like Mapertive for instance, which
can directly connect to an OSM-api like (not xAPI, not overpass, just the
0.6 original one) and render data statically (png, pdf...) according to a
MapCSS stylesheet in a given bounding box... like JOSM actually do when
downloading data.

I don't know if such an integrated and fully user-friendly solution
actually exists. The need comes from one of my customer's projects and
users just want to interact with a GUI (seems legit).

Maperitive may not satisfy them completely because of its CLI and the need
to separately download data before rendering them with a style sheet.
TileMill would be another strong candidate but it can't directly connect to
the original OSM API.
Maybe there are other apps I haven't tryed or even knew before.

They are working on a custom DB and only the API is conform to the OSM
specs.
It would be great to don't have to setup a custom overpass or another API
than the original one for the sack of maintenance simplicity.
The OSM API is there as for allowing them to transparently use some
client-side OSM software but there isn't a geospatial DB behind the scene
at all, thus they just can't use any of the server-side OSM toolchain
component.


Don't hesitate to let me know how do you feel regarding these
interoperability questions.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Street cabinets

[François Lacombe]

Well, I'll update my definition of street_cabinet and thank you to notice
me those existing tags.

A street cabinet concerned by the proposal differs from a monitoring
station :
- "Monitoring station" is only functional without taking size in account.
You can't going into a cabinet, it's only a rack where equipments are
installed and can be accessed by opening the door.
- "Monitoring station" is dedicated to monitoring when a street cabinet can
by used for many other activities (monitoring_station is far more specific
than street_cabinet).

Knowing that, I won't replace monitoring_station by a specific type of
street cabinet.
Mappers would use monitoring_station or street_cabinet either depending of
what is being mapped.

Typically :
- Urban air quality monitoring box => man_made=monitoring_station +
monitoring:air_quality=yes
- Traffic signals common box => man_made=street_cabinet +
monitoring:traffic=yes (we don't know if the box is only monitoring or
doing control & command too).

Proposal examples have to show the difference but I miss evocative pictures
to illustrate it properly.

I'll update the document later, I hope my point is clear here.


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-02-10 21:37 GMT+01:00 Gregory Williams :

> For some types of cabinet there’s already tags available, e.g.:
>
>
>
> Traffic counter:
>
> man_made=monitoring_station + monitoring:traffic=*
>
>
>
> Air quality monitoring:
>
> man_made=monitoring_station + monitoring:air_quality=*
>
>
>
> Cheers,
>
>
>
> Gregory
>
>
>
> *From:* François Lacombe [mailto:francois.laco...@telecom-bretagne.eu]
> *Sent:* 10 February 2014 15:38
> *To:* talk@openstreetmap.org
> *Subject:* Re: [OSM-talk] Street cabinets
>
>
>
> Well, the proposal has been created and hosted on this page :
> https://wiki.openstreetmap.org/wiki/Proposed_features/Street_cabinet
>
> It's obviously a draft yet, many elements are missing.
>
> I will ask @tagging a few more additional tags.
>
> Thank you for your feedbacks and feel free to use Talk page.
>
> Cheers.
>
>
> *François Lacombe*
>
> francois dot lacombe At telecom-bretagne dot eu
> http://www.infos-reseaux.com
>
>
>
> 2014-02-10 9:34 GMT+01:00 Lester Caine :
>
> François Lacombe wrote:
>
> For electricity, we do have power=cable_distribution_cabinet but IMHO it's
> definitely to specific.
> It would be replaced by man_made=street_cabinet +
> street_cabinet=power_distribution (+ operator=* + ref=* if applicable)
>
> Sounds a very reasonable expansion allowing finer detail to be recorded.
>
>
>
> And obviously there are traffic control, road lights and all other public
> facilities.
>
> Certainly traffic lights have similar street furniture ...
>
>
>
> In France, we have kind of postal boxes where a postal service employee
> deposits
> letters as for allowing a second person to distribute them later.
>
> We have the same thing in the UK as well ...
>
> This should probably be in the tagging list ... but I'm probably not alone
> in not having even joined that :)
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
>
> ___
> 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] Street cabinets

[François Lacombe]

Well, the proposal has been created and hosted on this page :
https://wiki.openstreetmap.org/wiki/Proposed_features/Street_cabinet

It's obviously a draft yet, many elements are missing.

I will ask @tagging a few more additional tags.

Thank you for your feedbacks and feel free to use Talk page.


Cheers.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-02-10 9:34 GMT+01:00 Lester Caine :

> François Lacombe wrote:
>
>> For electricity, we do have power=cable_distribution_cabinet but IMHO
>> it's
>> definitely to specific.
>> It would be replaced by man_made=street_cabinet +
>> street_cabinet=power_distribution (+ operator=* + ref=* if applicable)
>>
> Sounds a very reasonable expansion allowing finer detail to be recorded.
>
>
>  And obviously there are traffic control, road lights and all other public
>> facilities.
>>
> Certainly traffic lights have similar street furniture ...
>
>
>  In France, we have kind of postal boxes where a postal service employee
>> deposits
>> letters as for allowing a second person to distribute them later.
>>
> We have the same thing in the UK as well ...
>
> This should probably be in the tagging list ... but I'm probably not alone
> in not having even joined that :)
>
> --
> Lester Caine - G8HFL
> -
> Contact - http://lsces.co.uk/wiki/?page=contact
> L.S.Caine Electronic Services - http://lsces.co.uk
> EnquirySolve - http://enquirysolve.com/
> Model Engineers Digital Workshop - http://medw.co.uk
> Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
>
>
> ___
> 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] Street cabinets

[François Lacombe]

Thank for those details Philip.

How would you call things like that ?
https://wiki.openstreetmap.org/wiki/File:French_gas_delivery_point.jpg

I would looking for the most general term to add it to man_made and then
qualify its nature with a second tag like street_cabinet=*
Thirdly, domain-specific tags would do the trick to eventually give details
about what is hosted in the cabinet

For electricity, we do have power=cable_distribution_cabinet but IMHO it's
definitely to specific.
It would be replaced by man_made=street_cabinet +
street_cabinet=power_distribution (+ operator=* + ref=* if applicable)

And obviously there are traffic control, road lights and all other public
facilities.
In France, we have kind of postal boxes where a postal service employee
deposits letters as for allowing a second person to distribute them later.
https://www.google.fr/maps/preview/@48.127418,-1.640277,3a,19y,262.9h,69.34t/data=!3m4!1e1!3m2!1s7fn6hRmeXM84TL5rvHcjbg!2e0




*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-02-09 23:08 GMT+01:00 Philip Barnes :

> On Sun, 2014-02-09 at 11:42 -0700, Murry McEntire wrote:
> > "Street cabinet" has no meaning in my region. Looking at
> > manufacturer's sites and google images, I do see the term in use in
> > Britain (and some other places) for above ground enclosures with
> > vertical hinged doors. Did you also mean to include above ground
> > enclosures without hinged doors and subsurface enclosures with a
> > surface door? In the U.S. all types are probably most commonly known
> > as utility boxes. Utility box has other meanings, so is ambiguous, but
> > on a map would likely be interpreted correctly
> >
> > Perhaps someone could chime in with the British term covering all the
> > variations?
>
> In the UK a cabinet is used primarily for telecoms cabinets. They are
> quite common, although less common there are gas cabinets. I am not
> aware of water or electricity having them.
>
> In terms of telecoms, the cabinet is where the cable carrying multiple
> subscriber lines is split to provide individual lines to each house.
>
> The word has become more common since the roleout of fibre started. The
> term commonly used is FTTC (Fibre to the cabinet). In terms of telecoms,
> a cabinet does not have to be above ground, it can be accessed with
> removable covers and be below ground.
>
> The term cabinet just mean a small cupboard, it is also commonly used
> for things in the house such as a  'bathroom cabinet'.
>
> Phil (trigpoint)
>
>
> >
> >
> >
> >
> > On Sun, Feb 9, 2014 at 10:31 AM, François Lacombe
> >  wrote:
> > Hi,
> >
> >
> > I was pretty frustrated to don't encounter any common tag to
> > map street cabinets (trafic lights control, water metering,
> > phone connection points...) in my city.
> >
> >
> > I was looking for something like man_made=street_cabinet or
> > whatever but it's not widely used in the DB.
> >
> >
> > Should I propose this new value on wiki (with additional tags
> > to specify what kind of street cabinet, obviously) ?
> >
> >
> > It would be interesting to document street cabinets since many
> > of them dangerously deal with pavement accessibility in urban
> > zones.
> >
> > This would be done to prevent specific primary keys about a
> > particular infrastructure to appear on the map.
> >
> >
> >
> > Thanks in advance for any feedback.
> >
> > Cheers.
> >
> >
> > François Lacombe
> >
> > francois dot lacombe At telecom-bretagne dot eu
> > http://www.infos-reseaux.com
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
> >
> >
> >
> > ___
> > talk mailing list
> > talk@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> 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] Street cabinets

[François Lacombe]

According to Pieren pics, only surface enclosures with vertical hinged
doors are concerned by this proposal.

For a subsurface enclosure, I would use building=yes + location=underground
by default.
A subsurface enclosure often offers enough space to go down inside, thus
it's more a building than a simple cabinet (where you can't go inside).
http://img.directindustry.fr/images_di/photo-g/postes-transformation-enterres-26707-4123999.jpg(an
underground electrical substation)

For cable drawing rooms like this :
http://www.infos-reseaux.com/photos/image/95-chambre-importante
It's not big enough to use building but it's definetly not a street cabinet.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-02-09 21:22 GMT+01:00 Pieren :

> On Sun, Feb 9, 2014 at 7:42 PM, Murry McEntire 
> wrote:
> > "Street cabinet" has no meaning in my region.
>
> He's talking about something like this (but outdoor only):
> http://en.wikipedia.org/wiki/Enclosure_%28electrical%29
> http://en.wikipedia.org/wiki/File:Electricalenclosure.JPG
>
> Pieren
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Street cabinets

[François Lacombe]

Hi,

I was pretty frustrated to don't encounter any common tag to map street
cabinets (trafic lights control, water metering, phone connection
points...) in my city.

I was looking for something like man_made=street_cabinet or whatever but
it's not widely used in the DB.

Should I propose this new value on wiki (with additional tags to specify
what kind of street cabinet, obviously) ?

It would be interesting to document street cabinets since many of them
dangerously deal with pavement accessibility in urban zones.
This would be done to prevent specific primary keys about a particular
infrastructure to appear on the map.


Thanks in advance for any feedback.

Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] Power portal

[François Lacombe]

Thank you guys for answers.

I'll move all French power=portal to power=tower + design=portal as
Polderrunner suggested.

May everyone be encouraged to do so everywhere.


Cheers.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com


2014-02-07 0:06 GMT+01:00 Craig Wallace :

> On 2014-02-06 21:51, François Lacombe wrote:
>
>> Hi folks,
>>
>> I feel a bit disappointed with the power=portal tag, pretty widely used
>> in Germany for instance.
>>
>> It seems to document start points of a power line in power substations.
>> Have a look :
>> http://www.power-technology.com/contractor_images/pauwels/
>> 4_Compact-substation.jpg
>>
>> There are only 18 of them in France, I thought it would be better to
>> don't use it. I don't even know if it's the right English term.
>> Nevertheless the idea of considering portals instead of standard towers
>> in substations sounds good.
>>
>>
>> How do you feel about this ?
>>
>
> I am not an expert on this, but I have never heard this described as a
> 'portal'.
> In English a portal is some sort of opening or entrance or hole, so it
> doesn't make much sense for part of a power line or a tower.
>
> I'm not sure what the correct name for this is. I would suggest something
> like "termination tower" or maybe "terminator".
>
> Craig
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Power portal

[François Lacombe]

Hi folks,

I feel a bit disappointed with the power=portal tag, pretty widely used in
Germany for instance.

It seems to document start points of a power line in power substations.
Have a look :
http://www.power-technology.com/contractor_images/pauwels/4_Compact-substation.jpg

There are only 18 of them in France, I thought it would be better to don't
use it. I don't even know if it's the right English term.
Nevertheless the idea of considering portals instead of standard towers in
substations sounds good.


How do you feel about this ?

Many substations are moved from sub_station to substation, it's a great
occasion to check this out too.


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Pipeline proposal vs PODS

[François Lacombe]

Hi,

As suggested on the talk page of the PipelineExtension proposal, it should
be built according to the PODS data model.
http://wiki.openstreetmap.org/wiki/Proposed_features/PipelineExtension

http://www.pods.org
PODS is a geographical data model to help data exchange between companies
who operate pipelines. It would be great that OSM can provide compatible
data.

But it seems to be a bit complex to deal with PODS and I'm not so familiar
with it.
Is someone knowledgeable about it and would like to help us ?


Thanks.

*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Power icons

[François Lacombe]

Hi,

I'm looking for icons which can be used in wiki, tools and renders for
power infrastructures.

There are currently two big power proposals (out of four) which had been
accepted and it would be great to have a few of pictures / graphic stuff to
improve wiki and renders look and feel.

I'm not so good at graph design and not even at ease with illustrator. Do
someone qualified want to help us with it ?
Maybe an existing library can be used but :
- It would be great to find all icons in the same place (to prevent design
differences)
- It would be great to find it under creative commons.

We need about 20/25 icons for different map features. Generators
sources/method and type icons are pretty well furnished but they can be
unformalized too.

Let's discuss how will it look like, many thanks in advance.


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Deprecated tag status

[François Lacombe]

Hi,

Shouldn't we use some "deprecated" status on tag info box on wiki pages
when the tag is as such ?

Example here : http://wiki.openstreetmap.org/wiki/Tag:power%3Dstation

Status is "Approved" but this tag is deprecated too.

It will be more user friendly and representative, better than a big "don't
use it" at the top of the page.


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk] Power generation refinement approved

[François Lacombe]

Hi,

Last June 11, the power generation refinement proposal was approved by 30
wiki users.
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_generation_refinement

It aims to provide a strong and consistent tagging model to map power
plants and power generators too.
http://wiki.openstreetmap.org/wiki/Tag:power%3Dplant
http://wiki.openstreetmap.org/wiki/Tag:power%3Dgenerator

Thus, power=plant replace the deprecated power=station (for places where
power is generated only, see
http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinementfor
other OSM use cases).
power=generator is reserved for devices which convert power from one kind
to another kind.

Wiki update is still in progress but rendering models and editors presets
should be upgraded with that new stuff.

If there's anything you need to bring this up to date, please ask here and
I would be pleased to precise any unclear point.

Please note that 3 other proposals are still draft or RFC and should be
voted in next monts.
http://wiki.openstreetmap.org/wiki/Proposed_features/Substation_refinement
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement
http://wiki.openstreetmap.org/wiki/Proposed_features/Power_routing_proposal


Cheers.


*François Lacombe*

francois dot lacombe At telecom-bretagne dot eu
http://www.infos-reseaux.com
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] magical road detector to play with

[François Van Der Biest]

Thanks for this new service.

I felt quite frustrated when I saw the silverlight stuff warning, so I
decided to create a simple client with OpenLayers.
Here it is: http://maps.qualitystreetmap.org/bingtracing/

I really like the whole idea, but the service lacks a confidence index
for the returned feature.
I also guess that the algorithm gives several paths and only the one
with the highest score is returned.
Is it possible to get the other paths along with their scores ?

F.

On Thu, Feb 3, 2011 at 6:17 PM, Steve Coast  wrote:
> http://www.bing.com/community/site_blogs/b/maps/archive/2011/02/03/automatically-detect-roads-with-bing-aerial-imagery.aspx
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>

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

Re: [OSM-talk] Aerial imagery for Kyrgyzstan

[François Van Der Biest]

I've extended QualityStreetMap's coverage to this region :
http://www.qualitystreetmap.org/osmqa/?lang=kg
For more information on QSM, please refer to
http://www.slideshare.net/fvanderbiest/20100712-sotm-lightning-talk-qualitystreetmaporg-and-osmqa

Hope this helps,
F.

PS: You can help translating the user interface to russian. Just send
me this file 
http://code.google.com/p/osmqa/source/browse/trunk/osmqa/public/app/lib/App/Lang/kg.js
after translation

2010/8/3 Frédéric Bonifas :
> Hi,
>
> Following the recent crisis in Kyrgyzstan, aerial imagery has been
> asked to UNOSAT. It is now available for tracing in OSM and only for
> that purpose, as the imagery has been purchased commercially.
>
> Due to the licence with the imagery provider, the WMS URL is not for sharing.
> All data traced from this imagery should be credited “UNOSAT, e-geos”
>
> Please get back to me at fredericboni...@gmail.com if you are
> interested and I will give you the WMS URL.
>
> There is a wiki page to coordinate the work :
> http://wiki.openstreetmap.org/wiki/WikiProject_Kyrgyzstan
>
> Thanks
>
> --
> Frédéric Bonifas
> +33672652807 skype:fredericbonifas
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] presentation on introduction to osm technicals

[François Van Der Biest]

Hi Mikel,

This page [1] deals with the use of the XAPI with OpenLayers. It's
very interesting, but in French.
The app [2] source might be more readable/

HTH,
F.

[1] http://www.geotribu.net/node/260
[2] http://88.191.39.115/fabien/geotribu/application/osm/xapi/

On Mon, Jun 7, 2010 at 8:14 AM, Mikel Maron  wrote:
> Hi
>
> I'm giving a workshop on Friday at the Africa Agricultural GIS Week in
> Nairobi. The first half of the day will be a short mapping party. The second
> half of the day will survey topics in how to use OSM data ... in OpenLayers,
> Shapefiles, using osmosis, API, etc. The audience will be GIS professionals.
>
> Does anyone have any presentation files or materials that covers this kind
> of thing?
>
> Thanks
> Mikel
>
> == Mikel Maron ==
> +254(0)724899738 @mikel s:mikelmaron
> http://mapkibera.org/
> http://wiki.openstreetmap.org/index.php/Haiti
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
>

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

[OSM-talk] Video featuring ITO's "Year of Edits"

[François Van Der Biest]

Very nice en/fr video dealing with visual complexity, data
visualization :
http://digup.tv/index.php?rub=videos&item=70%E3%80%88=fr or
http://goo.gl/294o
I was pleased to see OSM mentioned and ITOWorld's "2008: a year of
edits" video featured.

F.

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

Re: [OSM-talk] Help to import Rio de Janeiro city data to OSM - misaligned shapefiles

[François Van Der Biest]

Hi all,

I'd recommend having a look at this automated road selection process
before hand selecting features to import :
http://wiki.openstreetmap.org/wiki/BMO#Differential_import

If needed, I can provide help, since I'm the one who wrote the page.

F.

On Sun, May 16, 2010 at 4:49 PM, Jukka Rahkonen
 wrote:
> Arlindo Pereira  arlindopereira.com> writes:
>
> ...
>>
>> Now, moving on to the second question: the largest shapefile
>> (Quadras.shp, with the streets and the blocks) has 68 MB, and after
>> conversion (and two hours later) it becomes a huge 416 MB .osm file,
>> and I can't open it with JOSM (ok, after half an hour it loads up on
>> the editor but I can't do anything because the program freezes). How
>> can I split it in smaller files for an easier edition?
>
> One possibility is to edit the shapefile with some GIS program like OpenJUMP 
> or
> QGis, select features from a smaller area and save that part to a new 
> shapefile.
> That way you could also select only some kind of features to import, or cut 
> off
> those you do not want at all.
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>

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

[OSM-talk] European Commission working groups on economic aspects of PSI Re-use

[François Van Der Biest]

FYI, http://www.epsiplatform.eu/news/news/economic_working_groups_launched
"The European Commission has launched working groups on economic aspects of
PSI Re-use
[...]
The meeting on the 12th November 2009 agreed to establish 5 working groups
on PSI Economic Indicators on the following themes:
 - Address Information
 - Cadastral Information
- [...]"

If not already done, it might be interesting to provide feedback to the
working groups regarding our interest in those data.
The agreement with the Cadastre in France was a major step forward.

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

Re: [OSM-talk] Web GIS Application

[François Van Der Biest]

Hi John,

On Fri, Mar 12, 2010 at 11:26 AM, John Yumbya  wrote:
>
> Hi OSM geeks,
>
> I need a simple Web GIS Application tool which allows user interactivity. 
> Thanks

If you mean "Web GIS Application toolkit", you'll probably be interested in :
- http://openlayers.org
- http://geoext.org
- http://mapfish.org
- ...

HTH,
F.

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

[OSM-talk] how to remove objects from the database ?

[François Van Der Biest]

Hi list,

Last year, we (= some french osmers) imported some data around Brest
city (see for instance http://wiki.openstreetmap.org/wiki/BMO).
Unfortunately, the source shapefiles were badly converted to WGS84,
and this resulted in a shift of several meters for all data. Thus, we
need to delete previously imported data (identified by the source tag)
and reimport.

I could not find an easy way to batch delete data from the OSM db ...
I guess there are reasons to make it easier to import data than to delete it ;-)

Osmosis seems to be able to "produce change sets using database
history tables". Is this the way to go ?
Yet, osmosis's script/pgsql_simple.txt file says "The pgsql simple
schema is a PostgreSQL schema utilising postgis extensions that is
capable of storing a snapshot of OSM data. No history is maintained."
I could not find any other SQL file which would let us create a
database with history tables.

Thanks for helping !
F.

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

Re: [OSM-talk] Extended GeoEye imagery now available for use on OSM

[François Van Der Biest]

Hi,
Tiles are ready here : http://maps.nypl.org/relief/haiti.html. Thank's for
the work Schuyler.
Is there need for more bandwidth, or is it OK ?
If needed, Camptocamp could host the dataset, eventually on Amazon.
Cheers,
F.

On Sat, Jan 16, 2010 at 3:23 AM, Schuyler Erle  wrote:

> * On 15-Jan-2010 at  6:32PM EST, Ævar Arnfjörð Bjarmason said:
> >
> > I just meant to mirror them to something faster than the  Google
> > server (the OSM cluster should get ~30MB/s from cassini).
> >
> > It would be better if someone else could set up the actual tile/wms
> serving.
>
> I'm working on that now, hope to have something up by morning!
>
> SDE
>
> ___
> talk mailing list
> talk@openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk