from:"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 craig...@fastmail.fm:

 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] Street cabinets

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] Street cabinets

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 pier...@gmail.com:

 On Sun, Feb 9, 2014 at 7:42 PM, Murry McEntire murry.mcent...@gmail.com
 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

Re: [OSM-talk] Street cabinets

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 p...@trigpoint.me.uk:

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
francois.laco...@telecom-bretagne.eu 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

Re: [OSM-talk] Street cabinets

2014-02-10 Thread 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 les...@lsces.co.uk:

 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

2014-02-10 Thread 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 greg...@gregorywilliams.me.uk:

 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 les...@lsces.co.uk:

 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

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

2014-03-25 Thread 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] Static render software working with OSM API-like

2014-03-25 Thread 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 frede...@remote.org:

 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] Azimuth measurement

2014-04-08 Thread 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] Azimuth measurement

2014-04-08 Thread 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 chris_horm...@gmx.de:

 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] New ITO electricity distribution map

2014-04-30 Thread 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.51848lat=48.80986zoom=10open_sidebar=map_keyfullscreen=true

The main point was to deal with power substation inside stuff and pole
hosted features.
http://www.itoworld.com/map/4?lon=5.80635lat=46.05588zoom=17fullscreen=true
http://www.itoworld.com/map/4?lon=6.19542lat=46.07335zoom=14fullscreen=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] Upcoming openstreetmap-carto changes

2014-07-23 Thread 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ć jan...@gmail.com:

 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] Wiki translate extension

2014-07-24 Thread 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] Wiki translate extension

2014-07-24 Thread 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 andi...@t-online.de:

 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

Re: [OSM-talk] Wiki translate extension

2014-07-24 Thread François Lacombe

2014-07-24 22:47 GMT+02:00 Frederik Ramm frede...@remote.org:

 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] MEP - pipelines

2015-01-03 Thread 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 r...@oudeis.org:


 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] MEP - pipelines

2015-01-03 Thread François Lacombe

2015-01-03 18:22 GMT+01:00 Chris Hill o...@raggedred.net:


 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

2015-01-03 Thread François Lacombe

2015-01-03 21:18 GMT+01:00 Chris Hill o...@raggedred.net:


 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

2015-01-06 Thread 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 nice...@att.net:

 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

2015-01-09 Thread 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 dieterdre...@gmail.com:


 2015-01-06 13:34 GMT+01:00 François Lacombe fl.infosrese...@gmail.com:

 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] [HOT] Mapping high tension power lines in Nepal

2015-05-15 Thread 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 brad.neuhau...@gmail.com:

 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 sbo...@gmavt.net 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 j...@arkemie.com
 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] [HOT] Mapping high tension power lines in Nepal

2015-05-15 Thread 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 pierz...@yahoo.fr 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 fl.infosrese...@gmail.com
 *À :* Brad Neuhauser brad.neuhau...@gmail.com
 *Cc :* HOT@OSM (Humanitarian OpenStreetMap Team) h...@openstreetmap.org;
 OSM talk@openstreetmap.org; Jean-Guilhem Cailton j...@arkemie.com;
 OpenStreetMap in India talk...@openstreetmap.org; OpenStreetMap
 Community in Nepal talk...@openstreetmap.org
 *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 brad.neuhau...@gmail.com:

 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 sbo...@gmavt.net 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 j...@arkemie.com
 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

Re: [OSM-talk] Tagging FOR the renderer

2015-05-18 Thread 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 molto...@gmail.com:

 On 18/05/2015, Daniel Koć daniel@koć.pl 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] Neat use of OpenStreetMap

2015-05-28 Thread 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 ba...@ursamundi.org:

 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=unifiednlpfdid=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

[OSM-talk] Antennas and radio networks supports mapping

2015-07-15 Thread 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] Antennas and radio networks supports mapping

2015-07-15 Thread François Lacombe

Thank you Dave,


2015-07-15 14:15 GMT+02:00 Dave Stanley da...@dbsconsult.co.uk:

 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

Re: [OSM-talk] A big debate about OSM quality in Strava community

2015-09-18 Thread 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] VisualEditor on the OSM wiki

2016-01-03 Thread 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 <rob.j.nicker...@gmail.com>:
> 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

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

2016-01-19 Thread 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

[OSM-talk] Wiki power pages merging

2016-03-06 Thread 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

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

2017-01-30 Thread 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

2017-01-28 Thread 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

Re: [OSM-talk] The New Cloud Atlas - Mapping Physical Infrastructure of the Internet with OSM

2016-08-17 Thread 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

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

2016-08-31 Thread 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] Map features page on wiki

2016-09-21 Thread 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

2016-09-21 Thread 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

2016-09-26 Thread 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

2016-09-26 Thread 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

2016-10-01 Thread 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

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

2016-11-25 Thread 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] JOSM 11223 won't start : expired certifcate

2016-11-25 Thread 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 <si...@poole.ch>:

> 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] Wiki TagList and TagKey/exists templates

2016-12-24 Thread 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] OSM Wikidata SPARQL service updated

2017-08-14 Thread 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] JOSM Custom Presets - Combo to set multiple tags

2017-08-29 Thread 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 Tag History updates - call for help

2017-11-25 Thread 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ć <daniel@koć.pl>:

> 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

[OSM-talk] OSM tagging validation lib

2017-12-24 Thread 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 tagging validation lib

2017-12-24 Thread 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" <si...@poole.ch> 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" <fl.infosrese...@gmail.com>
> 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

Re: [OSM-talk] OSM tagging validation lib

2017-12-24 Thread 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] Mapping rivers that flow into/through lakes?

2018-02-23 Thread 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=27.98062=
>> -16.95179=11
>> ) or here (
>> http://tools.geofabrik.de/osmi/?view=water=-8.26705=
>> 52.99047=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] Mapping rivers that flow into/through lakes?

2018-02-23 Thread 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=28.57869=-16.75136=11 )?
>

Yes: http://tools.geofabrik.de/osmi/?view=water=28.57869;
lat=-16.75136=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=28.57869;
lat=-16.75136=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?

2018-02-23 Thread 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] Power Lines and topological error detection

2018-03-07 Thread 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] Unify Mapping and wiki accounts? -- WAS: Vote cheating?

2018-03-18 Thread 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] Waterway=* and Waterways wiki pages merge

2018-03-23 Thread 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 <dieterdre...@gmail.com>:

>
>
> 2018-03-23 17:58 GMT+01:00 Martin Koppenhoefer <dieterdre...@gmail.com>:
>
>> 2018-03-23 17:01 GMT+01:00 François Lacombe <fl.infosrese...@gmail.com>:
>>
>>>
>>> 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

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

2018-03-23 Thread 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] Waterway=* and Waterways wiki pages merge

2018-03-23 Thread 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 <dieterdre...@gmail.com>:

>
>
> 2018-03-23 15:45 GMT+01:00 François Lacombe <fl.infosrese...@gmail.com>:
>
>> 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

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

2018-02-27 Thread 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

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

2018-10-04 Thread 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] LinuxFoundation Energy Summit 2018 in Edinburgh (too few OSM inside)

2018-10-07 Thread 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] Really heavy browser load with Overpass-turbo map display

2018-09-23 Thread 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] Really heavy browser load with Overpass-turbo map display

2018-09-23 Thread 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

Re: [OSM-talk] Ground truth for non-physical objects

2018-12-15 Thread 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=13,47.2096,-1.51929=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] What use is OpenStreetMap?

2019-01-04 Thread 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
> 
>
> ___
> 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] OpenStreetMap at CES

2019-01-11 Thread 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] Overpass API turned off due to Upload Filter thread

2019-03-21 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] FCC public documents license and submarine cables mapping

2019-04-13 Thread 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] FCC public documents license and submarine cables mapping

2019-04-14 Thread 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

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

2019-06-10 Thread 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?

2019-06-10 Thread 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

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

2019-09-01 Thread 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

2019-08-28 Thread 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

[OSM-talk] Wiki templates and DataItems

2019-11-22 Thread 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] Wiki templates and DataItems

2019-11-25 Thread 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

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

2019-09-22 Thread 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

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

2019-12-21 Thread 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=15,43.31032,5.38377=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

2019-12-20 Thread 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=15,43.31032,5.38377=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] Acknowledgement for the wiki documentation

2020-02-11 Thread 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

2020-01-17 Thread 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] Fwd: Re[2]: Tag:manhole=telecom

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=1587328637=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=1587329086=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] Fwd: Re[2]: Tag:manhole=telecom

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=1587328637=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=1587329086=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

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] Tag:manhole=telecom

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] New diary: 10 years of French power transmission network mapping

2020-04-25 Thread 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] Quality and the Openstreetmap value chain

2020-05-17 Thread 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] Proposed new status for tags in the wiki: "import" for undiscussed tags that were only used by an import

2020-03-17 Thread 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
>
>  
>
> archaic
>
> passe
>
> stale
>
>
>
> 
> ___
> 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 end of waterway map

2024-01-30 Thread 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-fr] Modélisation du réseau électrique français

2013-01-02 Thread François Lacombe

Le 2 janvier 2013 19:40, Rodolphe Quiedeville rodol...@quiedeville.org a
écrit :

 Bonjour à toi :-)

Bonjour Rodolphe,



 Information très intéressant, je les avait contacté il y a un peu plus
 d'un an et il m'avait répondu que la carto du réseau existait déjà et
 m'avait fournit un super PDF A4 :-) J'avais bien rit à l'époque. A ma
 deuxième relance la réponse m'avait été faite que le réseau dans son détail
 était considéré comme donnée sensible donc non publiable.


Ah très bien, je me suis donc peut-être emballé un peu trop vite.

En fait il existe une offre à laquelle on peut adhérer pour recevoir une
version shape du réseau RTE mais uniquement pour un usage interne (pour
planifier des travaux ou autres).
Il ne s'agit pas de les rendre disponibles en ligne donc c'est pas très
intéressant pour OSM.

En revanche, rien n'empêche de balayer les compte rendus de réunion
d'information publique sur les projets ou les communiqués de presse de RTE
pour avoir les tracés des projets souterrains ou de s'appuyer sur
l'imagerie aérienne pour connaitre le cheminement des circuits.

http://maps.google.fr/maps/ms?ie=UTF8hl=frmsa=0msid=108612998568428175821.00047008d975a934653d1t=hz=7


Le 2 janvier 2013 20:36, Plop76 vaujani...@free.fr a écrit :

 Salut fanfouer ;)


Bonjour Plop, peut-être nous sommes-nous déjà rencontré? :)




 C'est abordé sur le wiki du tag cables :

 «Multiple independent circuits can share the same towers/poles. You may
 use multiple semicolon-separated values grouped by voltage (for example.
 cables=6;3).»

 Perso c'est ce que je fais en attendant que la question soit «tranchée» et
 en faisant pareil et dans le même ordre pour la tension.


C'est le plus commode pour l'intégrer dans le node/way/relation d'OSM mais
ca n’empêche pas l'indétermination topologique.

Si dans l'exemple il y avait eu plusieurs circuits du même type à y
aboutir, comment savoir qui est connecté avec qui?
Il y a des pylônes qui ont plusieurs niveaux d'ancrage sans que les
circuits soient connectés entre-eux.
https://maps.google.fr/maps?q=lausannehl=enll=46.562426,6.559904spn=0.002068,0.004128sll=45.86462,6.057506sspn=0.002962,0.008256t=hhnear=Lausanne,+Vaud,+Switzerlandz=19layer=ccbll=46.562426,6.559904panoid=bLcu9m2dZc60Zupe4aEnpQcbp=12,129.74,,0,-47.95

En fait ca me semblerai cohérent de faire deux (ou +) ways superposées en
cas de double (ou +) circuits.
Pour que ca soit manipulable, il faudra adapter la représentation en
conséquence :

+--+== +===+
  (2 circuits superposés)

De là à voir si la chaine OSM peut le supporter ou l'adopter facilement...



 Il y a power=cable + location=underground ou power=underground_cable. Cf.
 http://wiki.openstreetmap.org/wiki/Proposed_features/Power_transmission_refinement


Très bien, j'adopte!
Par contre ça me laisse perplexe parce que quand c'est de l'aérien, on
parle de line alors que quand c'est souterrain, on parle de cable.

A des niveaux de tension pareils, les câbles souterrains supportent chacun
une phase dans des tubes séparés
http://www.infos-reseaux.com/photos/album/61-genie-civil-souterrain

En HTA et en BTB ce peut-être différent, il existe de vieux câbles papier
qui supportent les 3 phases (+ neutre en distribution locale).
Mais là, un tag power=line + cables=3 ou cables=1 sera suffisant pour
donner l'information.

Loin de moi l'envie de cartographier chaque phase, un circuit en HTB étant
systématiquement triphasé en France.
Du coup power=line + location=underground ne serait-il pas autant
approprié?

Par contre cela vaudrait le coup de créer power=medium_line ou autre pour
différencier les artères HTA des lignes de distribution BTB (400V) qui sont
actuellement tous deux identifiés par power=minor_line

En France, je ne prendrais la peine de cartographier que la HTA et les
transfos HTA/BTB vu la capillarité et la facilité d'évolution des réseaux
de distribution locaux (ou alors il faut un suivi régulier et pointu).


No connaissant pas l'organisation sur le bout des doigts, ces questions ne
se discutent peut-être pas au niveau français mais au dessus non?

A bientôt,

-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Modélisation du réseau électrique français

2013-01-03 Thread François Lacombe

Bonjour,

Le 3 janvier 2013 10:09, David Crochet david.croc...@online.fr a écrit :

 J'ai eu l'occasion de le faire pour la nouvelle ligne HTA de l'EPR avec la
 dépose et la mise en souterrain, ainsi que du déplacement de ligne sur le
 département de la manche, puisque les documents mis en ligne sont ceux que
 le publique pouvait aller consulter auprès des commissaire des
 consultations publiques. et donc j'en ai profiter pour amender OSM :
 http://www.openstreetmap.org/?**lat=49.17259lon=-1.33565**
 zoom=15layers=Mhttp://www.openstreetmap.org/?lat=49.17259lon=-1.33565zoom=15layers=M
 où l'on peut voir la déviation souterraine singulière d'une ligne
 aérienne. Mais également
 http://www.openstreetmap.org/?**lat=49.08075lon=-1.26145**
 zoom=15layers=Mhttp://www.openstreetmap.org/?lat=49.08075lon=-1.26145zoom=15layers=M
 d'où l'absence de pylône


Excellent, c'est une affaire qui tourne!

Par contre ne vaudrait-il mieux pas utiliser power=line +
location=underground que power=line + tunnel=yes?
Peut-être ont-ils creusé une galerie visitable pour supporter la section
souterraine?



  Pour ma part, cela devient très compliqué avec la situation que tu
 décrits, surtout en édition pour que déjà tout le monde comprennent que les
 réseaux sont intégrés lors d'une modification.


Oui je reconnais qu'avoir plusieurs way superposées c'est compliqué à
maintenir.

Je suis passé à côté de l'aspect relation qui relie n circuits aboutés à un
même nœud.
La topologie décrite par le wiki me semble maintenant beaucoup plus claire
et correcte.

Il faudra par contre prendre garde à bien sectionner les ways à chaque
pylône présentant des dérivations sans quoi des tronçons qui ne supportent
pas le circuit en réalité risquent de se trouver membre des relations
malgré eux.


Sur la partie représentation, on pourrait représenter ces circuits
parallèles en représentant les relations au lieu des ways.
Je ne sais pas si c'est quelque chose que mapnik saurait gérer...




 Non, il est extremement rare que les 3 phases soient physiquement éloignés
 l'un de l'autre. Donc je le réseau et non la constitution physique. On ne
 tague pas toutes les voies de circulation même si elle sont non séparés
 physiquement mais éloignées l'une de l'autre d'environ 1m50 sans
 discontinuité du support de roulement dans le sens de la largeur de la voie
 ?


Oui je suis bien de cet avis aussi mais ce sont les tag eux-mêmes qui
introduisent line et cable comme deux choses différentes.
Du coup, si on ne cartographie pas les voies (câbles) mais uniquement les
routes (lignes électriques), pourquoi avoir ce tag power=cable qui n'est
jamais sensé servir?



 Oui, mais ce sont des éléments géographiques, donc en toute logique
 peuvent être intégrés dans la base et leur durée de vie (ie l'implantation
 physique) est pérenne sur moyen voire long terme.

Ok pour l'utilité géographique des lignes BTB aériennes.
En ville tout est parfois enterré de plus en plus facilement.

Pour avoir une carte fiable et à jour pour ce niveau de tension, qui
résiste rarement aux modifications de la voirie, il va falloir suivre tout
ça régulièrement.


Sur la question du taggage de la HTA vs BTB il y a aussi cette possibilité :
HTA : power=minor_line + tension=2 + operator=ERDF...
BTB : power=minor_line + tension=400 + operator=ERDF...


A bientôt,

-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Modélisation du réseau électrique français

2013-01-03 Thread François Lacombe

Le 3 janvier 2013 11:12, David Crochet david.croc...@online.fr a écrit :

 Est-ce que RTE  applique des informations de réseau d'énergie indépendant
 du réseau physique comme le fait la SCNF qui applique un numéro de ligne
 (le Paris-Granville) indépendant des voies physique mais liés quand même ?
 Dans ce cas, pas la peine de simuler la présence de plusieurs réseaux au
 sein d'un même « chemin » puisque la relation va faire le tri correctement
 dans ce cas


Si les voies SNCF correspondent aux files de pylônes alors la réponse est
oui.
RTE ne connait même que le circuit qui est codifié selon le nom des postes
aux extrémités et suivant un ordre numérique (plusieurs circuits peuvent
correspondre aux mêmes extrémités).
Les files de pylônes ne sont pas codifiées en tant qu'artère, par contre
les pylônes possèdent des numéros (selon un des circuits supportés je crois)

Je suis aussi d'accord pour dire que la relation réifie correctement le
circuit, il faut que tout s'ordonne dans ma tête surtout :)


Il peut exister des cas particuliers : les piquages.
C'est le cas à Montchanin : http://goo.gl/maps/fjdKy
Le circuit de gauche se voit ponctionner vers le poste électrique tout
proche. Là, le modèle d'OSM à base de relation permet de traiter ce cas
avec un tag via= par contre je ne sais pas comment RTE fait puisque le
circuit n'a pas 2 mais 3 extrémités.

D'ailleurs les apparences sont parfois trompeuses puisque ce circuit est
construit en techno 400 kV mais n'accepte en réalité que du 225 kV (cf le
piquage et les cartes de RTE).
Le 400 kV arrive prochainement.
http://www.rte-france.com/fr/nos-activites/nos-projets/bourgogne/les-projets-en-cours-en-bourgogne



 Car « power=cable » sous entend implicitement « layer = -1 » ce qui évite
 par exemple à un logiciel de dire qu'un câble croisent sans connexion une
 ligne. alors qu'il n'ont pas le layer indiqué


Je ne comprends pas très bien cette histoire de layer.
Deux ways peuvent se croiser, elles ne seront connectées que si elles ont
un node en commun à l'endroit du croisement.
Pourquoi vouloir hiérarchiser de cette façon?



 Mais très peu visible sauf les balises au sol indiquant la présence d'un
 réseau souterrain

Ce que je voulais dire est qu'un contributeur OSM pourra faire la carto
d'une artère BTB aérienne qui disparaitra 15 jours plus tard sous le coup
d'une dissimulation de réseau.

La capillarité fait que les zones à surveiller sont multiples sans avoir
une visibilité correcte sur les projets des concessionnaires de ces réseaux.
Sur la HTB (et ca démarre un peu sur la HTA) les projets sont connus et les
travaux bien plus voyant.

C'est juste une question de capacité de mise à jour, sinon on est bien
d'accord que le max de données disponibles reste l'objectif.

-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Modélisation du réseau électrique français

Bonjour,

Le 3 janvier 2013 23:04, Christian Quest cqu...@openstreetmap.fr a écrit :

 Pour la SNCF, il y a des relations route=train pour décrire les trains
 qui circulent sur les route=railway qui sont les infrastructures des
 lignes elles même. Les premiers sont liés à la SNCF, les seconds en
 réalité à RFF.

C'est pertinent.
Ici les route=railway sont donc nos circuits. Les ways qui en sont membres
sont donc soit les voies physiques, soit les files de pylônes.



 François, ton TOC* est déjà identifié: les pylônes électrique car dans
 ces relations, il n'y a pas de pylônes... certaines lignes
 ferroviaires n'étant toujours pas électrifiées ;)

Ah oui un TOC :)

C'est surtout que je cherche à avoir une vue topologique du réseau. Mon
réflexe était de représenter chaque circuit (ou chaque sens des voies
ferrées doubles par exemple) mais c'est pas la manière la plus économique
en temps et en taille de données.

Je comprends un peu mieux maintenant. Les relations donnent la topologie,
les ways le côté purement géographique et on a rarement besoin des deux en
même temps.



  Une habitude qui vient des routes, l'une passe forcément sur l'autre
 et layer permet d'indiquer qui est dessus, qui est dessous ce qui
 n'est pas forcément sans intérêt, car dans la réalité c'est quand même
 bien comme ça.


D'accord oui en effet.

Une situation à laquelle j'ai été confronté hier soir en tentant de
représenter l'intérieur d'un poste 400 kV RTE : les lignes arrivent sur des
portiques puis chaque phase est raccordé sur le jeu de barre correspondant.
http://wiki.openstreetmap.org/wiki/Power_lines#inside_power_stations

Pour raccorder chaque ligne aux jeux de barres, je suis tenté d'utiliser
une way power=cable entre le portique power=tower et le jeu de barre
(way) power=busbar
Le câble supporte une phase alors que le power=line en supporte n, selon
le régime régional considéré.
= Le tag cables=X sur les lignes haute-tension me semble superflu
puisqu'on a systématiquement les mêmes configuration suivant le régime
choisi.

Ici le câble est bien connecté à une ligne sans pour autant qu'on se
préoccupe du layer mais je n'ai peut-être pas considéré les bonnes
hypothèses.

Selon ces mêmes hypothèses, je trouve qu'utiliser un power=line +
layer=XX dans le cas d'une ligne multi-phase est sémantiquement mieux
qu'utiliser un power=cable qui reste trop éloigné de la vraie nature de
l'équipement représenté.

Pour rester sur le même thème, je pense être dans le vrai pour dire que ces
câbles de phase connectés entre les portiques et les jeux de barres doivent
faire partie des relations représentant les circuits avec role=Lx pour
indiquer le numéro de phase (normalement déductible visuellement sur les
transformateurs puis en remontant le jeu de barre).


-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Données historique et historiques des données...

Bonjour,

Je suis plutôt pour conserver un historique en effet.

Par contre non pas l’implanter dans les tags, il est possible d'utiliser
les versions.
Ces dernières ont déjà une dimension temporelle, plus temporelle que les
tags par exemple.

Le problème est qu'on ne sait pour l'instant pas si le passage d'une
version à l'autre reflète une modification de la carte uniquement ou une
édition suite à une modification du terrain.

Ca demande forcément quelques modifications de l'API et on peut facilement
préciser dans une requête qu'on ne veut que des données contemporaines et
pas du passé.

C'est d'ailleurs étonnant que ca ne fasse pas partie des motivations de
l'utilisation d'une base versionnée...

2013/1/3 Christian Quest cqu...@openstreetmap.fr

 Au moins l'avantage avec des données anciennes, c'est qu'elles sont
 stables ;)

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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




-- 
*François Lacombe*
*Apprenti Ingénieur Télécom Bretagne*

francois dot lacombe At telecom-bretagne dot eu
+33 6 73 41 92 99

http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Le fait que ça n'ai pas été intégré dès le départ va forcément motiver pas
mal de modifications. Profitons-en.

Les versions correspondent peut-être à diverses modifications qui ne relève
pas d'un changement terrain, mais lorsqu'il y a changement terrain, il y a
une nouvelle version OSM et c'est ce qui compte.
Pour l'avoir déjà testé, un fonctionnement à 4 dates permet :
- de dater la version elle-même
- de dater l'objet qu'elle représente de manière différente (ces dates
peuvent ne pas évoluer d'une version à l'autre).

Utiliser les tags, même avec un suffixe, va compliquer les choses si on
veut des enregistrements sans les données historisées.
Les tags ne sont pas les seuls à être modifiés, les coordonnées d'un node
(par exemple) le peuvent également d’où l'impérieuse nécessité :) de placer
l'historisation au niveau de l'enregistrement (sa version).
Les tags restent un tableau à 2 dimensions, c'est peu évolutif comme
concept, la version l'est beaucoup plus.

Pour le soucis des liaisons, ça ne sera pas simple dans tous les cas.
- Si on utilise un identifiant invariant suivant la version (comme c'est le
cas sur OSM), l'intégrité n'est pas préservée.
- Si on utilise un identifiant unique par couple objet/version, chaque mise
à jour d'objet va être un casse-tête pour le répliquer dans les références
qui le pointent.

Je crois que c'est un thème abordé sur le Wiki de débat sur l'API 0.7 par
ailleurs.

Le 4 janvier 2013 15:38, Christian Quest cqu...@openstreetmap.fr a écrit :

 C'est l'utilisation de tags standards qui crée la confusion.

 Ajouter un tag (comme historic=yes) ne résoudra le problème que pour
 les outils tenant compte de celui-ci, ce n'est donc pas une bonne
 solution à mon avis.

 Le principe du suffixe aux tags ne vous semble pas intéressant à creuser ?

 Rappel:  name[:1970]=Place de l'Etoile

 - pas de risque de confusion
 - possibilité d'en avoir plusieurs car des changements il peut y en
 avoir eu plus d'un !

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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




-- 
*François Lacombe*
*Apprenti Ingénieur Télécom Bretagne*

francois dot lacombe At telecom-bretagne dot eu
+33 6 73 41 92 99

http://www.infos-reseaux.com
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Données historique et historiques des données...

Ce formalisme serait-il requêtable en xquery ou même en SQL?

Le 4 janvier 2013 17:11, Christian Quest cqu...@openstreetmap.fr a écrit :

 Le 4 janvier 2013 17:02, Vincent Pottier vpott...@gmail.com a écrit :
  Un exemple (suivant ISO 8601 pour la notation des dates et intervalles)
 pour
  un POI :
  shop:[1985/1999-07]=florist
  name:[1985/1999-07]=Mille Fleurs
  shop:[1999-08/2005-02-21]=butcher
  name:[1999-08/2005-02-21]=L'entrecôte
  shop=electronics
  name=Fréquences
  On voit trois états successifs du magasin. L'état actuel est supposé être
  celui par défaut, ne comprenant pas de date de validité.
 
  Pour une ancienne commune, sur une relation :
  boundary:[/2011]=administrative
  name:[/2011]=Trifouilly-les-Oies
  ...
  Dans l'état actuel, les valeurs ne sont plus valides
 

 Je ne connaissais pas la notation des intervalle ISO, ça me semble
 plus propre comme ça.

 tag:[intervalleISO]


  Cette formule reste compatible avec l'existant. Les outils lambda
  n'utiliseront pas les tags *:[*]
  La limite, c'est les collisions du genre :
  shop:[1985/1999-07]=florist
  amenity=pub
  En 1990, c'était déjà un bar ?
 

 C'est pas parfait, mais c'est mieux que rien ;)


  L'autre limite, c'est, dans le premier exemple, en 1980, la boutique
 était
  electronics, la valeur par défaut ?
 

 Dans ce cas j'aurai ajouté un shop:[/1985]=electronics

 On devrait considérer que par défaut tag=xxx est équivalent à tag[plus
 grande date/]=xxx


  Bon. JOSM trouvera vite un plugin et un validateur pour gérer cette
 couche
  temporelle, genre openning_hours, mais je redoute que certains
 éditeurs,
  que je ne nommerai pas, aient du mal.

 Tant que ça ne leur pose pas de problème, ils les ignorent un point c'est
 tout.

 --
 Christian Quest - OpenStreetMap France - http://openstreetmap.fr/u/cquest

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




-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Données historique et historiques des données...

 traduire directement cet intervalle de dates
 en deux attributs donnant des dates précises si cela facilite les
 requêtes SQL : start_date=1890-02-21..1892-03-07 et
 start_date=1888..1892 pour les deux cas précédents.

 Les incertitudes de dates peuvent exister pour la date de début comme
 pour la date de fin de validité (les 4 dates sont alors en ordre
 croissant ; la paire à utiliser pour les tests de référence sont de
 prendre le plus plus grand intervalle des dates 1 et 4 pour l'objet
 référencé, et le plus petit intervalle des dates 2 et 3 pour l'objet
 référent).

 Certes cela duplique les objets et les attributs, mais il est plus
 simple de gérer l'intégrité référentielle au niveau de chaque objet
 ayant un ID unique qu'avec un seul objet avec des attributs dont les
 valeurs sont datés et deviennent des listes de valeurs. Mais des
 solutions peuvent être développées pour les éditeurs qui veulent
 vouloir pouvoir saisir un même objet avec des attributs (et membres de
 relation) datés individuellement. Il est même possible de lier ces
 objets à un objet maître liant les ID d'objets entre eux dans une
 liste odonnée par date avec une relation spéciale de type history
 comme une relation normale, sauf que les relations elles-mêmes ou
 autres objets ne sont pas modifiés, il n'y a que la nouvelle relations
 spéciale qui au lieu de contenir des listes d'objets quelconque
 contient une liste d'ID d'objets avec chacun leurs intervalles de date
 de validité au lieu du rôle (cette relation spéciale appliquant des
 contraintes : les intervalles ne doivent avoir aucune intersection
 hors des intervalles de tolérance).

 Bref aucune modification du schéma des objets actuels : noeuds,
 chemins et relations, mais l'ajout d'une primitive history
 permettant de lier un objet à ses dates de validité et ses versions
 successives dans des ID différents. L'intégrité référencielle reste
 conservée par les IDs comme actuellement, et il devient possible alors
 de ne pas tout charger et travailler sur une date précise (par défaut
 aujourd'hui, ou de demander à charger les autres dates et d'avoir
 dfférentes vues successives d'un objet qui a changé d'état.

 Maintenant si on commence à historiser les attributs ou membres d'une
 relation ou nœuds membres d'un chemin, on va se retrouver à modifier
 toutes les 3 primitives et là ça risque d'être compliqué et risqué à
 gérer car on aura des listes de valeurs pour chaque attribut ou
 membre/rôle d'une relation, ainsi que chaque nœud d'un chemin (c'est
 surtout là que le modèle va exploser, d'autant plus que ces noeuds
 forment déjà une liste ordonnée et connectée qui ajoute d'autres
 contraintes pour la validité géométrique).

 La solution avec des tags supplémentaires ajoutés aux objets me semble
 aussi plus fragile qu'une solution utilisant une primitive
 relationelle nouvelle liant les objets datés entre eux (et n'offira
 pas une bonne compatibilité avec les éditeurs et entrainera des
 confusions dans les données, sauf si le moteur assure que ces tags de
 date sont bien réservés à cet usage, et sont stockés en interne dans
 des primitives cachées, grace à une convention de nommage réservées au
 tags internes spéciaux de même nature que le tag du type d'objet
 node/way/relation ou du tag de l'id, renforcée par un test de
 cohérence côté serveur et une indexation spéciale à part).

 2013/1/4 Pieren pier...@gmail.com:
  Tout ce que vous suggérez (et plus encore) est présenté dans ce
  slideshare montré au SOTM de ... 2009:
  http://www.slideshare.net/frankieroberto/mapp-history-on-open-street-map

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




-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Données historique et historiques des données...

 : il peut y avoir des noeuds communs
 entre deux versions d'un chemin, ou bien tous les noeuds différents,
 ou tous identiques, les chemins ne différent que par les attributs
 voire sans aucune autre différence que les dates de validité (par
 exemple quand deux anciens chemin pour une zone ont été fusionnés puis
 rescindés à nouveau, ou quand une ligne de transport est aménagée
 pendant un certain temps différemment, puis restaurée à son ancien
 état, ou quand deux communes fusionnent pendant un certain temps puis
 se reséparent, la commune ayant cessé d'exister de façon autonome
 pendant une période donnée ; cependant je pense qu'il sera rare que la
 restauration soit totalement à l'identique, sauf si la version
 intermédiaire n'était que temporaire pour durer que quelques mois ou
 moins de 2 ou 3 ans ; mais là tout est possible, et il est probable
 que l'ancienne version ne corresponde pas exactement à ce qu(on trouve
 à l'heure actuelle et que celle-ci de toute façon conservera un ID
 séparé demandant des corrections et contributions distinctes à ne pas
 apporter à la version actuelle).

 Il est aussi très probable que les anciennes versions n'aient pas le
 niveau de précision géométrique des versions actuelles : la Terre
 bouge, les rivières bougent, les terrains bougent, il y a des
 inondations, des glissements de terrain, des arrangements légaux pour
 certaines parties, des échanges de parcelles qui ne feront pas l'objet
 de retour en arrière.

 Le 4 janvier 2013 20:55, François Lacombe
 francois.laco...@telecom-bretagne.eu a écrit :
  Même après avoir lu les slides, m'est avis qu'il vaut mieux gérer ça au
  niveau de la primitive plutôt que ses tags...
  Le tags sont des données particulières de la primitive, gérer un
 historique
  à ce niveau c'est se condamner à devoir le refaire pour toute autre
 donnée
  rattachée à l'objet.
 
  Qu'on appelle ça une version ou autre chose, c'est nettement plus
 navigable
  et manipulable que d'avoir à parser des chaines de texte pour faire une
  sélection.
  La version a le mérite de relier logiquement plusieurs historiques du
 même
  objet sans avoir à créer une liaison history justement.
  Dans ce cas on aurait un entier supplémentaire au lieu d'une table avec
  plusieurs entiers nécessaires.
 
  Ce qui m'interpelle aussi, c'est que la problématique du nombre
  gigantesque d'enregistrements que cela va entrainer ressorte alors que
  moult versions obsolètes (tant sur le terrain que pour d'éventuels
 reverts)
  sont conservées par ailleurs.
  D'expérience je créé des vues restreintes sur les enregistrements
 actuels
  (plus peut-être à d'autres points de temps fortement fréquentés) pour
  obtenir non seulement une vision actuelle et un accès direct aux
  historiques.
 
  Concernant les liaisons entre primitives, une référence aux objets
 logiques
  (dont le numéro ne change jamais au cours du temps) consolidées par les
  dates de part  d'autre pour connaitre la bonne version à utiliser
  fonctionnerait.
  Ceci à condition de restreindre la conservation d'un objet à sa stricte
  existence... on revient à la question philosophique des slides.




-- 
*François Lacombe*

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

Re: [OSM-talk-fr] Données historique et historiques des données...