Re: [OSM-talk-be] Du côté de la France...

[André Pirard]

On 04/01/2021 10.10, Lionel Giard wrote:

André,

Just to clarify : the article is speaking of the *"french IGN" *here, 
not the belgian counterpart. AFAIK, the license in Belgium doesn't 
change and it is still closed data that we can't use at all. And as 
regional data is open in all regions (normal PICC too is usable as we 
started to look for missing roads using it), i don't see much use 
anyway - except for some niche cases where it would be relevant. :p

You're right.
It's just like the French jurists or other people who don't realize that 
they speak worldwide and that they must say that they speak of the 
French law or other things.
We may answer the request "Signaler une erreur dans le texte 
<https://www.numerama.com/tech/679565-ca-y-est-les-donnees-publiques-de-lign-sont-libres-et-gratuites.html?&show_reader_reports>" 
to say that it must be read several times to notice "le relief français".


All the best,

André.



Best regards,
Lionel

Le dim. 3 janv. 2021 à 22:53, André Pirard <mailto:a.pirard.pa...@gmail.com>> a écrit :


On 03/01/2021 15.27, François Piette wrote:


Interesting !

Do you know if there is (or will be) a tile server?

--

francois.pie...@overbyte.be <mailto:francois.pie...@overbyte.be>

The author of the freeware multi-tier middleware MidWare

The author of the freeware Internet Component Suite (ICS)

http://www.overbyte.be

*De :*Matthieu  <mailto:matth...@gaillet.be>
*Envoyé :* dimanche 3 janvier 2021 14:00
*À :* OpenStreetMap Belgium 
<mailto:talk-be@openstreetmap.org>
*Objet :* [OSM-talk-be] Du côté de la France...

All IGN maps goes open data.


https://www.numerama.com/tech/679565-ca-y-est-les-donnees-publiques-de-lign-sont-libres-et-gratuites.html?fbclid=IwAR1bn3lr3vBcl5Ty5CXxzJu81AfZ5b2BRqnM9wRpD25Ee0nU2LkFQlvH568



Great!
I hope someone will add the servers to the JOSM free servers list.
Because I won't start again a new fight to prove the obvious
permission like I did for the PICC and for the cadastre.

The JOSM configuration for their Cartoweb (OVERLAY) is

  * WMS:
https://wms.ngi.be/cartoweb/service?request=GetCapabilities&service=WMS
  * WMTS: https://www.ngi.be/cartoweb/1.0.0/WMTSCapabilities.xml

Anything against WMS/WMTS François?

Envoyé de mon immobile Thunderbird, et sans virus non plus grâce à
seulement Ubuntu,

All the best,

André.


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


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


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

Re: [OSM-talk-be] Du côté de la France...

[André Pirard]

On 03/01/2021 15.27, François Piette wrote:


Interesting !

Do you know if there is (or will be) a tile server?

--

francois.pie...@overbyte.be 

The author of the freeware multi-tier middleware MidWare

The author of the freeware Internet Component Suite (ICS)

http://www.overbyte.be

*De :*Matthieu 
*Envoyé :* dimanche 3 janvier 2021 14:00
*À :* OpenStreetMap Belgium 
*Objet :* [OSM-talk-be] Du côté de la France...

All IGN maps goes open data.

https://www.numerama.com/tech/679565-ca-y-est-les-donnees-publiques-de-lign-sont-libres-et-gratuites.html?fbclid=IwAR1bn3lr3vBcl5Ty5CXxzJu81AfZ5b2BRqnM9wRpD25Ee0nU2LkFQlvH568



Great!
I hope someone will add the servers to the JOSM free servers list.
Because I won't start again a new fight to prove the obvious permission 
like I did for the PICC and for the cadastre.


The JOSM configuration for their Cartoweb (OVERLAY) is

 * WMS:
   https://wms.ngi.be/cartoweb/service?request=GetCapabilities&service=WMS
 * WMTS: https://www.ngi.be/cartoweb/1.0.0/WMTSCapabilities.xml

Anything against WMS/WMTS François?

Envoyé de mon immobile Thunderbird, et sans virus non plus grâce à 
seulement Ubuntu,


All the best,

André.


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

Re: [OSM-talk-be] How owing to FlightRadar24 to follow the Tour de France on a less straight route

[André Pirard]

On 12/07/2019 18.55, André Pirard wrote:


Comment avec FlightRadar24 suivre les avions plutôt que les vélos du 
Tour de France. 
<https://www.flightradar24.com/blog/how-the-tour-de-france-goes-from-cycle-to-screen/?utm_campaign=website&utm_source=sendgrid.com&utm_medium=email>


How owing to FlightRadar24 <https://www.flightradar24.com/> to follow 
the Tour de France on a route 
<https://www.flightradar24.com/blog/how-the-tour-de-france-goes-from-cycle-to-screen/?utm_campaign=website&utm_source=sendgrid.com&utm_medium=email> 
less straight than that of the bikes and than OSM's.
You may right click the video and select "iframe in a new tab" for a 
larger view.


You should probably be able to use Flightradar24 
<https://www.flightradar24.com/> and see the planes live if you manage 
to point it where they are 
<https://www.velowire.com/article/1043/fr/le-parcours-du-tour-de-france-2018-sur-google-maps-google-earth--itineraires-horaires-et-profils-des-etapes.html>.


Please forward this to other lists.

This will be my last message about this.
On this 2019-07-15 at around 17:00, I turned FlightRadar24.com 
<https://www.flightradar24.com/44.56,3.51/8> on to show the route of the 
10th stage of the Tour de France: Saint-Flour -> Albi 
<https://www.letour.fr/fr/etape-10>.
I clicked a few planes along the route until I pinned one that FR24 
labels with a made-up name BE20. It circled in rounds all along he 
track, probably to relay TV signals. You will probably be able to watch 
it during the next stages. (⚠ Tuesday 16 is resting day). Unfortunately, 
albeit F24 archives the history of most flights for replay, it does not 
archive this plane, like e.g. most gliders.
Then I waited until BE20 went nanight in Castres Mazamet Airport 
<https://www.flightradar24.com/airport/dcm> to take this picture.

Beware that the pasted over data is that when the plane was above Albi.
In Castres it was less high and going down. And it had a more decided 
speed ;-)


I thought that this could add loving to watch planes to your loving to 
map the land under.
For example, replay the history of this service plane 
<https://www.flightradar24.com/data/aircraft/oo-let/> and wonder why it 
goes to those places all over the world to fly in circles. Similar trips 
for this helicopter 
<https://www.flightradar24.com/data/aircraft/f-gkmb#21364fc1> that I 
found in Albi, Lyon, Brussels near the Tour de France.




All the best,
Cordialement,
Amitiés,

*𓄿* 
*𓈖* *𓂋*
*𓂧* *𓂝*







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

[OSM-talk-be] How owing to FlightRadar24 to follow the Tour de France on a less straight route

[André Pirard]

  
  

Comment
  avec FlightRadar24 suivre les avions plutôt que les vélos du Tour
  de France.

How owing to FlightRadar24 to follow
  the Tour de France on a route less straight than that of the
bikes and than OSM's.
You may right click the video and select "iframe in a new tab" for a
larger view.

You should probably be able to use Flightradar24 and see
the planes live if
  you manage to point it where they are.

Please forward this to other lists.

All the best,



  

  André.

  


  


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

Re: [OSM-talk-be] arlon - osm - training courses: JOSM and PICC

[André Pirard]

  
  


  
On Tue, Nov 27, 2018 at 10:40 PM Pierre
  Parmentier 
  wrote:


  

  Hello,
  
  
  The two
planned training sessions on the contribution to OSM
took place at EPN (Espace public numérique) in Arlon on
6 and 27 November 2018 from 9.00 to 16.00 h.

A dozen people attended each of them. They came from
very different horizons, from places in the province
sometimes far from Arlon, and included members of the
Sentiers de Grande Randonnée ASBL as well as officials
of a tourism organization in the area.

We approached the edition with JOSM mainly. The various
menus and some plugins were examined. Participants
created an account and some nodes and ways were added to
OSM. The GPX file creation with Graphhopper and overpass
turbo and their import into uMap were also shown.

Some participants have already set to work on their
side, mainly in the localities of Aubange and Athus, in
the province of Luxembourg.

But the others, perhaps more shy, were interested in
consolidating their knowledge and it was agreed with the
EPN Arlon that a monthly OSM workshop would take place
from January 2019.

I hope this will help OSM grow in this part of the
country.
  
  
  Pierre
Parmentier
  

  

  

That's great news, Pierre.
Nice to hear news from the nearby province (I mapped the Luxembourg
boundaries and in Wallonia with 2 Belgian friends and a Frenchman).
I especially appreciate your basing of your tutorials on JOSM and I
hope you mention PICC because:

  JOSM is the recognized best editor (most serious)
  it's extremely powerful: did you show the AreaSelector plugin
that, by clicking on the PICC layer, can map a whole streetful
of houses at the rate of 1 house per 5-10 sec, complete with
street name etc. and incrementing number, at a 20 cm precision?
  when I am mapping that way, I'm spending much time correcting
the mapping made with other editors with an imprecision of 2-5 m
and often more: when I meet precise tagging I know it was done
with JOSM+PICC and that most often checks to be true
  
  JOSM is less intuitive than other editors indeed (c) but it's
not very hard to learn it after all. The problem is that someone
who has been accustomed to another editor may prefer to spend
time mapping rather than to learn JOSM. Some of my friends are
really convinced of the superiority of JOSM but just can't make
the step. To them, my best advice is to start using JOSM little
by little, using two editors at the same time and finally
settling on JOSM (that's what I did with Merkaartor but I
concluded that JOSM is better).
  
  JOSM is a totally different concept than Web based solutions
that (generally) expose the user to the "an expected error
occurred" message, "please do it again" (all that was done
forgotten). JOSM loads parts of the OSM data on the PC, modifies
a part of it and then writes what it has modified back to the
OSM database. This means that:
  
the data that JOSM loaded, or part of it, can be recorded in
  a *.osm file on the PC (before being "written back" to OSM)

if the work to do was too much for one day, that *.osm file
  can be reloaded and the work continued after a good night
  sleep

if the user is stuck, the *.osm file can even be send to a
  friend to be continued
the *.osm file can be edited as a text file to do very
  subtle modifications
those kind of things are not obvious indeed but many friends
  are around: I once helped to salvage a shrimp pond dikes: his
  mapping had been vandalized (erased); He could not do a
  "revert", I did it for him and sent him the *.osm file that
  would have restored his mapping. But some nodes were moved "ad
  infinity" and JOSM would crash when trying to move them. So I
  edited the *.osm file to move them to a noticeable location so
  that he could move them to the right place. And he succeeded
  the revert and was so glad.

should JOSM crash, which is very rare, it will offer to
  continue a saved check

Re: [OSM-talk-be] [Tagging] Quick Building tracing question... -> Area Selector JOSM plugin

[André Pirard]

On 2019-01-10 03:42, John Willis wrote:
I am tracing and repairing existing traces of warehouses in an 
industrial district.

On a slightly different but similar subject.
To do serious fast building tracing, one should use JOSM with Area 
Selector Plugin  and an 
orthorectified map such as PICC in geoportail.wallonie.be or 
basemap.at.  That goes, complete with auto-incrementing street number 
tagging, at the rate of one house per 5-10 sec, but needs occasional 
touch up with Improve Way Accuracy tool.
While doing that I also make lots of corrections to traces by other OSM 
editors with a 2, 5 m or more precision error.
This is partly because they trace roofs from aerial maps, which are not 
at ground location because the camera view and walls are slanted. But 
also the roads are affected by imprecision.
Orthorectification does an incredible job of putting that right, 
impossible to do by hand. It computes the slant angle in one place, uses 
it in another, uses shades on the ground etc. I've seen it detect in 
meadows banks (slopes) that were strictly invisible to the eye.

This raises a problem.
When meeting untagged buildings that have been coarsely traced 5-10 m 
away from their position, should they simply be erased and replaced in 5 
secs or should 20+ sec instead of 5 be spent for conflation?
I asked Paul to add conflation 
. He did it, but with no 
tag merging.
I suggested that Area Selector simply invoked Replace Geometry instead 
.
If you feel that conflation is important, please visit these pages and 
back these requests.
Many of the warehouses have large (3-6m) roofs over the loading dock 
gates, making the building appear bigger.


here is an example.
https://www.openstreetmap.org/way/494766956

if I am mapping this kind of warehouses, which should I:

- map the whole structure as a warehouse

- map on the building portion as a warehouse (as I have done)

- map the building as a warehouse and map an attached polygon as the 
roof (which I haven’t done yet).


I am going to spend the time cleaning up UltimaSnorlax’s bad polygons, 
I might a well draw them correctly the first time.


Javbw



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

Re: [OSM-talk-be] [Tagging] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[André Pirard]

  
  
On 2018-11-18 19:05, Kevin Kenny wrote:


  

  
On Sun, Nov 18, 2018 at 11:16 AM André Pirard
  <a.pirard.pa...@gmail.com>
  wrote:


  
Jakka's
  point is not that "url" is used but that it could be
  wanted and that this usage would prevent it.

To prevent the "first jumping on it owns it" practice,
the good move would be to consider that anything:url is
officially an URL.
"being officially" meaning principally that listings
make it a clickable link.
Even though any URL can be recognized inside any text
and made clickable.
But I've had problems suggesting to make multiple tags
containing URLs clickable.
The answer was: "the URL tag exists already" ;-)



For whatever it's worth (probably not much), when I
  imported the New York City DEP recreation lands data, most
  of the facilities had multiple URL's - the main URL for
  the facility, the URL for the facility's official map, the
  URL for the site where permits can be obtained (if permits
  are required)...


At the time, JOSM warned me about 'url' and proffered
  'website' in its place, so I went with that in place of
  'url'. For the secondary sites (map, permit service, ...)
  I used 'website:map', 'website:permit', etc.  The tools
  appear to recognize it - at least when I call up a place
  like https://www.openstreetmap.org/relation/6304825,
  the URL's render appropriately as links. I may have got it
  all wrong, but nobody corrected me on talk-us or imports
  at the time.
  

  

In strict parlance, an URL refers to any resource and its name is
self-describing its type (with a scheme), e.g. mailto:me@there.
(if you click on mailto: the software may open a new e-mail message,
and on tel: it may dial a number, there are no coffee: nor tea:)
So, it's a matter of knowing if we want to reopen this discussion
for a new key for each scheme or do it all with url="">
A web site is a collection of web pages.
In any case, it is map:website, the website that is an attribute of
the map and not website:map which is the map of the website.
Just like the door:key is the key of the door and not the door of
the key.
Most general concept comes first and its parts or attributes come
last.

All the best,



  

  André.

  




  


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

Re: [OSM-talk-be] identifier in ref:xOperatorx=y0yyyy to url=http://mijnlijn.be/y0yyyy

[André Pirard]

  
  
On 2018-11-18 13:47, Jo wrote:


  Frank,


url wasn't used yet on the bus stops, so no conflict there.
  

Jakka's point is not that "url" is used but that it could be wanted
and that this usage would prevent it.
To prevent the "first jumping on it owns it" practice, the good move
would be to consider that anything:url is officially an URL.
"being officially" meaning principally that listings make it a
clickable link.
Even though any URL can be recognized inside any text and made
clickable.
But I've had problems suggesting to make multiple tags containing
URLs clickable.
The answer was: "the URL tag exists already" ;-)

All the best,



  

  André.

  



  
Pieter, good to hear De Lijn plans such deep links. I think
  it will be good to have them on our route_master relations.
  The route relations are for the longest variations in
  itinerary, not sure if they fit there.


For the stops, I tend to like the mijnlijn.be/
  form, as that is the information printed on each of the paper
  schedules on the stops. So if De Lijn is not planning to
  abolish those in the medium term, I'd prefer to use them. I'll
  hold off with preparing the data and launching the Project of
  the Month though.


Pieter, is De Lijn planning to introduce uic identifiers we
  could put in uic_ref?


We don't have anything that corresponds to the zones in
  OSM. I'm curious to find out what will be behind those urls. I
  painstakinglly added the zone information on the stops, but
  now that a ticket has a time limitation instead of a zone
  dependent one, they became less relevant.


Marc, we can leave the ref:De_Lijn tags. I'm not strongly
  against keeping them, but I doubt anyone uses them (except me
  in my integraton scripts). If anyone wants to use them, it's
  trivial to extract the identifiers from the url tag values.


There is another tag I'd like to introduce. While reviewing
  the import of bus stops around Finland, they added a direction
  tag.


My first reflex was to remove it after reviewing the stop,
  but now I start to see value in knowing in which direction the
  bus will leave. I plan to add functionality to PT_Assistant to
  calculate it automatically based on the segment of the way the
  stop is adjacent to. And in a second stage a validator rule
  that checks whether the stop is (still) on the correct side of
  the road (right or left, depending on the side of the road
  vehicles drive on)


Polyglot






 
  
  
  
El dom., 18 nov. 2018 a las 11:19, Pieter
  Colpaert ()
  escribió:

Hi Polyglot,
  
  We are in a Linked Data project with De Lijn and we’re going
  to have 
  official persistent identifiers (HTTP URIs) soon for stops
  (but also for 
  things like the routes and zones). It might be interesting to
  integrate 
  these in OSM rather than the mijnlijn.be
  one?
  
   From the moment we have an official URI strategy, I will get
  back to 
  this list in each case.
  
  Kind regards,
  
  Pieter
  
  On 18/11/18 11:10, Jakka wrote:
  > Using key as "url=""http://mijnlijn.be/303079"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://mijnlijn.be/303079   
  (<- you can test this, the url is
  >> expanded/translated to a url on www.delijn.be )
  >>
  >> For the conversion, I'd like to launch a Belgian
  "Project of the month",
  >> so the position of the stops can be verified once
  more by locals, but
  >> also shelters and bus_bays can be added and if cycle
  ways split off to
  >> go around those bus bays, that detail can be added as
  well.
  >>
  >> I know that that is what we have been doing for the
  past 5+ years, but
  >> now it would get some more dedicated focus.
  >>
  >> For several years I thought having the identifier n a
  dedicated ref:X
  >> tag and then telling everyone about how to turn it
  into such a url was
  >> the way to go,. That doesn't actually work though.
  Nobody knows how to
  >> get from the identifer to the url. Giving 

Re: [OSM-talk-be] [Tagging] cadastral plan now open data

[André Pirard]

On 2018-09-21 23:22, Martin Koppenhoefer wrote:


sent from a phone

On 21. Sep 2018, at 21:32, André Pirard <mailto:a.pirard.pa...@gmail.com>> wrote:



The whole cadastral map is offset by that 7m.
...

*Picture 3:* So, I dragged his parcel right onto the wall.
And now it's correctly located, aligned with the fencing all around.



how did you know which source was off, the cadastral map or the 
orthophoto?

The ortophoto is guaranteed with a 20 cm precision all over Wallonia.
On the other hand, all aerial photos cannot be off by the same 7m could 
they?
On the first foot, juxtaposing precisely measured parcels produces huge 
errors that vary all over a village.

I just can't figure.
I did not check if this occurs at gaps when crossing roads or what.
I'm not working for the Cadastre. I pay them ;-)

In Beijing, it was Google Maps that moved.
Satellites (several if I recall) were showing OSM in the right place.

All the best,

André.



...

The Belgian cadastre is not the only one with an error shift.
With JOSM, I have similarly proved that Google Map has a 120m NE 
shift in Beijing.

Nobody noticed it.



it is well known that the chinese government requires all imagery and 
map providers to use chinese algorithms which distort the map 
coordinates systematically, in a way that they remain usable as long 
as your navigation system uses the same algorithms.


Ciao, Martin


___
Tagging mailing list
tagg...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging


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

Re: [OSM-talk-be] cadastral plan now open data

[André Pirard]

  
  
On 2018-09-21 13:33, Lionel Giard
  wrote:


  
I'm not supporting the addition of this WMS
  neither, as it is more imprecise than others sources for most
  of the data. So the question about the license is not really
  important in that case. The regional sources for buildings,
  parcels, streets,... are almost always with a better
  precision. 

  

What you're not supporting is using that WMS I suppose but
you don't say exactly for what.
The text I prepare also very highly discourages roughly using what
is bearing Cadastre coordinates, but encourages such things as
discovering finding missing house numbers or locality names.
So, regarding "the addition", my opinion is "yes" as long as the
user is informed of the above.
But, unfortunately, [J]OSM did not think of displaying such usage
notes to the user discovering JOSM, installing it, fumbling and GO.

The pity is that this downloadable Opendata is made of local files
that are very inconvenient to use with an editor like JOSM.
Please, keep the WMS going !!!
It would be much better if shapes were on a server similar to WMS
but vector.
And in fact, an idea would be to put it in a second OSM2 server.
The shape data would be converted to OSM2, as imprecise as it may
be, but maybe with heuristic tags.
Then the user would evaluate if the position is correct, copy
OSM2->OSM and shift it to the right location.
The Cadastre polygons usually have a good shape (thanks goodness)
but are often in the wrong location.
That is just a last resort alternative way of doing.
Using AreaSelect to map houses including numbers is more
straightforward and preferred for buildings.

In fact, I strongly suggested that any OSM editor displayed
the terms in the server metadata the first time the server is used,
whenever they change and periodically. JOSM strongly refuses to do
that.
They refuse to display that a server strongly forbids using
its data and they act as if that they could be able to list all of
the allowed servers of the 89291 ones.
And the very partial JOSM database should be repeated for every OSM
editor.
Think of Merkaartor. They've had a configuration for PICC from the
start.
Users start Merkaartor and they see PICC without warning. Maybe they
think they launched a jigsaw puzzle game !!!
And no vigilante ever complained.  And [J]OSM says it's the way of
doing.
Not very logical to me who was accused of what I never did !!!

  
One important thing that the cadastre give, is
  the administrative boundary as it is the authorithy on this
  subject (to keep the cohesion with parcels and administrative
  boundaries) as explained here https://data.gov.be/fr/dataset/b47f2ffd-ebc9-413c-903f-d83af520fcdb
  (you can choose the language at the top left of the page) :
"The General Administration of Patrimonial
Documentation of the FPS Finances was designated by the
other institutes as being the authentic source for this
database and manages it as such" -> this is the layer
  "B_CaPa" in the downloadable data. So this would be the useful
  part of the cadastre, But i don't think we need the wms for
  that, if we want to improve the administrative boundary, we
  can just download the layer and use it as a base, to
  re-position the boundaries.
  

I'm speaking of boundaries in my document too :-(
And especially of the once sought old municipalities.
They have traditionally been different from other sources.
But if they're official...
The characteristic I've noticed is that they avoid crossing parcels.
So, watch who's selling their estates to keep them moving ;-)
It's very convenient to display a WMS layer displaying only
boundaries.

All the best,



  

  André.

  



  
Le ven. 21 sept. 2018 à 12:49, joost schouppe
   a
  écrit :


  
Hi,
  
André asked to include the WMS of this service by
  default in the JOSM repository. A long conversation
  ensued. Some of the confusion is caused by the fact
  that the WMS probably contains outdated license info.
  I have now asked the FOD Finances for a second time to
  clarify this. The ticket was closed, which is probably
  a good thing, as it is probably not a good idea to
  show this data by default in JOSM anyway!
  
  
  
  But even for the license of the downloadable files
 

Re: [OSM-talk-be] cadastral plan now open data

[André Pirard]

On 2018-09-21 12:46, joost schouppe wrote:
Op vr 24 aug. 2018 om 13:58 schreef joost schouppe 
mailto:joost.schou...@gmail.com>>:


Hi,

The cadastral plan is now open data for the entire country!

That's pretty big because:
- for Wallonia, it's the first open vector data with parcels,
buildings, roads and road names.
- contains "underground buildings" which were not available
anywhere AFAIK.
- there's a dataset with roads that have some kind of
"erfdienstbaarheid"/"servitude". This might be of use for certain
dubious paths

But of course, please note:
- there is way more data where this came from - the attributes of
the parcel are not included (like building levels, number of
units, landuse)
- Belgian cadastre data has a bad reputation in general so do not
trust everything you see. The building geometry seems to be quite
poor, especially when it comes to exact positioning, not so much
the shape itself.
- do not trust road name data (it doesn't follow the CRAB name, so
not official in Flanders). Names are often abbreviated
- the roads do not form a network, there are duplicate geometries
and some geometries are outdated by half a century
- there is pretty good metadata included. However, you might find
data that does not follow the explained model

The license file is included in any download. It seems to be
compatible with OSM, but it would be nice if more people give it a
good read. The first one to use it for mapping, does need to add
it to https://wiki.openstreetmap.org/wiki/Contributors

The data is in shapefile format (b!), but Philippe Duchesne
has made a download site where you can get it in geopackage
format. There is also a "view" link. To actually see the data
there, find the big switches to activate the layers you want to
see. The bigger ones take a while to load!

More details:
* Official website:

https://financien.belgium.be/nl/particulieren/woning/kadaster/kadastraal-plan

https://finances.belgium.be/fr/particuliers/habitation/revenu_cadastral/plan-cadastral

* Metadata:

https://financien.belgium.be/sites/default/files/20180626_Dataspecificaties.pdf

https://finances.belgium.be/sites/default/files/20180626_Specificationsdata.pdf

* Repackaged into an open data format:
http://data.highlatitud.es/cadaster-belgium/

We think this data will only be usable for validation efforts. If
you think an import could be useful for some of the data in some
places, do not forget to follow the Import Guidelines or risk
having your work reverted.

Happy mapping,
-- 
Joost Schouppe

OpenStreetMap
 | Twitter
 | LinkedIn
 | Meetup




--
Joost Schouppe
OpenStreetMap  | 
Twitter  | LinkedIn 
 | Meetup 




On 2018-09-21 12:46, joost schouppe wrote:

Hi,

André asked to include the WMS of this service by default in the JOSM 
repository. A long conversation ensued. Some of the confusion is 
caused by the fact that the WMS probably contains outdated license 
info. I have now asked the FOD Finances for a second time to clarify 
this. The ticket was closed, which is probably a good thing, as it is 
probably not a good idea to show this data by default in JOSM anyway!
Whether "shown by default" or not, that WMS exists, mappers can use it 
anyway, and it's *very useful **as a _complement_ to be used in parallel 
with JOSM+PICC* (or AGIV I suppose) and *only that*. "only" because I 
have *extremely important* remarks (complete with images) to make about 
the imprecision of that WMS or is it the whole cadastre.


I removed that cadastre JOSM default layer for two reasons.
To avoid mappers jumping on it and mapping (quite generously, pitifully) 
the same imprecise mess that we see now in Wallonia as the result of 
what was started with Potlatch and ID using various inappropriate 
sources instead of using JOSM+PICC/AGIV, which are now in charge of 
correcting those errors.
But before making those remarks, I have to see if that imprecision is of 
the 2018 shape data too or just of the 2017 WMS in which case it would 
be quite appropriate to ask the Finances to upgrade it.
So far, I've had problems browsing the shape data. It seems that it 
contains the same errors as the WMS but I want to be absolutely sure 
before speaking.

Second reason below...
But even for the license of the downloadable files the JOSM team 
seemed a bit worried: https://josm.openstreetmap.de/ticket/16693#comment:7
When I read the lic

Re: [OSM-talk-be] N30 relation fixed (was: National Road relation: does order matter?)

[André Pirard]

On 2018-09-03 21:59, Nathan Monfils wrote:

Op ma 3 sep. 2018 om 20:03 schreef André Pirard :
Op zo 2 sep. 2018 om 22:54 schreef Nathan Monfils 

Hello!

I was doing some editing on the N30 near Liège, when I noticed that its
relation was completely unordered, with ways near the city center being
next
to ways much further south (see relation `124374`).

The wiki defines a relation as an *ordered list*, yet only mentions order
for
bus lines. Is there a need for the road relations to be ordered
correctly?

Regards,

Nathan Monfils

On 2018-09-03 00:24, Jo wrote:

for route=road relations order doesn't matter much. It's impossible to
sort them according to any meaningful criterion.

Op ma 3 sep. 2018 om 20:03 schreef André Pirard :

A meaningful criterion to sort a route is so that two adjacent ways of it
share one same end node.
In other words, that the route is ordered the way you travel it without
interruptions.
That's what the "sort" buttons of JOSM do.
And, beside finding a segment more easily, the schema of the route made by
JOSM shows the gaps (missing pieces).
And in particular it will show if the road is circular.
For example, if you sort the N30, you will see a gap between Boulevard de
Fraipont and Avenue de la Libération.
And 16 other gaps in total.

Last time I spoke of routes with a Potlatch user, he told me he couldn't
sort routes.
I don't know about ID and that's quite a time ago.

The N30 should be sorted and corrected.
I will let Nathan do it if he's busy with it.

Amitiés,

André.

Polyglot


On Monday, September 3, 2018 8:09:28 PM CEST Jo wrote:

The "problem" with N roads is that they are not linear features, they
split, recombine, have dangling dead ends, roundabouts and so on.

Yes, you can group some of the elements, but the next time you sort, other
groups may be formed, so it's arbitrary.

Jo

I fixed the N30 relation the way I described.
I chose the order from Liège to Ardennes (holiday departures are happier 
than comeback ;-)).

That's the element order, down the list in JOSM relation editor.
Roundabouts are indicated by role "forward".
First way set to follow when traveling in route's direction.
Second way set to follow in the other direction.
JOSM shows them nicely with sidings like this



splits/recombines like Boulevard de Beaufraipont are normally like 
roundabout.


Basically, global sort doesn't change my roundabouts and splits.
But sort only sorts what is sortable and is only guaranteed as a local tool.
Hence, a global sort doesn't find a common northern node for the huge split
starting at Boulevard Raymond Pointcarré and ending in prongs.
And so it includes only one branch of it and it throws the other one to 
the end.


All the best,

André.



On 2018-09-03 21:59, Nathan Monfils wrote:

After looking into it further, I can only agree. I added the missing members
back (one way and a few junctions that were probably overlooked by previous
mappers), but every roundabout and double road "cuts off" the automatic
ordering by JOSM.
It seems to consider that a loop breaks the relation order entirely and
doesn't attempt to follow it any further.

I still pushed the changes since they contain a few added members, but I think
the N30 (and other N roads) will have to stay unsorted, unless JOSM's sorting
mechanism starts taking geographical proximity into account instead of
strictly checking the end nodes.

Regards,

Nathan Monfils



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

Re: [OSM-talk-be] National Road relation: does order matter?

[André Pirard]

On 2018-09-03 00:24, Jo wrote:
for route=road relations order doesn't matter much. It's impossible to 
sort them according to any meaningful criterion.
A meaningful criterion to sort a route is so that two adjacent ways of 
it share one same end node.
In other words, that the route is ordered the way you travel it without 
interruptions.

That's what the "sort" buttons of JOSM do.
And, beside finding a segment more easily, the schema of the route made 
by JOSM shows the gaps (missing pieces).

And in particular it will show if the road is circular.
For example, if you sort the N30, you will see a gap between Boulevard 
de Fraipont and Avenue de la Libération.

And 16 other gaps in total.

Last time I spoke of routes with a Potlatch user, he told me he couldn't 
sort routes.

I don't know about ID and that's quite a time ago.

The N30 should be sorted and corrected.
I will let Nathan do it if he's busy with it.

Amitiés,

André.



Polyglot

Op zo 2 sep. 2018 om 22:54 schreef Nathan Monfils 
mailto:nathanmonf...@gmail.com>>:


Hello!

I was doing some editing on the N30 near Liège, when I noticed
that its
relation was completely unordered, with ways near the city center
being next
to ways much further south (see relation `124374`).

The wiki defines a relation as an *ordered list*, yet only
mentions order for
bus lines. Is there a need for the road relations to be ordered
correctly?

Regards,

Nathan Monfils



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

Re: [OSM-talk-be] Ourthe = path?

[André Pirard]

On 2018-04-12 09:12, Stijn Rombauts wrote:
>> On ‎Thursday‎, ‎April‎ ‎12‎, ‎2018‎ ‎01‎:‎06‎:‎49‎ ‎AM, Gerard
>> Vanderveken  wrote:
>>
>> Goedendag,
>>
>> Hier heeft er eentje bij derivier Ourthe
>> 
>> een highway=path toegevoegd.
>> Is zo een dubbel gebruik van waterway en highway tags korrekt?
>>> Ici on a ajouté un chemin d'autoroute = à la rivière Ourthe.
>>> Une telle double utilisation des voies navigables et des plaques
>>> d'autoroutes est-elle correcte?
>>> (?)
>> Met vriendelijke groeten,
>> Gerard
> Hoi,
>
> Dat is zeker niet correct. Ik denk dat zelfs best die hele changeset
> wordt teruggedraaid. Zie ook bv.
> http://www.openstreetmap.org/way/372287784/history. Hij heeft een hele
> boel objecten diezelfde tags als highway=path e.d. gegeven en dus om
> zeep geholpen...
>> Ce n'est certainement pas correct. Je pense que même tout le
>> changeset est [devrait être?] inversé. Voir aussi, par exemple,
>> http://www.openstreetmap.org/way/372287784/history. Il a donné [à?]
>> tout un tas d'objets qui ont [?] les mêmes tags que highway = path et
>> ainsi de suite et ainsi ...
>
> Mvg,
>
> StijnRR
>
Bon moment présent,

En lisant le change set
, on voit en effet, en
plus, "You added highway=path andother path tags in three forest polygons".
Le mieux est en effet de faire un "revert" mais pas, comme certains en
ont l'habitude, sans avertir l'auteur.
Ne fut-ce que pour lui éviter d'autres erreurs ultérieures.
Est-ce de la distraction ou de l'incompétence (auquel cas se pose de
nouveau la question de la nécessité d'une certification des cartographes)?
Après 3 mois, un revert risque d'effacer d'autres modifications. Il faut
examiner les objets impliqués.
Il est étonnant que de telles erreurs (surtout l'Ourthe) restent 3 mois
sans êtres remarquées.
Merci Gerard.
Je me demande pourquoi utiliser des traces GPX et faire des imprécisions
de 1-2m ou plus alors que nous pouvons tracer le PICC à 20cm près
(extrait ci-dessous).

Cordialement,

André.






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

Re: [OSM-talk-be] [Tagging] area=yes on object without kind + using PICC & JOSM

[André Pirard]

On 2018-01-12 14:52, Jo wrote:
> You are right in that we shouldn't base any of our mapping on what is
> visible on Google Streetview. Which is why I was suggesting that
> somebody go check it out locally. I've been looking at Belgian aerial
> imagery we are allowed to use, taken over several years. But nothing
> useful can be seen on them either. What can be seen is that almost
> never more than 1 car was parked there when the planes flew over. So
> it's definitely not a parking lot.
>
> I don't think we really have a way to tag an empty piece of land with
> no defined "function" nor vegetation on it,
>
> Jo
I have overlaid OSM with the PICC (the digitalized version of those
aerial photographs).
The PICC shows nothing more than the road border.

The PICC has a 20cm precision, is extremely well done and we can trace
it (not to be confused with "copy").
I often *highly* recommend to use the PICC with JOSM in Wallonia.
In fact, I'm spending much time to use them to correct what is
neigbouring what I'm mapping.
Often, for example, the buildings are traced as roofs based on
imprecise, vague aerial photos.
PICC shows building bases instead, very cleverly and precisely
calculated from multiple photo angles.
And with Area Selector, one can trace a streetfull of houses in a single
click each, including numbers.
I've been asked why ID and Potlatch would be worse than JOSM.
I don't know. Just that when I meet something to leave as is, I know and
I can check that it's JOSM.
See my picture. It's Potlatch.
The "area" is offset 2 m on the right and 6 m on south.
The building is 5 m away from its place and it has no number 2.
The pedestrian crossings 2m and 5m, the wood on the right 6 m.
Etc ... Often, more complicated maps are simply horrifying.
The roads are mostly right but I believe that it's better to follow
PICC's way choices closely to show that PICC was used. And PICC does the
conversion of curved to straight lines for you.
Mistakes are sometimes easily corrected with JOSM's Improve Way
Accuracy, but it's harassing to spend much time doing that while other
mistakes continue to be made. And mapping a new house is much, much
faster than correcting a bad one.

*PLEASE, PLEASE* use PICC with JOSM in Wallonia !!!
Wallonia have lost 6 years while I was trying to have the SPW correct
their PICC server's mistake and I was helping JOSM to improve.
JOSM is not really difficult to use. Use it more ans more in parallel
with another software, which you can use when you're stuck until you
find out how to do it with JOSM. You will appreciate what more you can
do with JOSM.

Cheers
Cordialement,

André.




>
>
>
> 2018-01-12 14:38 GMT+01:00 José G Moya Y.  >:
>
> Please notice that, for doing something similar to what you do
> here (reading a lot of maps and aerial imaginery, being only one
> of them [3] google maps) I was forced to erase my edition and do
> it again.
> Just to warn you.
>
> El 12/1/2018 8:30, "Jo"  > escribió:
>
> It definitely doesn't look like a public parking lot. It would
> be good if someone local could resurvey if the shop is still
> in that house.
>
> Jo
>
> 2018-01-12 5:19 GMT+01:00 Marc Gemis  >:
>
> is there street view imagery ? do you have local knowledge ?
>
> If not, you might consider not fixing it. Yes it will be a
> useless
> polygon in the database, but isn't that better than
> changing it e.g.
> to a parking lot while it is a private property ?
>
> just my .5 cents
>
> m.
>
> On Fri, Jan 12, 2018 at 12:05 AM, OSMDoudou
> <19b350d2-b1b3-4edb-ad96-288ea1238...@gmx.com
> > wrote:
> > Hello,
> >
> > Osmose is complaining an area is mapped but not further
> specified: [1] and
> > [2]
> >
> > Here is how the place looks like: [3]
> >
> > I was thinking it's a side walk, but they're not to be
> mapped as area [4]
> > and the place doesn't really look like a square or plaza
> [5] nor like a
> > parking.
> >
> > How would you tag it ?
> >
> > Thx.
> >
> > [1] http://osmose.openstreetmap.fr/en/error/15140678368
> 
> > [2] https://www.openstreetmap.org/way/223853253
> 
> > [3] https://goo.gl/maps/yhA3rx2WVhM2
> 
> > [4] https://wiki.openstreetmap.org/wiki/Key:sidewalk
> 
>

Re: [OSM-talk-be] [Tagging] how to map a fr:talus?

[André Pirard]

On 2017-11-24 10:55, ralph.ayt...@ntlworld.com wrote:
>
> I have had a look on the Wallonia website. If you zoom out you will
> see that this feature runs exactly parallel to the road to the south
> of it. It is man made. It would have been created at the same time as
> the road. It was done to raise the road to a higher level as a flood
> defence against the river to the north. I do not know but it may be
> that there is a retaining structure of stone or concrete to strengthen
> it but is covered with soil and grass.
>
>  
>
> The tag for this could be /man_made=dyke/ with /material=soil/.
>
>  
>
> You will see that the farmland to the south of the road has something
> similar. This is not flood defence, it is terraced farming to stop the
> run off of water on sloping farmland.
>
>  
>
> The tag for this could be /barrier=retaining_wall/ with
> /material=stone/soil/ (or whatever material is used)
>
> Hope this has been helpful.
>
>  
>
> Ralph
>
Thank you, Ralph.
If you look down below (as people started to write bottom up in the XXth
century) you will see that I found Projet de canal Meuse et Moselle
<https://fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle>
(Genglish
<http://translate.google.be/translate?u=https%3A//fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle&hl=fr&langpair=auto%7Cen&tbb=1&ie=UTF-8>),
seeming to confirm what I wrote: that talus is the remnants of that old
canal, commonly called "canal de l'Ourthe", washed away by the frequent
flooding of the Ourthe and of various fate along its course.
So, what I should normally do is map a canal.
But as nobody ever saw a canal with a single bank looking like a talus,
that would get me in troubles.  Not counting that the rendering, even if
we cannot tag "for" it, would try to fill it with water and cause even
more flooding ;-)

So, good-bye canal, what it has now become is a crumbled bank, a
crumbled wall I suppose..

That is just as queer, so, unless you change your mind, I'll tag it man
made=embankment
<https://wiki.openstreetmap.org/wiki/Tag:man_made%3Dembankment>,
according to your repeated consent, but only as a single way at the top
of the slope I suppose.
But I'll name it an old canal's bank.

Thanks to all,
Cheers,

André.


> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>  
>
> *From: *André Pirard <mailto:a.pirard.pa...@gmail.com>
> *Sent: *Thursday, November 23, 2017 10:29 PM
> *To: *OpenStreetMap Belgium <mailto:talk-be@openstreetmap.org>
> *Cc: *Tag discussion, strategy and related tools
> <mailto:tagg...@openstreetmap.org>
> *Subject: *Re: [Tagging] [OSM-talk-be] how to map a fr:talus?
>
>  
>
> On 2017-11-23 17:26, joost schouppe wrote:
>
> 2017-11-23 16:48 GMT+01:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> I'm looking for how to map what is called in French a talus
> <http://www.cnrtl.fr/definition/talus> (Google's translation).
> I would call this a 1.8m simple step running for some reason
> for several 100s meters across meadows.
> Steep slope. There are "top of slope" and "bottom of slope"
> lines. Rest is perfectly flat either side.
> It might be the remnants of a old canal's bank whose other
> side would have been eroded by the often overflowing nearby river.
> A "talus" made of plain ground is often frequent at one side
> of a path or track.
> According to the wiki, it's not a "scree" nor a "shingle".
> It's much less matter specific.
> So what?
> I'll use "scree" unless/until I hear of better for a French talus.
>
> Cheers
>
> André.
>
> I'm not entirely sure this is what you have in mind, but in the
> cases where it is associated with roads, I've seen
> historic=hollow_way (when the slope is caused by the fact that
> there's an old road), and "embankment" or "cutting" when the slope
> is deliberatly constructed. In other cases, I've seen what I think
> you describe mapped as natural=cliff, which is obviously wrong,
> but does get the message accross. For example where sand or rock
> was quarried this is common to see on the map. I'm hoping someone
> has seen better ideas.
>
> Thanks for all your fast answers from which I had to choose the first
> one to reply to.
> A photo was asked. I might go back there to make one, but you wouldn't
> see more that the surface of a meadow l

Re: [OSM-talk-be] how to map a fr:talus?

[André Pirard]

On 2017-11-23 17:26, joost schouppe wrote:
> 2017-11-23 16:48 GMT+01:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> I'm looking for how to map what is called in French a talus
> <http://www.cnrtl.fr/definition/talus> (Google's translation).
> I would call this a 1.8m simple step running for some reason for
> several 100s meters across meadows.
> Steep slope. There are "top of slope" and "bottom of slope" lines.
> Rest is perfectly flat either side.
> It might be the remnants of a old canal's bank whose other side
> would have been eroded by the often overflowing nearby river.
> A "talus" made of plain ground is often frequent at one side of a
> path or track.
> According to the wiki, it's not a "scree" nor a "shingle". It's
> much less matter specific.
> So what?
> I'll use "scree" unless/until I hear of better for a French talus.
>
> Cheers
>
> André.
>
> I'm not entirely sure this is what you have in mind, but in the cases
> where it is associated with roads, I've seen historic=hollow_way (when
> the slope is caused by the fact that there's an old road), and
> "embankment" or "cutting" when the slope is deliberatly constructed.
> In other cases, I've seen what I think you describe mapped as
> natural=cliff, which is obviously wrong, but does get the message
> accross. For example where sand or rock was quarried this is common to
> see on the map. I'm hoping someone has seen better ideas.
Thanks for all your fast answers from which I had to choose the first
one to reply to.
A photo was asked. I might go back there to make one, but you wouldn't
see more that the surface of a meadow looking like this on a long
distance, at varying steepness and width.
   _
  /
 /
/

It can be seen on this map share
<http://geoportail.wallonie.be/walonmap#BBOX=233801.45736786586,233864.69291100363,138369.75440413086,138396.60966617474#SHARE=5EAB0363BC0C4A92E053D0AFA49D3CB8>,
pan it to the left and right.
The two striped, faint lines are the upper and lower edges (rims,
levels) from the BE SPW(allonie) PICC numerical imagery
http://geoservices.wallonie.be/arcgis/services/TOPOGRAPHIE/PICC_VDIFF/MapServer/WmsServer?SERVICE=WMS&VERSION=1.1.1&FORMAT=image/png8&TRANSPARENT=TRUE&REQUEST=GetMap&STYLES=&SRS=%7Bproj%7D&WIDTH=%7Bwidth%7D&HEIGHT=%7Bheight%7D&BBOX=%7Bbbox%7D&LAYERS=0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29>
(JOSM) overlay allowing me to map it. As you zoom out, you will see that
the aerial photo is darker along that line.
The Cartoweb background (Fond de Plan) draws it as the typical "behind
which to hide" line of old military maps.
Well, in OSM parlance, it's not a cree because there is no cliff (1),
not a shingle because there is no sea and not an embankment because
there is no road to be an attribute of.
Well, as I said it, what I'm facing seems to be, as I found more
specifically, the remnants of this old canal @ N°12
<https://fr.wikipedia.org/wiki/Projet_de_canal_Meuse_et_Moselle#N.C2.B012_Devant_Rosi.C3.A8res>.
The river often overflows as high as above the road. When the water goes
back, it washes the left bank of the canal towards the river but the
right bank is mostly just overflown.

So, there's nothing in OSM for that precisely.
Would man_made=dyke be the most resembling and acceptable with an
explanation note?

Thanks and TIA,
Cheers

André.


(1) there's a very beautiful one, but at the other side of the river,
called "La Roche aux Faucons" (Falcons' Cliff).

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

[OSM-talk-be] how to map a fr:talus?

[André Pirard]

Hi,

I'm looking for how to map what is called in French a talus
 (Google's translation).
I would call this a 1.8m simple step running for some reason for several
100s meters across meadows.
Steep slope. There are "top of slope" and "bottom of slope" lines. Rest
is perfectly flat either side.
It might be the remnants of a old canal's bank whose other side would
have been eroded by the often overflowing nearby river.
A "talus" made of plain ground is often frequent at one side of a path
or track.
According to the wiki, it's not a "scree" nor a "shingle". It's much
less matter specific.
So what?
I'll use "scree" unless/until I hear of better for a French talus.

Cheers

André.


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

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[André Pirard]

On 2017-11-21 00:08, marc marc wrote:
> Hello,
>
> Le 20. 11. 17 à 23:49, Ubipo . a écrit :
>
>> I don't know of any library that does all that :(
> https://github.com/googlei18n/libphonenumber/
> I never use it but it look like fine.
>
> Regards,
> Marc
That's what the JOSM suggestion
 speaks about.

Cheers

André.



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

Re: [OSM-talk-be] Belgium Phone Format OSM Tool

[André Pirard]

  
  
On 2017-11-18 13:49, Ubipo . wrote:


  Hey all,




I wanted to let you know about a tool I made called 'BPF'
  - Belgium Phone Formatter.
When provided with OSM login credentials and a list of OSM
  ID's to fix, it scans those 
  objects for 'phone', 'contact:phone', 'fax' and 'contact:fax'
  tags and attempts to normalize them.
  

Hi,

  I reported to JOSM that someone reported that a Frenchman
reported that he found many invalid phone numbers in OSM tags.
The comments  show that JOSM takes it as seriously as usual
(everybody should use JOSM).
You may want to contact them.

Cheers



  

  André.

  



  
If it fails (sees a difficult/unrecognized number), it
  leaves the whole object unchanged.




The tool/script is mainly meant to make this MapRoulette challenge
  a little easier.
But if you find another use for it feel free to download
  and use the python script from https://github.com/Ubipo/BpfOsmTool.


The reason that particular MapRoulette challenge isn't
  fixed already is that:
One: I wanted some other people's input about whether this
  is a good idea.
And two: I'm having some problems with the MapRoulette API:
  Google
Doc




Best,
Ubipo
ubipo.ski...@gmail.com
OSM Profile
  
  
  
  
  ___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be



The 
  

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

Re: [OSM-talk-be] Do you Tag those as cycleway?

[André Pirard]

On 2017-09-29 22:46, eMerzh wrote:
> just another example a little more cycleway...
> https://www.mapillary.com/app/?pKey=GnblTsSKolUsjQ6URC0zyg&focus=photo&lat=50.86767032&lng=4.3280441&z=17&x=0.510308202857&y=0.4999&zoom=0
>
> but still for me the delimitations are not really clear ... and
> calling that a cycleway seems. unfair :p
>
> 2017-09-29 22:42 GMT+02:00 eMerzh  >:
>
> hi,
>
> i stumble upon some streets that have small cycles drawn on the
> street now and then, and often there are small dashed line at the
> start or the end of the street,
> but tagging those as cycleway seems a bit weird as there are no
> clear delimitations...
>
>
> How to you tag thoses?
>
>
> An example :
> 
> https://www.google.be/maps/@50.8674422,4.3297542,3a,60y,141.06h,86.52t/data=!3m6!1e1!3m4!1srWr6HwmC8P9LgEfOSk2Xpg!2e0!7i13312!8i6656
> 
> 
>
>
> Thanks
>
Why not ask the police?
Isn't it their job to inform about doubtful road signs?
For the fun, send them the URL of the wiki and say "please choose".
And post the answer back here !!!
And if they answer that those signs are lookalikes, answer that
lookalikes must be fined ;-)

Cheers

André.





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

[OSM-talk-be] RFC: Defaults are paramount, abandoning Proposed_features/ is a HUGE mistake

[André Pirard]

Hi,

Examples: either each road is tagged with *maxspeed*=*
 speed limit and
*driving_side*=* 
or there are defaults.
I'm reviving this remark because the examples are numerous:

  * The Belgian Flemish community wants to tag *maxspeed*=*
 on every road
instead of using a default. Is this a new specification and where is
it written? Must that now be done in every country?
  * The current language= proposition wants to do it without defining
defaults. Really? language= on every name= ?
  * Other examples are maxheight in tunnels. Osmose just accused me of
someone else's omitting maxheight. It shouldn't be necessary if it's
the default, that is if there is no sign for it, but Osmose likes to
yell just in case.
  * countless etc.

Please choose.

Either the defaults are in the OSM database and it takes just a
routinely map fetch to get them all updated timely,
or each other router (GPS) writer implements them each their own way
from various random other files. It's not well clear how contributors ca
update all those files instead of OSM and it typically needs a full
software update for each little default change, depending on writer's
availability.

Please choose.

There is a Proposed_features/Defaults
 that
puts the defaults in OSM and it's an EXTREMELY HUGE mistake to have
marked such a paramount good work as abandoned because nobody continued
the work.  For the sake of OSM, especially routing, please reopen it.
I don't claim that it is the good solution but I do claim we should work
on such a default database *in priority*.

I didn't analyze it in full depth, but I have the following remarks:
- Why not allow the def keyword in the border relation itself? But it
could be called zzdef to cluster at the key end.
- If a separate relation is preferred, it should be pointed at by a
"defaults" role in the corresponding border or other relations so that
it can be found.
- to ease scanning a border tree upwards, a "parent" relation should
exist in border relations.

In hope of a well structured OSM,

Cheers

André.




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

Re: [OSM-talk-be] AreaSelector source (JOSM pour tracer les bâtiments)

[André Pirard]

On 2017-05-04 11:13, Verhoeven Fr wrote:
> Le 03/05/17 à 21:00, André Pirard a écrit :
>> On 2017-05-03 11:42, Sus Verhoeven wrote:
>>> Bonjour,
>>>
>>> Me référant au message qui suit je m'adresse à vous pour de l'aide
>>> vu ma faible connaissance de l'anglais qui me retient de m'adresser
>>> à l'auteur.
>>> Depuis quelque temps j'utilise  Area Selector avec le cartes AGIV
>>> pour la Flandre. Malheureusement depuis la dernière mise à jour de
>>> Josm je constate que AS colle automatiquement le tag "source". Mais
>>> pour cela il utilise le nom de toute les couches qui sont activées à
>>> ce moment, ce qui est illogique et oblige soit à chaque fois
>>> désactiver ces couches, soit à corriger ou à supprimer la source, et
>>> rend le contrôle par les vues aériennes fastidieux.
>>> Si le nom de la couche n'est pas explicite cela fait désordre.
>>> Question: avez vous le même problème et pouvez vous faire qq chose ?
>>>
>>> Merci à vous
>>>
>>> Sus  alias  susvhv
>> Bon présent Sus,
>>
>> J'ai aidé Paul, l'auteur de Area Selector, à trouver la raison pour
>> laquelle son programme ne fonctionnait plus.
>> Cela a pris pas mal de temps parce que c'était un conflit avec le
>> cœur de JOSM qui a dû être modifié aussi.
>> Maintenant il fonctionne mais moins bien qu'avant et j'introduirai
>> des remarques dès que j'aurai te temps.
>>
>> Tu expliques très bien le problème "source" qui est nouveau pour moi
>> et je viens de l’expérimenter.
>> Mais encore?  Est-ce quelqu'un a une suggestion pour l'éviter?
>> Actuellement, si l'utilisateur indique sa propre valeur pour
>> "source", AT la remplace par la sienne.
>> Moi, je vais proposer que dans ce cas il n'y change rien.
>>
>> Autre chose à dire?
>>
>> Paul va changer ça.
>> Ces gens de JOSM sont extraordinaires.
>>
>> Cordialement,
>>
>> André.
>>
>
> Salut André,
>
> Merci pour votre réponse rapide.
> Pour Area Selector je suggère de compléter le panneau des tag  avec
> des cases à cocher, comme dans Housenumber Tagging Tool, pour choisir
> les tag que l'on désire compléter.  Actuellement laisser le champ
> 'source' vierge ne sert à rien.
>
> J'ai un autre problème avec JOSM, mais c'est une autre histoire.
>
> Happy mapping. ;-)
>
> Sus
Hi Sus and All,

Paul vient de corriger le bug que j'avais ouvert.
AS maintenant n’utilise plus par défaut que le dernier source=* utilisé.

Meilleurs regards,  ;-)
Cheers
Cordialement,

André.











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

Re: [OSM-talk-be] How to map an amenity that spans several buildings?

[André Pirard]

On 2017-07-09 13:53, Yves bxl-forever wrote:
> Hi,
>
> Philippe raised an interesting point about the following note.
> http://www.openstreetmap.org/note/722850
>
> There are several occurrences where a shop or an amenity spans over several 
> buildings.
> Buildings have their own id based on UrbIS data, I suppose it will not be 
> appropriate to merge them, even when they appear as being one single house.
>
> For this very case (Maison Dandoy), the shop spans over 4 different buildings 
> and they does not seem to have any other use (nobody lives upstairs and there 
> is no door): perhaps a multipolygon will work here.  But if there is a 
> solution that covers most cases, it might be useful to hear about, and avoid 
> that careless mappers would duplicate nodes or ask endless questions about 
> "missing" items.
>
> Any idea or suggestion?
>
> Many thanks.
> Yves
I had to improve a school made of several buildings and it was a simple
amenity=* polygon enclosing the buildings.
I find this quite nice and simple, only subject to rare problems if
there were multiple amenities sharing the buildings in various ways,
unless the amenities were allowed to nest or overlap one another.
Generally, the amenities are drawn inside one building.
Also, it has been discussed on Tagging@ that a house number of a
buildings can also be indicated on an amenity to specify which entrance
to use to reach it.  And I added the obvious "also to have the amenity
tags contain its complete list of information". The unwary could
otherwise believe that there is no number.

Cheers

André.



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

Re: [OSM-talk-be] Potlatch crasht keer op keer

[André Pirard]

Hi Karel,

Beside running JOSM, which is highly recommended,
you might try an alternative Flash player found here
.

Cheers

André.



On Sat, Jul 1, 2017 at 4:56 PM, Karel Adams  wrote:
> Already for a couple of weeks, Potlatch crashes when I try to add a "blank
> node" to serve as a beginning of a way.
>
> For those who didn't yet know: I am almost exclusively into mapping
> aerdromes, and prefer Potlatch. I can, and still do, add aerodromes by
> dragging the relevant icon into map, no issue there. But I can no more add
> runways: when I click the first end point, there is an immediate crash. Not
> really of Potlatch but rather of the underlying "Adobe Flash plugin". I've
> already sent tons of error reports, and updated versions of the Flash plugin
> have appeared and were duly installed, still no improvement.
>
> What can be done?
>
> Environment: Ubuntu 16.04+ Firefox, both religiously patched up to date.
>

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

Re: [OSM-talk-be] Tagging of schools/college

[André Pirard]

On 2017-05-31 15:10, Guy Vanvuchelen wrote:
> Volgens mij is 'school'voor België de beste oplossing. In één school kunnen 
> immers meerdere afdelingen zijn: beroepsonderwijs, maar ook ASO. Als je 
> Wikipedia zou volgen is 'college' een klassikale les krijgen aan een 
> universiteit. Als je googled naar 'beroepsonderwijs in college' kom je 
> gegarandeerd op een Nederlandse school terecht, dus daar kan het wel 
> 'college' zijn. 
> GuyVV
> Je pense est school'voor Belgique, la meilleure solution. Dans une
> école plusieurs ministères peuvent en effet être: professionnel, mais
> ASO. Si vous suivez « collège » Wikipedia recevoir une formation en
> classe dans une université. Si vous googlé pour « l'enseignement
> professionnel au collège » vous garanti une école néerlandaise à juste
> titre comme il peut être « collège » est.
> > GuyVV
???
Jo nous a expliqué qu'on écrit en flamand quand le problème est flamand
mais c'est souvent loin d'être le cas.
Pourquoi ne pas fournir une traduction plutôt que de demander à 100
personnes d'en faire une?

De quel tag s'agit-il exactement?
"college" signifie enseignement supérieur en anglais.
Comme il y a de gros problèmes de correspondance de termes, même avec la
France, pourquoi ne pas utiliser "collège:BE" ou, encore mieux s'il le
faut, "collège:BE:fr"?
En plus de "school", évidement.

Which tag is it exactly?
"College" means higher education in English.
As there are big problems of aanpassing of terms, even with France, why
not use "collège:BE" or, better still if needed, "collège:BE:fr"?
In addition to "school", obviously.

Welke tag is het precies?
"College" betekent het hoger onderwijs in het Engels.
Omdat er grote correspondance problemen zijn, zelfs met Frankrijk,
waarom niet "collège:BE" gebruiken of, nog beter, indien nodig,
"collège:BE:fr"?
Naast "school", natuurlijk.

Cheers

André.


> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
> Verzonden: woensdag 31 mei 2017 5:16
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] Tagging of schools/college
>
> A Dutch mapper changed the "Hoe map ik een" school the other day.[1]
> The original discussion leading to the change can be found here: [2]
> in Dutch and with a lot of acronyms specific for The Netherlands.
>
> Do we want to map "Middelbaar beroepsonderwijs." (L'enseignement
> secondaire professionnel ?) as college ? I would never have thought to
> map them as college, but I could be wrong.
>
>
> m.
>
>
> Een Nederlandse mapper heeft de sectie voor hoe map ik een school
> aangepast [1] naar aanleiding van een discussie op het Nederlandse
> forum [2]. Nu zouden we middelbaar beroepsonderwijs als college moeten
> mappen. Ik zou er nooit aan gedacht hebben dit zo te taggen,
> waarschijnlijk had ik gewoon school gebruikt. Ik heb het misschien bij
> het verkeerde eind. Wat denken jullie ervan ?
>
>
>
>
>
> [1] 
> https://wiki.openstreetmap.org/w/index.php?title=Template:NL:How_to_map_a:S&diff=next&oldid=1390987
> [2] https://forum.openstreetmap.org/viewtopic.php?id=57278
>

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

Re: [OSM-talk-be] Authorization request for use of SPW data (PICC, orthophotos and others) and OSM representative

[André Pirard]

On 2017-05-30 18:43, Thomas Bertels wrote:
> Hi,
>
> After different emails to
> * helpdesk.carto AT spw.wallonie.be (no official answer)
> * carlo.diantonio AT gov.wallonie.be
> * rene.collin AT gov.wallonie.be
> * jeanclaude.jasselette AT spw.wallonie.be
What is the need to contact all those people after a SPW lawyer made the
situation clear?
> I've finally received an email from Vincent Bombaerts
>  (vincent.bombaerts AT
> spw.wallonie.be), Attaché to the SECRÉTARIAT GÉNÉRAL of the DIRECTION
> DE L'INTEGRATION DES GEODONNEES.
>
> Following that, I've been on the phone with him and he told me that,
> like many already know, we can use the data from the SPW for OSM.
Not at all.
For anyone having understood the terms of the SPW that are clarified in
my "YES we can trace the PICC" message, we are not allowed to use (copy)
the (vector) data of the PICC but we are allowed to trace the images of
the WMS et al. services.
> I had been requesting authorization for PICC and orthophotos, but he
> told me that there are other potentially useful data like MNT
> 
> (relief) and others.
>
> However, since I'd been asking for an explicit authorization (needed
> for integration into the iD editor), he told me that the authorization
> contract templates they've got require an organization. Probably
> because the data is free of the associations without lucrative purpose.
First, I strongly discourage using ID and Potlatch. This is what has led
to highly imprecise Wallonia tagging as well as introducing tagging
errors over the years.  All that work has to be redone with correction.
Please use the PICC with JOSM to achieve a 25 cm precision excellent
tagging.

Second, I'm not sure how ID could use the vector data that we could get
a license to copy.

Let us recall that the "copying" of PICC's data is subject to 1) a
possibly payed license 2) signed between SPW and the user 3) for only a
well defined, agreed part of Wallonia 4) over a limited period 5) for an
agreed restricted use.
Look at this file
.
This is certainly not for all OSM contributors to put that data in OSM !!!
> He suggested Open Knowledge Belgium
> , which is the parent of
> OpenStreetMap Belgium .
> I told him that what matters is that all OSM contributors are allowed
> to use SPW data for OSM.
I think that, after the very complete clarification I posted, this is
confusion again between copying the data and tracing the services.  What
is amazing this time is that SPW personal themselves are making the
confusion, at least as you say it.

Cheers,

André.


> He would like to have someone to talk to on behalf of the Belgian (or
> at least Walloon) OSM community, to discuss further about the terms
> and potential future cooperation with OSM.
> That person would be a link with the OSM community and would represent
> it when talking with him.
> Like the SPW, Vincent Bombaerts is based in Namur, but can and does go
> to mapping and related initiatives like State Of The Map 2016
>  (in
> Brussels) and FOSDEM. So the meeting(s) don't need to take place in Namur.
>
> Is anyone interested to be that person?
>
> Hopefully, those licensing issues should be soon a thing of the past.
>
> Thomas Bertels

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

Re: [OSM-talk-be] YES, we can trace the PICC

[André Pirard]

Hi,

This is the last e-mail I'll write about this because it's very clear
that the SPW allows OSM to trace the PICC.

On 2017-05-11 08:53, joost schouppe wrote:
> Hi,
>
> Sorry, this became a rather long mail. But it is important, and I
> tried to be as clear as possible.
>
> Meanwhile I spoke with Lionel on our Riot channel [1] and with Simon
> Poole through legal-questi...@osmfoundation.org.
>
> If I understood, André says this:
>
> - the license for all the geoportail WMS products is this [2]
Please look at what that file says and at the SPW site.  That text
contains the default conditions, but it says that other "Conditions"
(files) may exist in the "Accès" tab such as for Cartoweb.be
.
> - that license does not allow copying
"copying" has nothing to do with services (WMS) but with downloading
vector data. That is *another* license as I explained.
> - the geoportail team is the intermediary between the data source and
> the citizen, and can represent the data source
> - the geoportail team says (in a copy pasted mail) that yes, tracing
> the PICC WMS is considered consulting and that is allowed
More exactly, the geoportail states in that PDF document you call [2]
that "le SPW permet l’accès et l’utilisation gratuits des services par
tout utilisateur", meaning that anybody can do anything with the WMS
service. It means that it is "public domain".
The SPW further explained in a semi-private official e-mail for those
who do not understand the OSM implications of that sentence, that OSM is
allowed to "se connecter sur le serveur du SPW et calquer le PICC afin
de faire des fonds de plan (=vectoriser), réutiliser à sa guise les
fonds de plan (commercialement ou non)", that is, tracing the WMS
service and put that trace and everything found in PICC to the OSM database.
That is not the license (terms of use) of PICC but an equivalent
explanation of the above first sentence in OSM context.
> So things you could help answer:
> - are we sure Geoportail has the authority to clarify this license? (I
> don't know enough about Walloon gov structure; Lionel is quite sure
> they do; more opinions would be nice)
If you see maps on a site, if you see the conditions of use written next
to them, and if they say
> Toute question relative aux conditions d’accès et d’utilisation des
> services est envoyée à :
> SPW – Département de la Géomatique - Direction de l’Intégration des
> géodonnées
> Chaussée de Charleroi, 83 bis, 5000 Namur OU
> helpdesk.ca...@spw.wallonie.be
is there any doubt that they are authoritative?
> - is the wording used in the e-mail enough?
> - is an e-mail enough or do we need something a bit more formal?
Once again, the e-mail is not the license.
It's trying to make understand that simple sentence of the license which
is [2].
> - is this answer also valid for other WMS
Supposing that "this answer" means "the e-mail", it was written for the
PICC.
But it is of course true for the services for which that file you call
[2] is the license but not if they have contradictory conditions.
> The answer from OSMF is quite clear:
I provided URLs for the SPW and their texts.
Could you please do the same with OSMF? (OSMF?
)
I couldn't find anything leading to what you say.
> - if the license does not explicitly allow tracing, then you need a
> written permission
> - a written document (signed and scanned PDF) is always best, but
> e-mails can be acceptable
Once again, the e-mail is not the license.
Requesting a PDF is quite strange because PDF is a format used to send
to a printer and we certainly don't want to print licenses. PDF does not
contain data defining the format (e.g. paragraphs and tables) and,
beside printing it, it's not possible to convert it or copy&paste it
reliably; that implies guesses and making errors.
HTML is quite OK and better and, while PDF cannot be converted to HTML
(reliably) those who can't live without PDF can convert HTML to PDF
reliably. But it's a dead end.

*We do have* an SPW PDF file, that you call [2] and that I call
"Conditions d’accès et d’utilisation des services web géographiques de
visualisation du Service public de Wallonie
".

> - the text needs to contain something like the first paragraph of this
> text [3]. This contains legalese explaining what tracing for OSM
> implies. Generally, language like this will trigger the person
> answering the request to check higher up in the organisation, so we
> can be more sure someone with actual power in the organisation signs
> the document.
>
> I think this answer implies that:
> a) we shouldn't call other's vigilantes just because they feel what we
> currently have is not enough, as what we have clearlu is not what the
> OSMF would like is to have
> b)  we do kind of have something, so there probably is no 

Re: [OSM-talk-be] Dixit JOSM: missing tag - street with odd number of lanes, but without lanes:forward and lanes:backward or oneway

[André Pirard]

On 2017-05-25 10:09, Yves bxl-forever wrote:
> Hi,
>
> The way I understand this warning is that a two-way highway with an odd 
> number of lanes (in this case 3) should get "lanes:forward=2" and 
> "lanes:backward=1" to make the count.
> This is not linked with the "turn:lanes" key, despite the number of lanes 
> should obviously match.
>
> Have a great day.
> Yves
Hi,

Thank you Yves, adding lanes:*=* makes it, no more JOSM messages.

But OSM documentation will always surprise me.
> If the lanes on a two way road are not distributed evenly between the
> driving directions, the keys *lanes:forward*=* and *lanes:backward*=*
> can be used in addition to the lanes tag.
It says that they *can* be used and not that they *must*.
And that it's *in addition* to the lanes tag, as if one could not count.
Plus, in my simple mind, removing duplication 3 and defaults 1 and "none" in
> lanes:backward=1
> lanes:forward=2
> lanes=3
> turn:lanes:backward=none
> turn:lanes:forward=left|through;right
makes it
> lanes:forward=2
> turn:lanes:forward=left|through;right
that make more obvious reading, doesn't it?

Moreover, as "|" is the OR symbol and ";" is the multiple values separator,
"left;through|right" would have been the intuitive, logical choice in
the same simple mind.

Oh well, I silently tiptoed backward away from that.

Cheers

André.


> On Thu, 25 May 2017 03:08:56 +0200
> "André Pirard"  wrote:
>
>> Hi,
>>
>> Just like Osmose does, JOSM accused me of those errors with tags I never
>> wrote: here <http://www.openstreetmap.org/note/1006680> and here
>> <http://www.openstreetmap.org/note/1006679>.
>> It appears that the mapper used turn:lanes:… and that JOSM wants lanes:…
>> I'll leave it to the specialists whether the mapper must correct a
>> mistake or open a JOSM bug.
>>
>> TIA,
>> Cheers
>>
>> André.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] Dixit JOSM: missing tag - street with odd number of lanes, but without lanes:forward and lanes:backward or oneway

[André Pirard]

Hi,

Just like Osmose does, JOSM accused me of those errors with tags I never
wrote: here  and here
.
It appears that the mapper used turn:lanes:… and that JOSM wants lanes:…
I'll leave it to the specialists whether the mapper must correct a
mistake or open a JOSM bug.

TIA,
Cheers

André.



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

Re: [OSM-talk-be] YES, we can trace the PICC

[André Pirard]

On 2017-05-10 11:58, joost schouppe wrote:
>
> I guess Glenn’s point is that the license issue cannot be
> circumvented, even if the king itself says something different
> than its contents.
>
> André, could you elaborate the statement that tracing = consulting? I
> don't really understand how you come to that conclusion
Rather consulting => tracing.
As opposed to "*copier*" which is what we would do if we imported PICC's
vector data, "*consulter*" is accessing the raster scan images of their
Web servers by any means. "Aucune contrainte d'accès pour la
consultation" means that we can do anything with those images, including
what I prompted the SPW to write in a OSM tailored document when I
recalled what we are doing: "décalquer", "trace", "overtrekken?",
something that we learn to do at the kindergarten together with
"picoter": put a sheet of paper on top of another and draw what is
underneath.
> I'm not really sure about this, but I think it could work if the
> copyright owner creates some official documentation explaining that
> tracing on top of their imagery is not considered copying. My French
> isn't good enough to understand if the mail from geoportail is saying
> exactly that. But if anyone thinks it would be possible to get them to
> add a clause like this, we could ask legal-questions if a model like
> that could work. I don't think a copy-pasted e-mail is enough though.
You can ask them to change their site, but I fear that you're getting a
huge problem on your hands because there seems to be no Web site in the
world that speaks of "décalquer". SPW seems to be the first one to speak
correctly, and you would have to ask to do the same to all the world
sites too !!!
I think that if 99,999% of the users will only figure printing the map
or so, the SPW might prefer to not embarrass those users by speaking of
tracing and having to answer what it means. They may prefer to issue an
OSM tailored version.
> > I made an overpass turbo script showing OSM with the Michelin's colors.
> > I won't show it because the vigilantes would accuse me to copy
> Michelin's colors.
> > While doing so, I noticed that the main axis Ans-Amercœur wasn't
> fully Michelin's colors.
> > So, this could produce suboptimal routes.
> > This is because a few N3 streets are tagged highway=secondary
> instead of =primary.
> > I certainly did not correct that because the vigilantes would say
> that it is copying Michelin.
>
> I'm still of the opinion that we cannot use Michelin to validate our
> own map. But here you're talking about using the coloring of OSM roads
> to look for strange situations. That is obviously OK. If you really
> want to do that in Michelin style colors because that's what you like
> to see, I don't think anyone could be against that (though copyright
> holders sometimes think in strange ways).
For one thing, speaking of colors was a joke but it seems that it
unwillingly proved how picky copyright matters can be.
First, if anything in copyrights is precise, it seems necessary to
clarify what you mean by "validate our map".
Second, please let Michelin themselves decide what they allow.
My impression from their reply is that they just don't mind.
And, if you find it necessary, please add this note to those secondary
streets: It is forbidden to change these National roads to primary
because someone once notices that they are so on a Michelin map.

Happy mapping,
Cordialement,
Amitiés,

André.



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

Re: [OSM-talk-be] YES, we can trace the PICC

[André Pirard]

On 2017-05-08 15:09, mgwebm...@fastmail.fm wrote:
>
> André,
>
> I guess Glenn’s point is that the license issue cannot be
> circumvented, even if the king itself says something different than
> its contents.
>
> You said that Glenn looked at the wrong file, but as far as I can see
> you didn’t provide any other one. Did you ?
At the wrong 3 files.
I provided the other one as follows:
>
>  *
>
>
>   Consulter (= browsing = what OSM does : tracing VIA A WEB
>   SERVICE)
>
> that is *browsing* or *tracing* and the conditions are:
>   o Conditions d’accès et d’utilisation des services web
> géographiques de visualisation du Service public de Wallonie
> <http://geoportail.wallonie.be/files/LicServicesSPW.pdf>
>   o that is: "Aucune contrainte d'accès pour la consultation".
>   o *absolutely no restriction on what the user can do with
> browsing and tracing the PICC*
>
That is the file that the SPW told me applies to "consulter".
Unfortunately, although it is linked by the other 3 files
<http://geoportail.wallonie.be/files/documents/ConditionsSPW/DataSPW-CGU.pdf>,
it just disappeared from their Web (1).
Additionally, I told them that it should appear under "conditions" under
"consulter" and there was no reaction (1).
Anyway, "Aucune contrainte d'accès pour la consultation" is copied from
it I swear and it speaks by itself.

Anyway, at this point of this game, I would like Julien Fastré to fix
these details with the SPW.
When I said about 1 year ago that the PICC server bug that I reported in
2010 wasn't corrected yet and prevented to use JOSM, he scolded me and
said that the SPW are very busy and devoted people.
I would like him to thank me for all this, and getting JOSM to work with
PICC in the first place, and to scold instead all those who criticize
the SPW as I read it.
> From the OSM point of view, Wallonia will need to endorse ODBL or any
> compatible license scheme in order fro PICC (and others) to be
> accepted as a valid data source. It’s an administrative and legal
> point of view, nothing personal for god’s sake !
"Aucune contrainte d'accès pour la consultation" means "public domain".
Isn't that compatible?
Now if you have a high-brow name like ZORGLUB for PD, just use it instead.
> I was recently in the process of mapping a big bicycle network
> (Wallonie Picarde à Vélo (4128428)
> <https://www.openstreetmap.org/relation/4128428>) and I had to stop at
> 70% of completion because the Province suddenly asked me (why me ?) to
> sign some documents that was completely against the ODBL license.
> Potentially the whole relation could be deleted right now, even if it
> took me hours and hours of work.
That is why I made it absolutely sure that it won't happen with the SPW
and the PICC.
> It’s sad but I’m afraid that until Wallonia move its ass and enters
> the 21st century their will be no progress possible on that front.
(1) They have official Web pages, they have an official e-mail address
on it, that from which I received the official document I showed. 
Anyone can write to them that their ass is not public domain. But I
would consult Julien first.
I myself have no more time to lose with nit picking.

Cheers
Cordialement,

André.


>
> Matthieu
>
>> On 7 May 2017, at 17:15, André Pirard > <mailto:a.pirard.pa...@gmail.com>> wrote:
>>
>> Très long message...  Read throughout, up to the end absolutely!
>> Highly important!
>>
>> Despite the explanation on SPW's site that PICC browsing & tracing is
>> public domain and the report from Julien Fastré, recalled by myself,
>> of what the PICC told him, the SPW would certainly not sue OSM for
>> using the PICC that way, vigilantes repeatedly say that the SPW could
>> and they threaten their mates with OSM exclusion and total
>> contribution removal, whatever the source. 
>>
>> This letter explains all that in greater detail.
>>
>> On 2016-02-26 17:52, Glenn Plas wrote:
>>> On 26-02-16 14:23, Thib wrote:
>>>> Hi,
>>>>
>>>> SPW PICC tiles layer is available in JOSM for mapping Belgian Southern
>>>> area but I can't find enough information about the license terms.
>>>>
>>>> Is it allowed to :
>>>> - copy (doing"calc") buildings and other objects boundaries (as we do
>>>> with bing tiles)
>>>> - get address house numbers
>>>>
>>>> I've found some old threads talking about that interesting source but no
>>>> real answer...
>>>>
>>>> If someone has any information abou

Re: [OSM-talk-be] YES, we can trace the PICC

[André Pirard]

  
  
On 2017-05-08 15:09, mgwebm...@fastmail.fm
  wrote:


  
  
  
  André,
  
  
  I guess Glenn’s point is that the license issue
cannot be circumvented, even if the king itself says something
different than its contents.
  
  
  You said that Glenn looked at the wrong file, but as
far as I can see you didn’t provide any other one. Did you ?

..at the wrong 3 files.
I provided the other one as follows:

  

  Consulter (= browsing = what OSM does : tracing VIA A WEB SERVICE)
  
  that is browsing or tracing and the conditions
  are:


  Conditions d’accès et d’utilisation des services
  web géographiques de visualisation du Service public de
  Wallonie
  
  that is: "Aucune contrainte d'accès pour la
consultation".
  absolutely no restriction on what the
  user can do with browsing and tracing the PICC

  

That is the file that the SPW told me applies to "consulter".
Unfortunately, although it is linked by

  the other 3 files, it just disappeared from their Web
(1) (am I a lucky chap?).
Additionally, I told them that it should appear under "conditions"
under "consulter" and there was no reaction (1).
Anyway, "Aucune contrainte d'accès pour la consultation" is copied
from it I swear and it speaks by itself.

At this point of this game, the official SPW document sent by e-mail
achieves my goal which is to reassure the mappers that the SPW won't
sue them and to stop the vigilantes' threatening.
Anyone not satisfied with the contents of the SPW Web should
obviously discuss that with them and not us (1).
And it would be yourself or Julien Fastré to fix the detail here
above with the SPW.

  From the OSM point of view, Wallonia will need to
endorse ODBL or any compatible license scheme in order fro PICC
(and others) to be accepted as a valid data source. It’s an
administrative and legal point of view, nothing personal for
god’s sake !

"Aucune contrainte d'accès pour la consultation" means "public
domain".  Isn't that compatible?
Now if you have a high-brow name like ZORGLUB for PD, just use it
instead.

  I was recently in the process of mapping a big
bicycle network (Wallonie

  Picarde à Vélo (4128428)) and I had to stop at 70% of
completion because the Province suddenly asked me (why me ?) to
sign some documents that was completely against the ODBL
license. Potentially the whole relation could be deleted right
now, even if it took me hours and hours of work. 
  

That is why I made it absolutely sure that it won't happen with the
SPW and the PICC.

  It’s sad but I’m afraid that until Wallonia move its
ass and enters the 21st century their will be no progress
possible on that front.

(1) They have official Web pages, they have an official e-mail
address on it, that from which I received the official document I
showed.  Anyone can write to them that their ass is not public
domain. But I would consult Julien first.
I myself have no more time to lose with nit picking.

Happy mapping,
Cheers,
Cordialement, 


  

  André.

  


  


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

Re: [OSM-talk-be] [Tagging] Missing oneway:bicycle=no / Wiki editing

[André Pirard]

On 2017-05-10 21:08, Thilo Haug OSM wrote:
>
> Hi André,
>
> according to this documentation,
> the tagging mailing list is the wrong platform to address this  :
> "*If you have ideas for the wiki, you can generally just do them, by
> editing the wiki! *
> If you need any assistance the *wikiteam* are here to help."
> https://wiki.openstreetmap.org/wiki/Wiki#Wikiteam
>
Have you perchance seen the long and multiple discussions about
noexit=yes and similar subjects?
Yes, this place is exactly the one where to discuss that *tagging*
errors are made, what the wiki actually means, that it may be
misunderstood and that it should be clarified.

In this caseit seems clear to me that cycleway
<https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite* defines a
cycleway and some use it to tag a oneway exception.
And that oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no is the
access tag defining the oneway exception, that it is sometimes omitted
and that like misusing any access tag it produces routing (GPS) errors.
Some uncommented people openly laugh at OSM routing globally; in
contrast, I say "change this if you want better routing" and I'm the one
being criticized.
The horror comes when someone said that a wiki article (he didn't show
which) deprecates oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no and when the
very attractive map http://mijndev.openstreetmap.nl/%7Eligfietser/fiets/
introduces confusion.
I have no time to make corrections and improvements to every wiki topics
that need it and I hope that the persons who wrote them or acquaintances
will listen and do it.

For example, if I understood well, I'd recommend this or better:
cycleway
<https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite*indicates
the presence of a sort of cycleway called "cycle plug",  a very narrow
part of aoneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no way that
runs alongside it for cyclists to ride contraflow on.
Just that and not a long explanation of contraflow, making believe that
it's the subject, with a seemingly casual mention of "cycle plug" in the
end where one may have stopped reading. And oneway:bicycle
<https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no is not
"normally" tagged with it but is the fundamental reason for choosing the
value "opposite" and hence mandatory.
And I suggest replacing other possible explanations of that subject
scattered in the wiki with a pointer to the one and only.

OSM and I thank you for your attention,
Cheers,

André.


> Unless some always ask for a proposal to edit /amend anything in the wiki.
> IMHO this leads to the result you mentioned :
> "Unfortunately, I'm very sorry to say, OSM is often much of a chaos."
> There seem to be very few people which first like to request a request
> form
> to be able to help the community to improve *.
>
> A "code of conduct"** would be helpful in which cases
> you may just add a minor specification, unfortunately I couldn't find
> such up to now.
>
> Cheers,
> Thilo
>
> * For those who don't know the concept of sarcasm :
> https://en.wikipedia.org/wiki/Sarcasm
>
> ** Certainly this will also leave some (border) cases which are
> disputable,
> but at least there would be SOME agreed guideline.
> https://en.wikipedia.org/wiki/Code_of_conduct
>
> Am 10.05.2017 um 15:10 schrieb André Pirard:
>> Hi,
>>
>> In this thread, I said, in agreement with others,
>> that oneway:bicycle
>> <https://wiki.openstreetmap.org/wiki/Key:oneway:bicycle>=no (click to
>> open that page) is the tag to be used *to tell routing
>> software**(GPS)* that *oneway*=yes
>> <https://wiki.openstreetmap.org/wiki/Key:oneway>does not apply to
>> bicycles
>> that cycleway
>> <https://wiki.openstreetmap.org/wiki/Key:cycleway>=opposite* has
>> noting to do with routing and contraflow but indicates that *there is
>> a cycleway* that *happens* to be "opposite".
>>
>> Could you please make the wiki documentation more clear about that?
>> Because mappers often believe that cycleway=opposite means to
>> indicate bicycle contraflow oneway:bicycle=no.
>> Unfortunately, sometimes contradictory sentences about the same
>> concept are often spread all over the wiki.
>> Find them all!
>>
>> I have written this script
>> <http://overpass-turbo.eu/?Q=%0A%5Bout%3Ajson%5D%5Btimeout%3A60%5D%3B%0A%2F%2F%20gather%20results%0A%28%0A%20%20%2F%2F%20query%20%0A%20way%5B%21%22oneway%3Abicycle%22%5D%5Bcycleway%7E%22opposite%22%5D%28%7B%7Bbbox%7D%7D%29%3B%0A%20%20%0A%29%3B%0A%2F%2F%20print%20results%0Aou

Re: [OSM-talk-be] Missing oneway:bicycle=no

[André Pirard]

Hi,

In this thread, I said, in agreement with others,
that oneway:bicycle
=no (click to
open that page) is the tag to be used *to tell routing software**(GPS)*
that *oneway*=yes does
not apply to bicycles
that cycleway
=opposite* has noting
to do with routing and contraflow but indicates that *there is a
cycleway* that *happens* to be "opposite".

Could you please make the wiki documentation more clear about that?
Because mappers often believe that cycleway=oppositemeans to indicate
bicycle contraflow oneway:bicycle=no.
Unfortunately, sometimes contradictory sentences about the same concept
are often spread all over the wiki.
Find them all!

I have written this script

to find where many cycleway=opposite* exist without oneway:bicycle=no
and even without oneway=yes.

Look at this street  to
which GRi added cycleway=opposite without oneway:bicycle=no, to which
JanFi added oneway:bicycle=no  probably after reading this thread (thank
you!) and from which I removed cycleway=opposite because there is no
cycleway at all.

The worst of all is that the map
http://mijndev.openstreetmap.nl/%7Eligfietser/fiets/ shows
"cycleway=opposite or oneway:bicycle=no" ways, hence neither identifying
the cycleways  nor the contraflow correctly and not testing in its bugs
tag that cycleway=opposite must contain oneway:bicycle=no.
That is pitiful complete misinformation and the author did not even
reply to my message.

Unfortunately, I'm very sorry to say, OSM is often much of a chaos.

Hoping this will help,
Cheers

André.



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

Re: [OSM-talk-be] YES, we can trace the PICC (was: Using SPW PICC layer in josm)

[André Pirard]

ing, OSM vigilantes threaten with exclusions
their mates who would trace it.

While helping someone with routing problems I mentioned the Michelin map.
I had just imagined that an OSM route could be compared to Michelin's.
Someone came down on me, suspecting me to trace Michelin.
I had just come across ViaMichelin and that map is so coarse that it
would be stupid to trace it.
He threatened to exclude me from OSM and to remove my contributions.
That's removing a good part of the Walloon borders and all a jazz !!!
For not being reported, I had to swear that I never did such a silly
thing and that I never will.
Out of curiosity I contacted Michelin.
I asked them in excellent French if OSM can compare its routes with theirs.
They very kindly replied that the copyright mention is at the bottom
left of their maps.
Including when their "Type de carte" is OSM background.
She did not reply what file contains the copyright text.
And certainly not to my question.
Exactly what I say here above: "a too limited explanation of their ©".

I made an overpass turbo script showing OSM with the Michelin's colors.
I won't show it because the vigilantes would accuse me to copy
Michelin's colors.
While doing so, I noticed that the main axis Ans-Amercœur wasn't fully
Michelin's colors.
So, this could produce suboptimal routes.
This is because a few N3 streets are tagged highway=secondary instead of
=primary.
I certainly did not correct that because the vigilantes would say that
it is copying Michelin.

> On 01-03-16 21:48, Erik B wrote:
>> Hello,
>>
>> I understand that there is no clear agreement to use PICC for OSM but it
>> is said and written by different persons from the government that there
>> is nothing against the use of those data for OSM and that we don't risk
>> that data have to be deleted in the future.
>> It means that besides SPW aerial imagery also the data on the PICC map
>> may be used. Does this include the dimensions of the buildings, the
>> house numbers, the names of the streets and the names of rivers, woods,
>> farms and so on?
>>
>> Erik
>>
>> Op 29-02-16 om 17:38 schreef Julien Fastré:
>>> Bonjour,
>>>
>>> On n'est jamais parvenu à obtenir une réponse claire de la part du
>>> SPW. Mais je confirme ce qu'écrit André Pirard: pour eux, recopier nos
>>> données n'est pas les utiliser 
autrement dit, "tracer" et utiliser la trace à sa guise est parfaitement
licite.
>>> => donc on pourrait tracer à partir du
>>> PICC comme on le fait à partir de Bing!, selon eux. Le mieux (ou le
>>> pire) c'est qu'ils ont rédigé leur nouvelle licence en partie pour
>>> permettre à OSM d'utiliser ces données (il y a eu vraiment un travail
>>> de ce côté), mais qu'elle reste floue pour qu'on le fasse.
Les Conditions sur le site sont indubitables, mais uniquement pour ceux
qui ont déjà compris ce que nous disons.
Il reste que la référence au fichier de Conditions de traçage manque. Je
l'ai signalé mais rien n'a changé.
Peut-être que si une dizaine de contributeurs faisaient de même, ça se
remarquerait.
L'Union fait la Force, n'est-ce pas.
>>> Maintenant, s'ils se plaignent, je n'ai que des conversations
>>> téléphoniques, des réunions et des échanges de courriels pour défendre
>>> la personne qui serait mise en cause.
Maintenant, nous avons "mon" texte officiel.
>>> En Wallonie, on reste dans le domaine du compromis...
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
On 2016-02-26 17:37, lionel bulpa wrote:
> Bonjour,
>
> Pour être honnête, je l'utilise déjà, je ne contribue que de temps en
> temps et mes contributions sont basé sur PICC. Je ne connais pas bien
> les licences etc mais je supposais que si le fond de carte était
> proposé dans JOSM, cela signifiait que nous pouvions l'utiliser.
Pour info, voici >6 ans que Merkaartor présente le PICC dans ses
serveurs pré-configurés et que personne ne dit rien.
Sauf moi que les logiciels devraient afficher les conditions
d’utilisation qu'il trouverait dans les méta-données du serveur.
Et des méta-données disent par leurs absences qu'il n'y a pas de
restriction.
Et l'auteur dit qu'elles sont absentes parce que personne ne les lit.
Et l'auteur du logiciel dit qu'il n'est pas nécessaire d'afficher ce
qu'on ne trouve pas.
Et personne ne sait qui est la poule et l'œuf
Tout le monde est d'avis que cette information doit être diffusée au hasard.
Mais que c'est très très très important.
> Si ce n'est pas le cas, merci de m'en informer 
>
> Lio :)
Voir ci-dessus ...

On 2016-02-28 10:53, lionel bulpa wrote:
> J'ai lu vos réponses mais je n'ai pas réussi à en tirer une conclusion
> claire (je dois traduire le texte :P ) Pouvons-nous utiliser les
> données PICC?
Oui.  C'est ce que disent ses auteurs.
J'essaye ci-dessus de l'expliquer aux incroyants.
Pour traduire: S3.Google.Translator : excellent


On 2016-02-28 11:28, Jo wrote:
> Non
>
> So, unless someone claims i'm wrong, we should not use this at all, if
> you do... and a claim is made, that data will be removed from OSM by
> analysing the user names involved and their changesets.
>
> Il ne faut surtout pas l'utiliser. Tu risques d'avoir toutes tes
> contributions relatées expulsées de la base de données OSM.
>
> Polyglot

Encore une menace non fondée, sans investigation.

Encore bonjour,
Cordialement,

André.




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

Re: [OSM-talk-be] New traffic sign for bicycle

[André Pirard]

On 2017-03-26 18:10, André Pirard wrote:
> On 2017-03-25 17:49, Marc Gemis wrote:
>> the problem with a subtag is that you cannot use it in combination
>> with oneway. Now you can map it as oneway:moped_A/B/P = yes
> Yes we can, as: :moped:A=yes
I meant  oneway:moped:A=yes  of course.
> When using namespace <http://wiki.openstreetmap.org/wiki/Namespace>,
> ":A" means a qualifier of what is before it, "moped", meaning which
> part of the mopeds we are talking about: "a moped of class A". And
> "moped:A" applies to "oneway", which part of the vehicles one-way is for.
> Unfortunately, as often with OSM docs, that article isn't very clear
> that namespace can be multilevel and in what order.
> The worst of it is that some contributors don't like namespace and
> scold those who speak about it, saying "we don't do like that" (who is
> "we"?).
>
> Cheers
>
> André.
>
>
>> On Tue, Mar 21, 2017 at 8:47 AM, Santens Seppe  
>> wrote:
>>> Am I correct moped_A and moped_B are only used in Belgium? Can we have a 
>>> moped_P? Or would it be better to review the moped tag and make it 
>>> something like moped=yes + moped:A=yes + moped:P=yes?
>>> (by the way, a lot of new class A + P exception signs will be introduced in 
>>> the city of Ghent on 03/04/2017)
>>>
>>> Seppe
>>>
>>>
>>> -Oorspronkelijk bericht-
>>> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
>>> Verzonden: vrijdag 17 maart 2017 14:36
>>> Aan: Jakka; OpenStreetMap Belgium
>>> Onderwerp: Re: [OSM-talk-be] New traffic sign for bicycle
>>>
>>> How do we map the "P" category ? We already have moped_A and moped_B.
>>>
>>> m
>>>
>>> 2017-03-17 12:53 GMT+01:00 Jakka :
>>>> Nouveaux panneaux de signalisation pour les deux-roues
>>>> http://www.code-de-la-route.be/textes-legaux/sections/ar/code-de-la-route/248-art65
>>>>
>>>> Nieuwe verkeers- onderborden voor tweewielers onder de aandacht brengen.
>>>> http://wegcode.be/wetteksten/secties/kb/wegcode/248-art65
>>>>
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] New traffic sign for bicycle

[André Pirard]

On 2017-03-25 17:49, Marc Gemis wrote:
> the problem with a subtag is that you cannot use it in combination
> with oneway. Now you can map it as oneway:moped_A/B/P = yes
Yes we can, as: :moped:A=yes
When using namespace ,
":A" means a qualifier of what is before it, "moped", meaning which part
of the mopeds we are talking about "a moped of class A". And "moped:A"
applies to "oneway", which part of the vehicles one-way is for.
Unfortunately, as often with OSM docs, that article isn't very clear
that namespace can be multilevel and in what order.
The worst of it is that some contributors don't like namespace and scold
those who speak about it, saying "we don't do like that" (who is "we"?).

Cheers

André.






>
> On Tue, Mar 21, 2017 at 8:47 AM, Santens Seppe  
> wrote:
>> Am I correct moped_A and moped_B are only used in Belgium? Can we have a 
>> moped_P? Or would it be better to review the moped tag and make it something 
>> like moped=yes + moped:A=yes + moped:P=yes?
>> (by the way, a lot of new class A + P exception signs will be introduced in 
>> the city of Ghent on 03/04/2017)
>>
>> Seppe
>>
>>
>> -Oorspronkelijk bericht-
>> Van: Marc Gemis [mailto:marc.ge...@gmail.com]
>> Verzonden: vrijdag 17 maart 2017 14:36
>> Aan: Jakka; OpenStreetMap Belgium
>> Onderwerp: Re: [OSM-talk-be] New traffic sign for bicycle
>>
>> How do we map the "P" category ? We already have moped_A and moped_B.
>>
>> m
>>
>> 2017-03-17 12:53 GMT+01:00 Jakka :
>>> Nouveaux panneaux de signalisation pour les deux-roues
>>> http://www.code-de-la-route.be/textes-legaux/sections/ar/code-de-la-route/248-art65
>>>
>>> Nieuwe verkeers- onderborden voor tweewielers onder de aandacht brengen.
>>> http://wegcode.be/wetteksten/secties/kb/wegcode/248-art65
>>>

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

[OSM-talk-be] Missing oneway:bicycle=no

[André Pirard]

  
  
I once read that routes of cyclists using OSM were laughed at by the
others...

oneway=yes is a routing
tag (used by GSM) indicating that only one way of the highway can be
used.
That page says that the exception for bicycles to run contraflow is
oneway:bicycle=no.
And that cycleway=opposite* is added
for compatibility.
Also, Key:cycleway says that oneway:bicycle=no.
must be used with cycleway=opposite.

All in all it makes much sense that only one oneway:bicycle=no
  routing tag be used to allow bicycle contraflow.
And that other tags like cycleway=* are not routing tags to be used
by routing software (GSM).
They are just tags giving more detail about how the bicycles run.
Why would a multitude of duplicating routing tags like detour:bicycle=yes
or shortcut:bicycle=yes be used Indeed?

Unfortunately, while writing an overpass script I noticed that many
cycleway=opposite* exist without oneway:bicycle=no and even
without _oneway_=yes.
Please
  run this script to find some of them.
I'm not going to give the nonOSM people I work with overly
complicated instructions.  I'm not going to make a complicated
script. To write it "for the errors".

Could we please correct those mistakes?

Cheers



  

  André.

  


  


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

[OSM-talk-be] OSM updates by cyclists

[André Pirard]

Hi,

I'm presently helping cyclists to draw an overpass map used to request
their Administration Communale to add "oneway:bicycle=no"  signs.
Doing that, the discovery is (pardon me Julien Fastré) that oneway=yes
tags are horribly missing.
And hence, if cyclists care so much about oneway, we could ask them to
give us a hand and map them.
Unfortunately, those cyclists fear much to be less able to use their
hands than their legs. ;-)

My question is: what would be the simplest way/site with which those
people could add oneway=yes/-1, oneway:bicycle=no and cycleway=*.
Unfortunately, instead of allowing to uses OVERLAYs, my idea to which
nobody replied, OSM is mad of splitting, splitting and splitting, with
doesn't make the above just adding tags.  (They are even fond of making
unnecessary layer=* changes to needlessly split even more).

I've come across MapContrib but it's one of the so many pages landing
you on a graphic page without exactly saying what it does.  Looking
behind the scene, I started reading things like
> Thanks to the work of Florian Lainez on the new initiative called
> Trilib’ in the city of Paris, geolocated in OpenStreetMap and captured
> in Mapillary
But finally the definition
> MapContrib is a web application for thematic contributions to
> OpenStreetMap
Cyclism being a theme and contributions what we want to do, MapContrib
is exactly what we need, isn't it?

Or is it not and there is better?

Cheers

André.



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

Re: [OSM-talk-be] wallonia - picc - import - buildings

[André Pirard]

  
  
On 2017-02-06 12:08, Ben Abelshausen
  wrote:


  
Hi Pierre,
  

We have been discussing this recently because of what's planned
in Flanders but we need to be sure about the license. We need
someone to go after this and get them to release this data using
a license compatible with OSM... or second best, have a letter
confirming they are releasing the data to OSM but in essence
that's the same thing.

We haven't done this because it would be better to have someone
from Wallonia to pursue this so I'm not sure about the status or
if someone is still working on this.
  

I am going to write an elaborated message about PICC as soon as I
have time.

Cheers 


  

  André.

  



  

  

  Met vriendelijke groeten,
Best regards,

Ben Abelshausen

  
  
  On Mon, Feb 6, 2017 at 11:19 AM,
Pierre Parmentier 
wrote:

  
What
  about the possibilities to import the buildings (and
  other data) from the PIC to OSM?


Any
  further developments?


Any
  additional details for the page https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources#G.C3.A9oportail_de_la_Wallonie?


Pierre

  P.
  
  

  

  


  


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

Re: [OSM-talk-be] JOSM pour tracer les bâtiments

[André Pirard]

  
  
On 2016-10-24 17:26, Sus Verhoeven
  wrote:


  

  2016-10-24 0:55 GMT+02:00 André
Pirard <a.pirard.pa...@gmail.com>:

  
On
  2016-10-23 20:54, Guy Vanvuchelen wrote:


  Voor het tekenen van gebouwen
gebruik ik het “Gebouwen tekenen (B)”. Bij dit
gereedschap kan je met “X” een lijn tussen twee
punten verplaatsen.
  De laatste tijd lukte dat niet
meer goed. De lijn werd soms schuin, en niet
loodrecht, verplaatst en zelf in ‘sprongen’ zodat
nauwkeurig tekenen niet gemakkelijk of zelfs
onmogelijk was. Ik ben wat gaan testen in de
voorkeuren en merkte dat het  probleem opgelost is
als ik de “Kaartprojectie” die ingesteld was op
EPSG4326 wijzigde in EPSG3857.  Van die
kaartprojectie snap ik niet veel en ik vraag me af
of ik die zomaar mag veranderen. 

La manière certainement la plus simple de cartographier
les bâtiments est le plugin Area Selection.
En un seul clic, il détermine et trace le pourtour du
bâtiment et il met les tags en incrémentant le n° de
maison.
On peut donc remplir une rue très rapidement en faisant
un clic par maison.
C'est tout à fait fantastique.
Mais rien n'est parfait, il faut parfois faire des
retouches, surtout de maisons connexes.
Et, pis que cela,  la dernière version de AS ne
fonctionne plus, du moins avec le PICC (essayer en AU).
Il va encore falloir que je me dévoue pour introduire un
bug.
C'était tout à fait fantastique.
Quelqu'un sait-il comment on trouve les anciennes
version des plugins?
C'est moi qui ai demandé qu'on les garde pour JOSM.

C'est désolant de pouvoir ainsi placer des maison aussi
facilement à 20 cm de précision et de rencontrer des
maisons qui se trouvent à 3-5m de leur endroit réel, et
sans tags? Que faut-il faire quand il faut 50 fois plus
de temps pour corriger que pour effacer et faire un
clic?

À mois qu'il n'y ait une raison d'utiliser EPSG4326, il
faut utiliser EPSG3857.
EPSG4326 introduit une légère erreur de positionnement.

Cordialement, 


  

  André.

  

  


  
Cet Areaselector plug-in  me semblait trés
  prometteur mais avec les images de AGIV il ne
  fonctione pas non plus..

Dommage. Vivement qu'on le remette en état.

  
  Avec regret.
  
  
  
  Sus 



  

  

I have submitted https://github.com/JOSM/areaselector/issues/25

Since an unknown time, Area Selector no longer works. It draws 4
ways at the border of the window.
Neither with BE SPW PICC, nor with BE AGIV I was told, and not even
as I can see with AT basemat.at which is your testbed I think.
I don't think the problem occurred with an AS update but rather with
a JOSM one.
I ran josm-snapshot-10693.jar and AS did run, but very badly again.
It does not draws its ways onto the building walls but around them.
However, that shows better some interested friends what they will
have when it will run superbly again.
TIA for fixing this !!!

I hope this will get you a better idea of Area Selector.
Tell us if you found a correctly working version, or better the last
one after which it broke.

Cheers



  

  André.

  



  


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

Re: [OSM-talk-be] JOSM pour tracer les bâtiments

[André Pirard]

  
  
On 2016-10-23 20:54, Guy Vanvuchelen
  wrote:


  Voor het tekenen van gebouwen gebruik ik het
“Gebouwen tekenen (B)”. Bij dit gereedschap kan je met “X” een
lijn tussen twee punten verplaatsen.
  De laatste tijd lukte dat niet meer goed. De
lijn werd soms schuin, en niet loodrecht, verplaatst en zelf in
‘sprongen’ zodat nauwkeurig tekenen niet gemakkelijk of zelfs
onmogelijk was. Ik ben wat gaan testen in de voorkeuren en
merkte dat het  probleem opgelost is als ik de “Kaartprojectie”
die ingesteld was op EPSG4326 wijzigde in EPSG3857.  Van die
kaartprojectie snap ik niet veel en ik vraag me af of ik die
zomaar mag veranderen. 

La manière certainement la plus simple de cartographier les
bâtiments est le plugin Area Selection.
En un seul clic, il détermine et trace le pourtour du bâtiment et il
met les tags en incrémentant le n° de maison.
On peut donc remplir une rue très rapidement en faisant un clic par
maison.
C'est tout à fait fantastique.
Mais rien n'est parfait, il faut parfois faire des retouches,
surtout de maisons connexes.
Et, pis que cela,  la dernière version de AS ne fonctionne plus, du
moins avec le PICC (essayer en AU).
Il va encore falloir que je me dévoue pour introduire un bug.
C'était tout à fait fantastique.
Quelqu'un sait-il comment on trouve les anciennes version des
plugins?
C'est moi qui ai demandé qu'on les garde pour JOSM.

C'est désolant de pouvoir ainsi placer des maison aussi facilement à
20 cm de précision et de rencontrer des maisons qui se trouvent à
3-5m de leur endroit réel, et sans tags? Que faut-il faire quand il
faut 50 fois plus de temps pour corriger que pour effacer et faire
un clic?

À mois qu'il n'y ait une raison d'utiliser EPSG4326, il faut
utiliser EPSG3857.
EPSG4326 introduit une légère erreur de positionnement.

Cordialement,



  

  André.

  



  


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

Re: [OSM-talk-be] Update BENELUX preset (Marc Gemis)

[André Pirard]

On 2016-10-22 21:45, Marc Gemis wrote:
> Waar is die stateofrepair tag gedocumenteerd ?
> Er zijn er 153 van gemapped, bijna allemaal in Belgie.
> Wat zijn de mogelijke waarden ?
>
> Capacity is toegevoegd voor fietsparkings
Moi j'aimerais un tag *officiel* pour les
Repair Cafés  (for here
).
J'en ai parlé sans beaucoup d'écho lors d'une discussion qui a donné
amenity=bicycle repair station

mais rien pour les Repair Cafés  où on
répare tout (sauf les sous-marins, ma dernière: l'épilateur électrique
d'une espagnole).

Cheers

André.



>
> m
>
> 2016-10-22 21:10 GMT+02:00 Philippe Casteleyn :
>> Kan ik die  Benelux presets aanpassen ?
>>
>>
>> Een amenity=bicycle_parking heet een tag capacity nodig.
>>
>> Een amenity=drinking_water heeft een stateorepair nodig.
>>
>>
>> Is er niemand bezig met de defibrillatoren ?
>>
>>
>>
>>
>> 
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Bounderies Bruxelles Brussel

[André Pirard]

On 2016-10-07 20:07, Jakka wrote:
> Someone very good in bouderies...
> There is a note ..
> "Les limites de Laeken ne sont pas correctes, Tour et Taxis fait
> partie de Laeken"
> http://www.openstreetmap.org/note/740606#map=17/50.88637/4.34646
J'ai revu un jour, et de manière assez précise je crois, comme c'est mon
habitude, toutes les frontières des communes de Bruxelles (elles n'en
faisaient pas le tour et, entre autres fantaisies, elles étaient
traversées par des passages pour piétions).

Mais, avant d'aller plus loin, cette note est incompréhensible, comme
souvent.
Ne serait-ce pas une bonne idée de mettre ce marqueur sur le point qui
n'est pas dans la commune de Laeken et qui est prétendu devoir y être,
sur ce Tour et Taxi? Il est en fait au beau milieu de Laeken.
Je pourrais alors jeter un coup d’œil, mais pas tout de suite car j'ai
des soucis urgents.

Cheers

André.



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

Re: [OSM-talk-be] [Tagging] mapping default values?

[André Pirard]

On 2016-10-05 11:00, Martin Koppenhoefer wrote:
>
> 2016-10-05 3:35 GMT+02:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> On 2016-09-27 11:43, Marc Gemis wrote:
>> Hallo,
>>
>> op 1/1/2017 daalt de snelheid op Vlaamse gewestwegen van 90 naar 70.
>> Normaal gezien zullen we die wegen (zonder expliciete borden) dan
>> moeten taggen met
>>
>> maxspeed=70
>> source:maxspeed=??:rural
>>
>> maar wat komt er op de plaats van de vraagtekens ? Volgens [1] staat
>> daar de landcode, maar het geldt enkel voor Vlaanderen.
>> Ik zou tegen dan de BENELUX presets willen aanpassen.
>>
>> -
>> English:
>>
>> On 1/1/2017 the maxspeeds on Flemish roads is lowered to 70. We should
>> map those roads (without signs) with
>>
>> maxspeed=70
>> source:maxpseed=??:rural
>>
>> Which "country" code should I use in the BENELUX plugin ? See [1] for
>> the syntax of maxspeed.
> I don't think that default values like maxspeed=*, 
> driving_side=*, or even oneway=no should be tagged on highways.
> Most roads (in Belgium and in the world) don't contain any, BTW,
> and it makes no sense using a few.
> A default values specification should be used instead.
> Those tags should be contained in the highest level administrative
> boundary relation or equivalent in which they apply.
> maxspeed=70 should apply to Flanders and maxspeed=90 to Wallonia.
>
>
> what you propose is not working, because speed limits are about roads,
> not administrative entities. You have to know the context (rural/urban
> inside settlement according to traffic law, etc.) in order to assign a
> maxspeed, and the only way we currently use to understand which
> context applies are the source:maxspeed values. It is very simple,
> doesn't require preprocessing, can be applied by everyone without
> looking for and downloading surrounding administrative polygons, and
> is also quite reliable. Why would we give this up?
Please don't remove important quotations.

What you are saying is that every road in the world should have a
maxspeed=*. driving_side=*, etc.
It's far from being the case.  Hurry up to do so.  Presently, GPSes
cannot deal with defaults.
What I am saying is that there should be in the Walloon/Flemish
administrative boundaries relations or so a tag saying
if zone is rural then maxspeed=90/70.
That is what "def:highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=primary
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dprimary>|highway
<https://wiki.openstreetmap.org/wiki/Key:highway>=secondary
<https://wiki.openstreetmap.org/wiki/Tag:highway%3Dsecondary>;maxspeed
<https://wiki.openstreetmap.org/wiki/Maxspeed> = rural" does in
Relations/Proposed/Defaults
<https://wiki.openstreetmap.org/wiki/Relations/Proposed/Defaults>.
Instead of destroying propositions again please propose improvements.
I think that this proposition is sound but I don' agree with the too
complicated details of it.
Yes, default speed limit rules are about administrative entities for
someone who understands what Flemish and Walloon mean.
No, GPS dealing with administrative polygons is not complicated as they
keep saying on and on.
It would even be simple with subareas but that's another subject.
No tagging default maxspeed everywhere is not reliable because it
depends on many tags being correct instead of a few.
As to using signals, that's the worst idea.  They are valid up to the
next crossing, but not a private road, and they must be repeated.
Indicating which direction they apply to is tricky and a source of
error. The few  signals I looked at were municipality limits. They were
redundant with boundaries (a disparaged feature) and they did not mind
indicating on which side of the signal was the indicated municipality.
Imagine that with speed limits and you get the picture.

Cheers

André.



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

Re: [OSM-talk-be] mapping default values? (was: Maximum snelheid in Vlaanderen, maxspeed in Flanders)

[André Pirard]

On 2016-09-27 11:43, Marc Gemis wrote:
> Hallo,
>
> op 1/1/2017 daalt de snelheid op Vlaamse gewestwegen van 90 naar 70.
> Normaal gezien zullen we die wegen (zonder expliciete borden) dan
> moeten taggen met
>
> maxspeed=70
> source:maxspeed=??:rural
>
> maar wat komt er op de plaats van de vraagtekens ? Volgens [1] staat
> daar de landcode, maar het geldt enkel voor Vlaanderen.
> Ik zou tegen dan de BENELUX presets willen aanpassen.
>
> -
> English:
>
> On 1/1/2017 the maxspeeds on Flemish roads is lowered to 70. We should
> map those roads (without signs) with
>
> maxspeed=70
> source:maxpseed=??:rural
>
> Which "country" code should I use in the BENELUX plugin ? See [1] for
> the syntax of maxspeed.
Note to "foreigners" (as Americans would call you):
Belgium is made of Flanders and Wallonia: Flanders steps down to 70 km/h
default while Wallonia stays at 90.

I don't think that default values like maxspeed=*,  driving_side=*, or
even oneway=no should be tagged on highways.
Most roads (in Belgium and in the world) don't contain any, BTW, and it
makes no sense using a few.
A default values specification should be used instead.
Those tags should be contained in the highest level administrative
boundary relation or equivalent in which they apply.
maxspeed=70 should apply to Flanders and maxspeed=90 to Wallonia.
Please note this (fuzzy again) sentence about driving_side=* : "Only add
it to a highway when it's driving side is an exception to the general
rule (and check that the general rule is tagged in your country
relation)." (they mean "its" driving side).
Which relation?  It's certainly not tagged in the Belgian boundary
 and not even in the
duplicate place .
So, a default value procedure is badly needed but is not implemented and
when a hacked fuzzy lookalike is documented, it is not used.

Cheers

André.


> regards
>
> m
>
>
> p.s. Ruben, please let me know which preset you want for variable
> maxspeeds. I'll add it when I change the above.
>
>
> [1] https://wiki.openstreetmap.org/wiki/Key:source:maxspeed
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Another Nominatim fact

[André Pirard]

On 2016-09-29 08:58, joost schouppe wrote:
> Well, I was the only one thinking that about your previous mail :)
> But André is probably right: it is a strange idea to define just one
> language for a nation. I wouldn't be surprised if half the people on
> this planet live in countries with more than one official language.
> Official languages tend to follow admin boundaries, so I don't see the
> point of boundary=linguistic. But you might feed a tool like Nominatim
> with an official language tag at different admin_levels.
The point is that in Belgium, the official languages (communities) are
delimited by boundary=political boundaries in addition to the
boundary=administrative ones.
Adding tags to the administrative kind to indicate the same thing as the
political kind seems weird.
The fact is that the /political/ kind was chosen for no particular
reason (1), just because the name exists.  I wonder if it's used for
languages anywhere else than in Belgium. And hence, very few people
understand it, even on this list.
And Nominatim certainly does not.
Replacing boundary=political with boundary=linguistic would suddenly
make the issue clear for everybody.
It's like making separate boundaries for national parks and that does
not assume that they follow administrative ones (everywhere in the world).

Cheers

André.


(1) as often the case, OSM does not clearly define its words: what
"political" means, except "areas, mostly political", the opposite of
actual tagging and "electoral (?)".
> Might also help with interpreting special naming styles, like in
> Brussels. So you could have something like official_language="see
> admin level 4" for Belgium, and official_language=fr;nl for Brussels.
> Mapped this way, it might help a tool understand that you can't know
> the language of a name in Belgium by just looking at the country
> outline, and that in Brussels you have to look out for bilingual names. 
>
> As we're talking Nominatim special cases: makes me think of Philippe's
> long irritation that all addresses in central Brussels being returned
> as in the Marollen. This is because there are only thee neighborhoods
> mapped in Brussels.
>
> Proposed solution: the statistical sectors of Belgium are now open
> data. We could map the centroids of those as neighborhood nodes.
> Statistical sectors of course don't always reflect what we would call
> neighborhoods (especially in the countryside, or in industrial areas
> etc). But in city centers they do tend to reflect what might be used
> locally.
> (I don't consider this a huge problem myself, so won't work on it myself)
>
> 2016-09-29 6:47 GMT+02:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> That is exactly what I explained several times before (Nominatim's
> behavior, not that feature).
> I put it that what that feature does is: if name:ll=* is missing
> produce an implicit one with the same value as name=*.
> This means (assuming that name=* always exists), that a browser
> configured with ll as one of its primary languages will always
> find a name in language ll in a region where that language is
> primarily spoken and is Nominatim's such "default".
> Now, what you say about Flemish nl s also true for Walloon fr and
> our eastern quiet and gentle friends' de.
> So that if Nominatim is defining a language default "by country"
> as you say, they really missed something.
> They missed Belgium, they missed Switzerland, they missed Wales,
> they missed the Spanish speaking South USA etc.
>
> I have long thought of proposing a boundary=linguistic that would
> be used, typically for the Belgian regions, in parallel with the
> administrative ones and that would obviously be where Nominatim
> should pick that "default" language.
> But I have also long abandoned the idea of feeding OSM with well
> thought out suggestions because, instead of trying to understand
> my goals and possibly suggesting alternatives, my fellow
> contributors answer that this is not the way "we" do it, or other
> denials, or that I'm out of topic or even that I'm accusing people
> to "do bad job".
>
> Let it be, as the Beatles said.
> Cheers
>
> André.
>
>
> On 2016-09-29 05:20, Marc Gemis wrote:
>> Here's another fact about Nominatim that I learned after a private
>> conversation with Sarah.
>>
>> Nominatim has the possibility to install a default language for a
>> country. This is not done for Belgium, but can be done for The
>> Netherlands. Ri

Re: [OSM-talk-be] Another Nominatim fact

[André Pirard]

Hi,

That is exactly what I explained several times before (Nominatim's
behavior, not that feature).
I put it that what that feature does is: if name:ll=* is missing produce
an implicit one with the same value as name=*.
This means (assuming that name=* always exists), that a browser
configured with ll as one of its primary languages will always find a
name in language ll in a region where that language is primarily spoken
and is Nominatim's such "default".
Now, what you say about Flemish nl s also true for Walloon fr and our
eastern quiet and gentle friends' de.
So that if Nominatim is defining a language default "by country" as you
say, they really missed something.
They missed Belgium, they missed Switzerland, they missed Wales, they
missed the Spanish speaking South USA etc.

I have long thought of proposing a boundary=linguistic that would be
used, typically for the Belgian regions, in parallel with the
administrative ones and that would obviously be where Nominatim should
pick that "default" language.
But I have also long abandoned the idea of feeding OSM with well thought
out suggestions because, instead of trying to understand my goals and
possibly suggesting alternatives, my fellow contributors answer that
this is not the way "we" do it, or other denials, or that I'm out of
topic or even that I'm accusing people to "do bad job".

Let it be, as the Beatles said.
Cheers

André.


On 2016-09-29 05:20, Marc Gemis wrote:
> Here's another fact about Nominatim that I learned after a private
> conversation with Sarah.
>
> Nominatim has the possibility to install a default language for a
> country. This is not done for Belgium, but can be done for The
> Netherlands. Right now, the list is not complete and The Netherlands
> is missing.
>
> What is the result ? In case you configure multiple languages in your
> browser, e.g. NL & DE, you will see DE results in case there is a
> DE-name and no explicit NL-name. This is the case for Zutphen.
>
> What will be the impact for Belgium ? Suppose a Flemish town is mapped
> as name=X and name:fr=Y . You install both NL and FR in your browser.
> A search will now return Y.
>
> This means we might have to map name:NL explicitly. I know some will
> consider this as mapping for the tool. Nominatim has no way (I asked)
> to do this on other levels than countries. So there is no possibility
> to tell it the default language for Flanders or Wallonia.
>
> Hope this explains why in some case you get unexpected results from
> Nominatim search
>
> regards
>
> m
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

[OSM-talk-be] using Michelin's road classification (was: Routing in Liège)

[André Pirard]

Hi Marc,

Could you please forward/translate this reply to Michael and anyone who
believe that Liège (and other places?) contain main road classification
errors that produce bad routing.  One-way streets and the like will be
another subject.
I suggested below to compare the OSM classification with that of Michelin.
Martin Koppenhoefer replied down below that Michael is wrong because
"we" (they) "do more or less like Michelin". But he doesn't say if it is
more or less and how much.
He asks "Where do you see differences?", meaning that he did not try to
find them.

Consequently, I have made my own Michelin compatible overpass query
<http://overpass-turbo.eu/?q=CltvdXQ6anNvbl1bdGltZcSCxIQ2MF07Ci8vIGdhdGhlciByZXN1bHRzCigKICDElyBxdcSeeSDEqiB3YXlbImhpZ2jEtnkiPSJtb3RvcsS_Il0oe3tiYm94fX0pxJXEq8S_xLnEu8S9xYnFgnByxI1hcsWAxYvFjcWPxZHFk8WVxLTFl8S3xZnEvMS-xLfFgSJzZWPEiGTFocWjxYzFjsWQxZLFlMSVxLTFmMS6xa7FnCJ0xJ7EjMW4xYrFusWmxb3FqcWrxLjGgsWbxbDFgnVuY2xhc3NpZmllZMaKxaXFvMWoxZbEtcWsxpHFr8WAxYLEocabZGVuxohsxqHFu8Wnxb7EtArFqcStxZ5pxrDEoMSixKTEpgrEkCDFkGR5xJU-xJXHg3NrZWzErnTFv8WNc3R5bGU6CsSWKkRlZmHHgCDFs3TEjG5ncyBmxYfGpnlzKi8KxL8ge8S0b3BhY2nHlTowLjXGpXdpZMScOjPGpcW1bMWHOmJsxLDGpX3HmsWYxZrGqT3FhMWGxYjEt13Hs8Wqx7bHuMe6ece8LjnIgMiCyIQ0yIdvyIlyOsShZMiPyJHFrMiTxL89xrttxbjImse0xKsgyJ3Huce7x73Io8aAyKVoOsinxLTIiMiKyK3Ir8exyLHGg8S3PcWzxbVuxbfFosi4yJzHt8i9yKDIv8ikyIPJg8mFxKvJh8ireceOyIl3yYrIksmNeT3GhnLGiMmUyJvIusi8yJ_IocmAxZfJgsmEyKjIqjrJomzJpMmmyYzGksmpxqzIgsavxrHJlcmwyZfJssmayYHJnMm3yYbIqciKZ8Shx4fEtMiQx5rHm0jFrmzFrnQgxJxlIMe4xIx2yp_HsmFmyasgxpdpY2vGvGfHr8mLyKDKoWnKo8mvxKvJsci-yKLJm8iEOMm4yYjGn8mKCsWT&c=BL83OJVENO&R>
(thanks to the author of the original) that is using the same colors as
Michelin (1).

At *very first (short) sight*, I am surprised that Martin did not spot
that the ref=N3 road that's going north-west is primary (in red) mostly
but is interrupted by secondary segments (in yellow) Rue de Hesbaye
<http://www.openstreetmap.org/way/301189193#map=17/50.64889/5.55263> and
Rue Eugène Houdret <http://www.openstreetmap.org/way/237917909>.  As
well as in Rue Louis Jamme
<http://www.openstreetmap.org/way/368855374#map=18/50.63813/5.58499> to
connect Place Delcour <http://www.openstreetmap.org/way/28611081> to
primary N90 <http://www.openstreetmap.org/way/28659889> and primary N610
<http://www.openstreetmap.org/way/368855373> (2). N610 should in theory
be secondary but I completely agree with Michelin to make it debatable
and make it primary like the Namur road should.

I did not investigate further (I'm short sighted indeed) but I suggest
that anyone contesting an OSM route compared it with the same routing by
Michelin, tried to find an explanation by comparing my overpass
<http://overpass-turbo.eu/?q=CltvdXQ6anNvbl1bdGltZcSCxIQ2MF07Ci8vIGdhdGhlciByZXN1bHRzCigKICDElyBxdcSeeSDEqiB3YXlbImhpZ2jEtnkiPSJtb3RvcsS_Il0oe3tiYm94fX0pxJXEq8S_xLnEu8S9xYnFgnByxI1hcsWAxYvFjcWPxZHFk8WVxLTFl8S3xZnEvMS-xLfFgSJzZWPEiGTFocWjxYzFjsWQxZLFlMSVxLTFmMS6xa7FnCJ0xJ7EjMW4xYrFusWmxb3FqcWrxLjGgsWbxbDFgnVuY2xhc3NpZmllZMaKxaXFvMWoxZbEtcWsxpHFr8WAxYLEocabZGVuxohsxqHFu8Wnxb7EtArFqcStxZ5pxrDEoMSixKTEpgrEkCDFkGR5xJU-xJXHg3NrZWzErnTFv8WNc3R5bGU6CsSWKkRlZmHHgCDFs3TEjG5ncyBmxYfGpnlzKi8KxL8ge8S0b3BhY2nHlTowLjXGpXdpZMScOjPGpcW1bMWHOmJsxLDGpX3HmsWYxZrGqT3FhMWGxYjEt13Hs8Wqx7bHuMe6ece8LjnIgMiCyIQ0yIdvyIlyOsShZMiPyJHFrMiTxL89xrttxbjImse0xKsgyJ3Huce7x73Io8aAyKVoOsinxLTIiMiKyK3Ir8exyLHGg8S3PcWzxbVuxbfFosi4yJzHt8i9yKDIv8ikyIPJg8mFxKvJh8ireceOyIl3yYrIksmNeT3GhnLGiMmUyJvIusi8yJ_IocmAxZfJgsmEyKjIqjrJomzJpMmmyYzGksmpxqzIgsavxrHJlcmwyZfJssmayYHJnMm3yYbIqciKZ8Shx4fEtMiQx5rHm0jFrmzFrnQgxJxlIMe4xIx2yp_HsmFmyasgxpdpY2vGvGfHr8mLyKDKoWnKo8mvxKvJsci-yKLJm8iEOMm4yYjGn8mKCsWT&c=BL83OJVENO&R>
with the Michelin map
<https://fr.viamichelin.be/web/Cartes-plans/Carte_plan-Liege-_-Liege-Belgique?>
(my "Michelin info" message helps the wise JOSM users too), and asked
people with local knowledge if they know better than Michelin.

Last point is what source:???=Michelin ??? to use to prevent a StijnRR
or like arbitrarily destructing well thought out tagging without
notifying the author. I suggest
source:highway=https://viamichelin.be/web/Cartes-plans 2016 2016.

Kéne afêre à Lîdje and I hope that this work will be useful elsewhere too,

Cheers

André.


(1) As white would not fit for residential, I used grey.  I'm surprised
indeed that no unclassified roads turn up in blue but that doesn't
affect routing.
(2) why the heck do those people adore splitting?

On 2016-09-15 17:02, André Pirard wrote:
> On 2016-09-13 18:21, Marc Gemis wrote:
>> Hallo,
>>
>> I was contacted by a mapper from Germany with whom I worked on turn:lanes.
>> He has to following question, can someone with local knowledge inform
>> us about the road classifications ? I have the impression a lot of
>> streets are indeed residential. Feel free to reply in

[OSM-talk-be] Michelin info

[André Pirard]

*Reply* to this message *privately* to receive info about how to easily
compare OSM with the Via Michelin map using JOSM.

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

[OSM-talk-be] using Michelin's road classification (was: Routing in Liège)

[André Pirard]

On 2016-09-13 18:21, Marc Gemis wrote:
> Hallo,
>
> I was contacted by a mapper from Germany with whom I worked on turn:lanes.
> He has to following question, can someone with local knowledge inform
> us about the road classifications ? I have the impression a lot of
> streets are indeed residential. Feel free to reply in French, I'll
> translate it to English for him.
>
>
> [snipped]
> Now I want ask you about another problem.
> Coming from here
> http://forum.mapfactor.com/discussion/comment/13515#Comment_13515
> I checked Liege to find out the mapping of roads there:
> http://overpass-turbo.eu/s/imn
> My guess is, that unclassified is used wrong there and that is the
> reason for strange routings. My opinion is that unclassified as the
> lowest kind of connecting roads do not end at city borders and have or
> need common connection to same or higher class inside of towns or
> villages. For me routers should avoid residentials and lower as much
> as possible. Do you have any idea to check and correct this in Liege
> to make routing better?
>
> If there are any questions, please ask.
>
> Regards
> Michael aka hurdygurdyman
In order to produce good routing using the *main* roads (1), ...
why not adopt in OSM the same classification as Michelin

(2)?
They should know something about routing, shouldn't they?

Michelin



BE ID/type
Nxx
Nxxx
other
many houses
rare houses
OSM
primary
secondary
tertiary
residential
unclassified


Inside town, the main advantage is that streets are then classified as
either secondary/tertiary or residential/unclassified
according to whether they should be used or not for routes from town
place to place.
Please note that when a street is promoted to tertiary status, the fact
that it contains houses gets disregarded
(and hence I wonder if it's a good idea to consider houses  for road
classification rather than using an additional residential attribute
(yes, I know it's the way "we" do it)).

I am willing to explain JOSM users how to compare OSM and Michelin easily.
Please send me a *private **reply* to the next message "Michelin info"
to get it.
I would do a part of Liège myself if it's organized by someone
distributing the tasks.

Cheers

André.


(1) several de-contributors claim loudly that OSM routing is an every
contributors' hoax; I tend to agree with them for routing finer than
main roads given the complexity of making a no-turn relation, the
general misunderstanding of access restriction rules ("bicycle=yes"
alone), etc.; but I hate the "we don't do it like that" answers without
any constructive remark towards my goal when I suggest improvements. 
The "dedicated" subject alone makes whole chapters just because the
"dedicated" concept is not an (already existing) access restriction but
a reason for one ("but "we" do it like that").

(2) I suppose that Michelin doesn't mind just that since they updated
OSM themselves in their 2012 experiment
.


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

Re: [OSM-talk-be] Routing in Liège

[André Pirard]

On 2016-09-14 05:52, Marc Gemis wrote:
> André, Julien,
>
> thanks for the replies. I've forwarded them to Michael and let hem
> answer your questions/remarks/concerns.
>
> My impression, based on aerial imagery, was that only a couple of
> streets might be classified incorrectly, But it hard to tell without
> knowing the area.
> As for the circles in Overpass, they are caused by very small (OSM)
> ways. There is a command that you can add to the css of Overpass to
> avoid them, but I leave it to Michael to solve.
Unfortunately,  trying to route based on administrative classification
is a lost cause.
If we were tweaking it to match usability, someone would soon come to
destroy the work.
My best example is this
.
 
National road N674 !!!
It's a winding narrow road where two lorries can hardly cross each other.
It's bordering a ravine on a great length.
One day, a lorry crumbled the side, fortunately only down a few meters
to the meadow below.
And I once skilfully dodged a van driving much too fast in the sharp bend.
No danger sign at all !!!

I once suggested that objective classification criteria were mapped to
be used for routing.
One which is important and easily mappable from aerial photos is the width.
Straightness can be calculated by the GPS based on topology.
Recommended speed is unhappily more subjective unless we find an
objective measure.
Surface quality too.
I suggested that bouncing could be measured by software using a GSM
accelerometer.

In a town, there is a mesh of major roads that cars follow to travel
inside, not across.
I mentioned boulevards d'Avroy and de la Sauvenière.
Julien mentioned them around place du Marché.
Around the Guillemins, they are avenue E.Digneffe, rue de Fragnée, rue
de Sclessin, rue des Guillemins, rue du Plan Incliné, rue d'Artois &
Fabry & Louvrex, etc.
All those streets could get routing specific tags that no one would disturb.

Cheers

André.









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

[OSM-talk-be] Help starting JOSM on Ubuntu (was; Help! Hoe kan ik deze editeren?)

[André Pirard]

On 2016-09-13 18:22, Karel Adams wrote:
> Allen,
>
> ... JOSM wil om een of andere duistere reden niet opstarten op mijn
> ubuntu-bakske.
>
Alleen,

I can try to help you or anyone start JOSM on Ubuntu if you like.
What do you do and what do you see?

Cheers

André.




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

Re: [OSM-talk-be] Routing in Liège

[André Pirard]

On 2016-09-13 18:21, Marc Gemis wrote:
> Hallo,
>
> I was contacted by a mapper from Germany with whom I worked on turn:lanes.
> He has to following question, can someone with local knowledge inform
> us about the road classifications ? I have the impression a lot of
> streets are indeed residential. Feel free to reply in French, I'll
> translate it to English for him.
Hi,

The overpass map doesn't show Liège but the North of it.
When run, I can't make sense of what I see.
Could you get rid of the nodes?

In Liège, most of the ways are residential, of course.
You can see not yet mapped buildings by displaying the BE PICC layer.
But, beside surrounding and access motorways, some ways are suitable for
slower, through traffic.
Those are brown on OSM.org and mainly: alongside Meuse and Dérivation,
rue de l'Yser to Ans, N3, N61, N30, N63, N90. (...?)
Notably missing the brown status is N671 for carrying the heavy traffic
in direction Namur.
(The rule is that brown, main National, primary roads are 1 or 2 digits,
but 671 certainly deserves that).
Beside that, there are yellow, secondary wider streets bordered by
buildings like Boulevard de la Sauvenière that can be used for faster
moving inside town but isn't recommended for traveling through.

I'm not mapping Liège and I don't know every small streets of it
everywhere, but I can comment specifics like N671 if no one else stands
up in this thread.

Cheers

André.




>
>
> [snipped]
> Now I want ask you about another problem.
> Coming from here
> http://forum.mapfactor.com/discussion/comment/13515#Comment_13515
> I checked Liege to find out the mapping of roads there:
> http://overpass-turbo.eu/s/imn
> My guess is, that unclassified is used wrong there and that is the
> reason for strange routings. My opinion is that unclassified as the
> lowest kind of connecting roads do not end at city borders and have or
> need common connection to same or higher class inside of towns or
> villages. For me routers should avoid residentials and lower as much
> as possible. Do you have any idea to check and correct this in Liege
> to make routing better?
>
> If there are any questions, please ask.
>
> Regards
> Michael aka hurdygurdyman
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] une idée pour mappé les "smart" zone 30? + hazards

[André Pirard]

On 2016-09-09 08:06, eMerzh wrote:
> Hello,
> Je suis un peu perdu de savoir comment je mapperai ça :)
>
> http://www.lalibre.be/regions/bruxelles/bruxelles-les-zones-30-deviennent-intelligentes-57d1d1223570646c923b915d
>
C'est une bonne chose que de ne plus limiter la vitesse à 30 km/h un 31
juillet à 24 h parce que c'est un abord d'école.

Ce qui me touche le plus, c'est que cette zone 30 (avec un signal
triangulaire qui en fait part) est différente d'une zone 30 "simple".
C'est une zone appelée "abord d'école" et aucun mapping de centaines de
zones 30 que j'ai vu ne l'indique.  Manifestement, quand on regarde
l'état de la proposition hazard
 vieille de
10 ans et qui contient exactement ce qu'il faut: *hazard = school_zone*,
on se dit que OSM est opposé au signalement des dangers aux utilisateurs
de GSM.  Et spécialement au danger concernant les enfants.

What I'm concerned with most is that this sort of zone 30 (with a
triangular sign being part of its sign) is different from a "plain" zone
30. It's a zone called "school neighborhood" and no mapping in
hundredths of zones 30 I saw in OSM indicates that.  Obviously, the
status of the 10 yo hazard

proposition, containing exactly the needed *hazard = school_zone*, shows
than OSM is opposed to signaling dangers to GSM users, and especially
children related dangers.

Cheers

André.




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

Re: [OSM-talk-be] overpass-api.de non disponible?

[André Pirard]

Hi,
> $ tcptraceroute overpass-api.de
> Selected device wlan0, address 192.168.69.103, port 51768 for outgoing
> packets
> Tracing the path to overpass-api.de (136.243.42.136) on TCP port 80
> (http), 30 hops max
>  1  192.168.69.1  1.419 ms  1.265 ms  1.224 ms
>  2  192.168.0.1  2.532 ms  1.914 ms  1.888 ms
>  3  129.196-4-62.adsl-dyn.isp.belgacom.be (62.4.196.129)  30.667 ms * *
>  4  ae-83-100.iarstr4.isp.belgacom.be (91.183.242.128)  29.835 ms * *
>  5  ae-13-1000.ibrstr5.isp.belgacom.be (91.183.246.112)  30.066 ms * *
>  6  ae2.bru21.ip4.gtt.net (141.136.102.217)  30.880 ms * *
>  7  et-10-1-0.fra28.ip4.gtt.net (89.149.182.146)  39.232 ms * *
>  8  hetzner-online-gw.ip4.gtt.net (77.67.76.142)  40.055 ms * *
>  9  core24.hetzner.de (213.239.229.78)  42.804 ms * *
> 10  ex9k2.rz21.hetzner.de (213.239.203.194)  43.526 ms * *
> 11  static.136.42.243.136.clients.your-server.de (136.243.42.136)
> [open]  42.081 ms * *
shows that there is no IPV4 routing or firewall problem and that the
http server is started (port open).
> $ telnet overpass-api.de http
> Trying 136.243.42.136...
> telnet: Unable to connect to remote host: Connection timed out
shows that the server is not responding to any request (even /).
It's looping or something equivalent.
> $ telnet overpass.osm.rambler.ru http
> Trying 81.19.69.32...
> Connected to worker2.osm.rambler.ru.
> Escape character is '^]'.
> byebye
> HTTP/1.1 400 Bad Request
> Server: nginx/1.6.0
> Date: Sun, 21 Aug 2016 18:28:03 GMT
> Content-Type: text/html
> Content-Length: 172
> Connection: close
>
> 
> 400 Bad Request
> 
> 400 Bad Request
> nginx/1.6.0
> 
> 
> Connection closed by foreign host.
The Russian server is replying (not necessarily correctly).

Cheers

André.


On 2016-08-21 17:17, Marc Gemis wrote:
> Philippe Verdy op de Franse mailing list:
>
> Les deux instances russe et allemande sont "down" (aussi bien en HTTP
> qu'en HTTPS). Ce n'est même pas à cause de l'usage car selon leurs
> mainteneur l'activité est faible. Il semble que ce soit un problème en
> amont sur un parefeu (maucais routage interne) ou un proxy frontal
> (problème disque?). En attendant on n'a que l'instance française qui
> fonctionne.
>
> Cela dure depuis 2 jours, mais pas d'explication sur ce qui se passe.
> Si c'est causé par un usage excessif de l'API, cela pourrait être lié
> à certains outils (quelques applis mal fichues pour mobiles, qui ne
> disposent d'aucune capacité de gestion de cache en local sur le client
> ou sur le serveur de l'appli, et qui raffraichissent trop souvent ou
> entrent en boucle)
>
> 2016-08-21 16:12 GMT+02:00 Karel Adams :
>> De titel zegt het allemaal: ik kan niet meer connecteren naar
>> overpass-api.de?
>>
>> Onderhoudswerkzaamheden, misschien? Maar dan zou er toch een "sorry"-pagina
>> opstaan, zou ik verwachten?
>>
>> wget "http://overpass-api.de/api/interpreter";
>> --2016-08-21 14:09:02--  http://overpass-api.de/api/interpreter
>> Resolving overpass-api.de (overpass-api.de)... 136.243.42.136,
>> 2a01:4f8:212:a83::2
>> Connecting to overpass-api.de (overpass-api.de)|136.243.42.136|:80...
>> failed: Connection refused.
>> Connecting to overpass-api.de (overpass-api.de)|2a01:4f8:212:a83::2|:80...
>> failed: Network is unreachable.
>>
>> (geen paniek, dit commando zal ik in normale omstandigheden niet lanceren -
>> gewoonlijk zit er een --post-file= bij in om het volume stevig in te perken
>>
>>
>> Karel
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-12 10:03, Ruben Maes wrote:
> On vrijdag 12 augustus 2016 03:58 André Pirard wrote:
>> On 2016-08-11 23:59, Ruben Maes wrote:
>>> On donderdag 11 augustus 2016 18:26 André Pirard wrote:
>>>> (...)
>>>> OSM.org displays the names according to the Language preference of the
>>>> browser (1).
>>>> Precisely, it displays a name in the first language of that preference
>>>> that matches one in the map.
>>>> Else, it displays the common default name.
>>>> E. g. if the preference is fr,ru :
>>>> if name:fr exists, display it, else if name:ru exists, display it, else
>>>> display name.
>>>> (...)
>>> I don't know where you get this, but it is completely false.
>>> For what you say to be possible, there would have to be separate tiles for 
>>> every language. That's not the case, everyone gets 
>>> https://{a,b,c}.tile.openstreetmap.org/{zoomlevel}/{}/{}.png.
>> What I said is in fact how OSM.org display names in the Nominatim search
>> left pane.
> I think that even that is not true. I see:
This is the OSM.org left pane for a search of "Houte-Si-Plou" with
language preference ru+wa.
You can see name:ru in Cyrillic if it exists, else name:wa that I put in
bold if it exists, else name=*.
>
>
> Результаты поиска
>
>
> Результаты, полученные из OpenStreetMap Nominatim
> <http://nominatim.openstreetmap.org/>
>
>  *
>
> Посёлок *Hoûte-s'i-ploût*, Льеж, Валлония, Бельгия
> <http://www.openstreetmap.org/node/259975902>
>
>  *
>
> Дорога хозяйственного назначения Chemin de Houte-Si-Plout,
> *Esneu*, Энё, Льеж, Валлония, 4130, Бельгия
> <http://www.openstreetmap.org/way/210622693>
>
>  *
>
> Watermill Moulin de Hoûte-s'i-Ploût, Chemin de Houte-Si-Plout,
> *Esneu*, Энё, Льеж, Валлония, 4130, Бельгия
> <http://www.openstreetmap.org/way/317769117>
>

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

Re: [OSM-talk-be] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-11 23:59, Ruben Maes wrote:
> On donderdag 11 augustus 2016 18:26 André Pirard wrote:
>> (...)
>> OSM.org displays the names according to the Language preference of the
>> browser (1).
>> Precisely, it displays a name in the first language of that preference
>> that matches one in the map.
>> Else, it displays the common default name.
>> E. g. if the preference is fr,ru :
>> if name:fr exists, display it, else if name:ru exists, display it, else
>> display name.
>> (...)
> I don't know where you get this, but it is completely false.
> For what you say to be possible, there would have to be separate tiles for 
> every language. That's not the case, everyone gets 
> https://{a,b,c}.tile.openstreetmap.org/{zoomlevel}/{}/{}.png.

What I said is in fact how OSM.org display names in the Nominatim search
left pane.

What Joost is asking, "a rendering of OSM in Dutch and French" ("or", I
suppose)
can be done by overlaying a nameless background and names foreground
like this example for Liège and Russian:

http://c.tile.openstreetmap.de:8002/tiles/1.0.0/bg//11/1055/688.png
http://c.tile.openstreetmap.de:8002/tiles/1.0.0/labels/ru/11/1055/688.png
http://c.tile.openstreetmap.de:8002/tiles/1.0.0/labels/ru,_/11/1055/688.png

The foreground overlay could be rendered in text mode for speed.

Cheers

André.



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

Re: [OSM-talk-be] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-09 11:37, joost schouppe wrote:
> Hi,
>
> Someone asked on Twitter about a rendering of OSM in Dutch and French
> to avoid the clutter of bilingual names in the standard rendering.
>
> https://twitter.com/iciBrussels/status/762743820358418432
>
> The French render is easy, OSM France provides it. But how about a
> Dutch rendering? Do you know of one?
>
> It might be cool to create a little webmap on OSM.be with the three
> official languages. If you help me find a Dutch rendering, I can make
> that (I've just learned the basics about leaflet).
>
> It looks rather easy to make a style with mapbox, but you need to
> extract the data through Overpass for exotic languages like Dutch, so
> it would be a bit of a job to keep that up to date.
I don't understand exactly what the problem is.
OSM.org displays the names according to the Language preference of the
browser (1).
Precisely, it displays a name in the first language of that preference
that matches one in the map.
Else, it displays the common default name.
E. g. if the preference is fr,ru :
if name:fr exists, display it, else if name:ru exists, display it, else
display name.
Hence, to reliably display Dutch, the preference must be nl,... and
name:nl must exist.
Or name=* must be in Dutch, but see gotcha.
That is a gotcha, of course.  If name=French_name has been coded and a
good soul adds mane:ru=России_имя, the fr,ru French speaker accepting
Russian will see the Russian name.  When adding name:ru=*, name:fr=*
must also be added.
This is especially strange in a region like Brussels.
The law says that the names must be written in both fr and nl.
But no Belgian sees that because their preference uses fr or nl.  Only
foreigners do.

So, what could be improved is

  * a &ln= in the OSM.org URL to force the preference and do
without (1)
  o assuming a name:ll=* tag equal to name=* where ll is the only
language of the names
  o or running a bot to add the name:ll=* names automatically

Cheers

André.


(1) or the simulation of the browser's preference as Ben noted
On 2016-08-09 16:31, Ben Laenen wrote:
> On Tuesday 09 August 2016 11:37:58 joost schouppe wrote:
>> Someone asked on Twitter about a rendering of OSM in Dutch and French
>> to avoid the clutter of bilingual names in the standard rendering. 
> How about this one: http://mlm.jochentopf.com/ Fill in "nl" or "fr" in
> the box to get the names rendered in those languages
> Ben

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

Re: [OSM-talk-be] OSM in French and Dutch [or any monolingual]

[André Pirard]

On 2016-08-09 11:37, joost schouppe wrote:
> Hi,
>
> Someone asked on Twitter about a rendering of OSM in Dutch and French
> to avoid the clutter of bilingual names in the standard rendering.
>
> https://twitter.com/iciBrussels/status/762743820358418432
>
> The French render is easy, OSM France provides it. But how about a
> Dutch rendering? Do you know of one?
>
> It might be cool to create a little webmap on OSM.be with the three
> official languages. If you help me find a Dutch rendering, I can make
> that (I've just learned the basics about leaflet).
>
> It looks rather easy to make a style with mapbox, but you need to
> extract the data through Overpass for exotic languages like Dutch, so
> it would be a bit of a job to keep that up to date.
I don't understand exactly what the problem is.
OSM.org displays the names according to the Language preference of the
browser (1).
Precisely, it displays a name in the first language of that preference
that matches one in the map.
Else, it displays the common default name.
E. g. if the preference is fr,ru :
if name:fr exists, display it, else if name:ru exists, display it, else
display name.
Hence, to reliably display Dutch, the preference must be nl,... and
name:nl must exist.
Or name=* must be in Dutch, but see gotcha.
That is a gotcha, of course.  If name=French_name has been coded and a
good soul adds mane:ru=России_имя, the fr,ru French speaker accepting
Russian will see the Russian name.  When adding name:ru=*, name:fr=*
must also be added.
This is especially strange in a region like Brussels.
The law says that the names must be written in both fr and nl.
But no Belgian sees that because their preference uses fr or nl.  Only
foreigners do.

So, what could be improved is

  * a &ln= in the OSM.org URL to force the preference and do
without (1)
  o assuming a name:ll=* tag equal to name=* where ll is the only
language of the names
  o or running a bot to add the name:ll=* names automatically

Cheers

André.


(1) or the simulation of the browser's preference as Ben noted
On 2016-08-09 16:31, Ben Laenen wrote:
> On Tuesday 09 August 2016 11:37:58 joost schouppe wrote:
>> Someone asked on Twitter about a rendering of OSM in Dutch and French
>> to avoid the clutter of bilingual names in the standard rendering. 
> How about this one: http://mlm.jochentopf.com/
> http://mlm.jochentopf.com/%20fill%20in%20%22nl%22%20or%20%22fr%22%20in%20the%20box%20to%20get%20the%20names%20rendered%20in%20those%20languages%20ben%20___%20talk-be%20mailing%20list%20talk...@openstreetmap.org%20https://lists.openstreetmap.org/listinfo/talk-be>
> Fill in "nl" or "fr" in the box to get the names rendered in those
> languages
> Ben

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

Re: [OSM-talk-be] rendering

[André Pirard]

On 2016-07-18 21:59, joost schouppe wrote:
> Nu het toch suggesties aan het regenen is: QGIS. Met de Openlayers
> plugin kan je verschillende stijlen van OSM op de achtergrond
> weergeven. De gpx kan je gewoon in het programma slepen. Er zit ook
> iets in om prints te maken, maar in de praktijk maak ik zelf doorgaans
> gewoon screenshots.
Ou bien modifier ma carte que je montre de temps en temps
.
La ligne verte est une des piste GPX.
Recopier le fichier source HTML et changer les données. 

"Circuit de luges" ==> "Dodentocht"



> // create GPX traces var Hornay_Louveigné = new newGPX ("vélo
> Hornay-Louveigné", "gpx/Hornay-Louveigné.gpx"); var
> Princesse_Clémentine = new newGPX ("hike Princesse Clémentine",
> "gpx/Princesse_Clémentine.gpx"); var hike_8339 = new newGPX ("hike
> Co90 Sentier géologique", "gpx/8339_Co90_Sentier_géologique.gpx"); var
> Ru_de_Chawion_UCP = new newGPX ("Ru de Chawion UCP",
> "gpx/Ru_de_Chawion_UCP.gpx"); var luges = new newGPX ("Circuit de
> luges", "gpx/luges.gpx"); var work = new newGPX ("work",
> "gpx/work.gpx"); ... // Add a Layer for a GPX Track //
> OpenLayers.Format.GPX({extractRoutes: false, extractAttributes: false,
> extractWaypoints: false, extractTracks: false}) function newGPX(name,
> URL) { var GPX = new OpenLayers.Layer.Vector(name, { strategies: [new
> OpenLayers.Strategy.Fixed()], protocol: new OpenLayers.Protocol.HTTP({
> url: URL, format: new OpenLayers.Format.GPX() }), style: {strokeColor:
> "green", strokeWidth: 5, strokeOpacity: 0.5}, projection: new
> OpenLayers.Projection("EPSG:4326") }); map.addLayer(GPX); }

>
> Op 18 juli 2016 21:09 schreef Marc Gemis  >:
>
> met maperative zou je dat redelijk eenvoudig zelf moeten kunnen maken
> je moet dan wel software lokaal installeren
>
> 2016-07-18 20:19 GMT+02:00 wannes  >:
> > je GPX opladen in www.afstandmeten.nl
>  en dan afdrukken.
> >
> > Je kan ook eens contact opnemen met
> > www.legendstracking.com/index.php/dodentocht/
>  zij bieden
> tracking aan
> > voor 20 euro. En dan ziet je familie je op de kaart, constant, niet
> > alleen aan de checkpoints.
> >
> > 2016-07-18 20:10 GMT+02:00 Bart Vanherck  >:
> >> Beste mappers,
> >>
> >> Weet iemand in de groep hier of er ergens een service of een
> programma
> >> bestaat waarmee ik een gpx trace op een openstreetmap layer kan
> plaatsen.
> >> Het doel is om een redelijk gedetailleerde kaart te hebben om
> af te printen.
> >>
> >> Ik ga namelijk de dodentocht doen, en mijn volgers zouden graag
> weten hoe de
> >> wandeling loopt. En internet access is niet mogelijk, vandaar
> de noodzaak om
> >> alles af te printen op papier.
> >>
> >> alvast bedankt,
> >>
> >> Bart
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org 
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >
> >
> >
> > --
> > wannes
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
>
> -- 
> Joost @
> Openstreetmap
>  | Twitter
>  | LinkedIn
>  | Meetup
> 
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] rendering

[André Pirard]

  
  
On 2016-07-18 20:10, Bart Vanherck
  wrote:


  Beste mappers,


Weet iemand in de groep hier of er ergens een service of
  een programma bestaat waarmee ik een gpx trace op een
  openstreetmap layer kan plaatsen. Het doel is om een redelijk
  gedetailleerde kaart te hebben om af te printen.


Ik ga namelijk de dodentocht doen, en mijn volgers zouden
  graag weten hoe de wandeling loopt. En internet access is niet
  mogelijk, vandaar de noodzaak om alles af te printen op
  papier.


alvast bedankt,


Bart

  

Salut Bart et tous,

GPSVisualizer.com doit
faire ce que tu veux.
Mais beaucoup diront qu'avant d'imprimer il faut penser à
l'environnement !!!
Après chargement du fichier GPX sur un smartphone, le programme
OSMand sera non seulement capable de montrer la piste GPX sur fond
OSM mais aussi de la suivre en mode GPS, et ce sans Internet et sans
papier.
Il faut vivre avec son temps et il y a de quoi amuser les promeneurs
en ayant en poche un smartphone qui dit "tournez à gauche" ou bien
"vous dépassez la vitesse limitée".  Dans un magasin, j'aime lui
faire dire "Faites demi-tour dès que possible".

Cordialement,



  

  André.

  


  


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

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[André Pirard]

On 2016-06-06 02:43, André Pirard wrote:
> Please do JOSM>Imagery>Imagery Preferences>Available default
> entries>refresh (whirling arrows)  and
> Activate : BE : SPW(allonie) PICC numerical imagery
> OK
> and use the PICC layer as before.
Je constate qu'il n'y a pas de noms de rues et qu'il y a des ridicules
colliers de boules de coton.
D'autre part, j'ai lu qu'ils ont (par exemple) retiré les points de
références bien utiles pour vérifier le positionnement.
Je vais vérifier demain si tout est complet.
Si oui, je chercherai un calque supplémentaire contenant les noms.
Ce n'est pas plus mal, car les noms masquaient souvent le centre de la voie.

En attendant, pourriez-vous repérer de semblables autres inconvénients
et améliorations.

Cordialement,

André.


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

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[André Pirard]

On 2016-06-05 00:51, Erik B wrote:
> Les données géographiques SPW PICC disponible comme layer dans JOSM ne
> fonctionnent plus.
> Message sur Géoportail de la Wallonie  :
> CETTE DONNÉE  EST DÉSACTIVÉE DÉFINITIVEMENT DEPUIS LE 31 MAI 2016 ;
> IL N'EST PLUS POSSIBLE DE L'OBTENIR ; VEUILLEZ UTILISER LA NOUVELLE
> VERSION DU PICC.
>
> Est-ce que cette nouvelle version est disponible? Et avec quel lien?

Please do JOSM>Imagery>Imagery Preferences>Available default
entries>refresh (whirling arrows)  and
Activate : BE : SPW(allonie) PICC numerical imagery
OK
and use the PICC layer as before.

Please use JOSM now that I made it possible.  It means 20 cm precision
and it detects many errors instead of the 2 to 5 m offset that is
usually seen, made by other methods.

WMS URL :
http://geoservices.wallonie.be/arcgis/services/TOPOGRAPHIE/PICC_VDIFF/MapServer/WmsServer?

More will come from me.

Effectuer le rafraîchissement ci-dessus du SPW PICC pré-configuré et
utilisez-le comme le précédent.

Merci pour l'avertissement.
J'avais écrit au SPW pour demander comment on peut être averti des
changements et je n'ai pas reçu de réponse comme d'habitude.  Mailing
list?  Je vois un RSS mais ça ne me semble pas pratique (chaque page?
les nouvelles? pas de journal?).

*S'il vous plait*, maintenant que j'ai tout fait pour que ce soit
possible, utilisez JOSM. Je vois sans cesse, au lieu de la précision de
20 cm, des éléments qui sont dessinés à 2 ou 5 m de leur endroit, sans
parler des erreurs que seul JOSM détecte.  C'est comme si un travail de
5 ans devait être recommencé.

Cheers
Cordialement,

André.


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

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[André Pirard]

  
  
On 2016-06-05 02:09, André Pirard
  wrote:


  
  On 2016-06-05 00:51, Erik B wrote:
  
  

Les données géographiques SPW PICC disponible comme layer dans
JOSM ne fonctionnent plus.
Message sur Géoportail de la
  Wallonie :
CETTE DONNÉE  EST DÉSACTIVÉE DÉFINITIVEMENT DEPUIS LE 31 MAI
2016 ; 
IL N'EST PLUS POSSIBLE DE L'OBTENIR ; VEUILLEZ UTILISER LA
NOUVELLE VERSION DU PICC. 

Est-ce que cette nouvelle version est disponible? Et avec quel
lien?
  
  Je vais tenter de remédier à ça demain soir.

Car je dois m'absenter la journée, je pars à l'instant.
En attendant, pour gagner du temps, à quel URL est ce message et en
faisant quoi l'obtient-on?
Le message contient   Géoportail de la
Wallonie

Cheers 


  

  André.

  



  


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

Re: [OSM-talk-be] WMS layer SPW(Wallonie) PICC disponible dans JOSM est obsolete

[André Pirard]

  
  
On 2016-06-05 00:51, Erik B wrote:


  
  Les données géographiques SPW PICC disponible comme layer dans
  JOSM ne fonctionnent plus.
  Message sur Géoportail de la Wallonie
  :
  CETTE DONNÉE  EST DÉSACTIVÉE DÉFINITIVEMENT DEPUIS LE 31 MAI 2016
  ; 
  IL N'EST PLUS POSSIBLE DE L'OBTENIR ; VEUILLEZ UTILISER LA
  NOUVELLE VERSION DU PICC. 
  
  Est-ce que cette nouvelle version est disponible? Et avec quel
  lien?

Je vais tenter de remédier à ça demain soir.

Cheers



  

  André.

  



  


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

[OSM-talk-be] Nice OSM POI maps for © lovers

[André Pirard]

Example .

Not all walks are signposted.
But who cares, with a GPS and a map?

Also see Leaflet. 

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

Re: [OSM-talk-be] Using SPW PICC layer in josm

[André Pirard]

On 2016-02-26 15:23, Thib wrote:
> Hi,
>
> SPW PICC tiles layer is available in JOSM for mapping Belgian Southern
> area but I can't find enough information about the license terms.
>
> Is it allowed to :
> - copy (doing"calc") buildings and other objects boundaries (as we do
> with bing tiles)
> - get address house numbers
According to a phone conversation Julien Fastré had with the SPW, what
we are doing is *not* copying the data in their eyes.  (I suppose this
is akin to map licenses often considering the copyright as a right to
reproduce the picture (and wasting paper "you can print...") and not the
right to make measurements on it.
On the other hand, Minister Henry ordered the SPW to free their
geographic data.

The PICC story is a pity.
In 2010, I notified the SPW helpdesk that the PICC server was returning
blank tiles in EPSG:4326 which is practically a requirement for JOSM and
which is served by almost all servers in the world.   No answer.
Later on, I asked to feed this request through our official channel with
the SPW and my insistence was laughed at by Julien Fastré whose own
insistence was "we cannot copy yet".
Now, that bug has finally been fixed.
In short, if the SPW had fixed that bug when I reported it, we would
have enjoyed a 5-year JOSM tagging at a 20 cm precision since what we do
is not copy.  I was able to use the PICC with Mapproxy, I did not
because of the false instructions but yet I have been suspected to be a
copying pirate!
And nowadays, it's a real pity to find most houses and roads at a 2 to 5
m distance of their real location, especially those who were and still
are mapped with other tools than JOSM and PICC. It makes feel like
everything has to be redone again at 20 cm precision..
Making corrections is difficult because I proposed a revision date
tagging that could have been very useful in this case but there was no
interest on the Tagging list and even Marc Gemis was on my tracks to say
it's impossible.
In consequence, if you find the following tag, it means that I have
rectified the geometry.
source=20cm-near PICC http://geoportail.wallonie.be 2015  or
source:geometry=same.
Unfortunately, I have made many many untagged corrections.

Cheers

André.





>
> I've found some old threads talking about that interesting source but
> no real answer...
>
> If someone has any information about it, It would be very useful.
>
> Thanks in advance.
> Regards,
>
> Thib
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Changes to Belgian-Dutch Border

[André Pirard]

On 2016-01-04 20:41, Marc Gemis wrote:
> Found an article on De Redactie (Dutch):
> http://deredactie.be/cm/vrtnieuws/binnenland/1.1773332
For better French than  La Belgique se correctif zéro Pays-Bas

see  La Belgique sera plus petite en 2016
.

I wish we could send them an OSM URL showing the affected territories
better.
But that's "wishing for the renderer" ;-)

André.


> On Mon, Jan 4, 2016 at 8:37 PM, Sander Deryckere  wrote:
>> I heard that it would happen this year, not that it already happened.
>>
>> See this note: http://www.openstreetmap.org/note/275464
>>
>> 2016-01-04 20:29 GMT+01:00 Marc Gemis :
>>> Hallo,
>>>
>>> I heard on the radio today that the Belgian-Dutch border was adapted.
>>> Belgium became a bit smaller. Anyone knows whether this change is
>>> already reflected in OSM ? I can't find an online article.
>>>
>>>
>>> regards
>>>
>>> m
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be

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

Re: [OSM-talk-be] Erreur dans la base de donnée

[André Pirard]

On 2016-01-03 21:34, lionel bulpa wrote:
> Bonjour,
>
> Alors là je comprends plus rien, effectivement tout est là, pourtant
> j'ai regardé 4-5 fois aujourd’hui et les données ne se sont jamais
> affichées. Je n'y comprends plus rien. Enfin bref, le principal est
> que les informations soient là.
Il faut parfois rafraîchir la carte OSM pour voir les tuiles à jour;
Cette carte montre toutes les modifications

du dernier mois (cliquer une tuile, aide: ?
)
> Au passage si vous avez des conseils à me donner sur ma façon de
> mapper, je suis preneur, je suis encore un novice.
Sans aucun doute:  JOSM et le PICC à 20 cm de précision et pas autre chose.

André.


> Merci beaucoup
>
> Lio 
>
> (et merci pour la réponse en français ;) )
> 
> Date: Sun, 3 Jan 2016 19:59:21 +
> From: stijnromba...@yahoo.com
> To: talk-be@openstreetmap.org
> Subject: Re: [OSM-talk-be] Erreur dans la base de donnée
>
> Bonjour,
>
> [Je vais essayer de répondre en français.]
> Je crois tout est encore dans la base de donnée. Le lien que tu a
> donné me mène vers la version 'MapQuest Open' de OSM qui n'est pas
> renouvelé souvent apparament. Si tu prend la version 'normale' tout
> est là, non? https://www.openstreetmap.org/#map=17/50.41994/4.92651
>
> StijnRR
>
>
>
> 
> *From:* lionel bulpa 
> *To:* OpenStreetMap Belgium 
> *Sent:* Sunday, January 3, 2016 8:32 PM
> *Subject:* Re: [OSM-talk-be] Erreur dans la base de donnée
>
> Bonsoir,
>
> Je ne connaissais pas mon historique personnel mais je viens de
> regarder, mes dernières modifications ont bien été faites il y a 29
> jours dans le quartier de Nannine, mon pseudo OSM est Lionel Bulpa
> : 
> https://www.openstreetmap.org/user/Lionel%20Bulpa/history#map=12/50.4191/4.9200&layers=Q
>
> Si tu sais m'aider ;) , je dois avouer que je n'ai pas envie de
> recommencer
>
> Merci
>
> Lio
>
> 
> From: mgwebm...@fastmail.fm
> Date: Sun, 3 Jan 2016 19:14:41 +0100
> To: talk-be@openstreetmap.org
> Subject: Re: [OSM-talk-be] Erreur dans la base de donnée
>
>
> Bonjour Lionel,
>
> Quel est ton nom d’utilisateur sur OSM ? As-tu vérifié tes dernières
> contributions via ta page perso sur openstreetmap.com
>  ?
>
> Matthieu
>
> On 03 Jan 2016, at 18:25, lionel bulpa  > wrote:
>
> Bonjour,
>
> Il y a 29 jours, j'ai ajouté tout un quartier de Nannine (près de
> Namur) dans la base de donnée, je suis sur que les informations
> sont parvenues au serveur car les maisons, l'école, etc
> apparaissaient sur la carte. Je viens de vérifier, personne ne
> semble avoir édité le quartier depuis et pourtant, tout mon
> travail a disparu, quelqu'un sait il pourquoi?
>
> Merci d'avance
>
> Lionel Bulpa
> 
>

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

Re: [OSM-talk-be] Strange nice map

[André Pirard]

On 2015-12-28 01:37, Gerard Vanderveken wrote:
> Originates from this 'wizz kid' <http://www.code-wendt.de/>.
who found an excellent way to make OSM known as I stumbled upon it after
a plain search <https://www.google.be/search?&q=daline+tilff> for a shop
(20th hit).
I wish I knew how to boost a site up in Google's order.
> I like the colours and general appearance, but streetnames are not
> optimal.
>
> Regards,
> Gerard
>
> André Pirard wrote:
>> Hi,
>>
>> I have been very surprised to find this
>> <http://fast_food.cartogiraffe.com/belgi%C3%AB+-+belgique+-+belgien/wallonie/wallonie+%28communaut%C3%A9+fran%C3%A7aise%29/li%C3%A8ge/li%C3%A8ge+%28communaut%C3%A9+fran%C3%A7aise%29/li%C3%A8ge/esneux/ourthe-ambl%C3%A8ve/daline/#16,50.5687581566851,5.584530830383301>
>> as result of a search.
>> Definitely all OpenStreetMap.
>> Strange rendering.
>> Definitely for the clever ones who manage to use OSM without a Help.
>> I found that one can ask for "petrol near Houte-si-Plout", but not bread.
>> But hospital and cemetery are OK.
>> Investigate, guess and tell us more surprises.
>>
>> Cheers
>>
>> André.
>>
>>
>>
>> 
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>   
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Strange nice map

[André Pirard]

Hi,

I have been very surprised to find this

as result of a search.
Definitely all OpenStreetMap.
Strange rendering.
Definitely for the clever ones who manage to use OSM without a Help.
I found that one can ask for "petrol near Houte-si-Plout", but not bread.
But hospital and cemetery are OK.
Investigate, guess and tell us more surprises.

Cheers

André.



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

Re: [OSM-talk-be] IGN/NGI/NGI/NGI too now using OpenStreetMap

[André Pirard]

Hi,

Regarding this wonderful proposition of Nicolas, IGN/NGI/NGI/NGI/НГИ 
have announcedCartoWebreplacingTestbed.

See the announcement below the fr/nl bars at the end of this e-mail.
This looks great when a JOSM bug/incompatibility will be fixed. I've 
opened a ticket and I'm confident.
This CartoWeb supports CECP 3857 /private-joke>
I need to see it work to compare with Testbed. I wonder how the 
additional layers can be selected.
One thing I can already say is that if the administrative borders were 
coarse with Testbed, they are completely wrong with CartoWeb and, if he 
looked at that, it's no wonder that someone found that they don't match OSM.
Please Nicolas or someone, look at convention #2 
<http://www.ngi.be/FR/FR1-19-1-1.shtm> to see if they could agree to 
make it suitable for OSM.be.


André.


On 2015-11-12 09:43, joost schouppe wrote:

Hi André, Nicolas,

I would be interested in hearing what they have to say too. The NGI 
road data might be very interesting for us too, if only to check for 
missing roads in our map (especially the "slow roads" still need work 
in Belgium).


Sorry about the late response, and thanks for bumping this, André.

2015-11-11 18:25 GMT+01:00 André Pirard <mailto:a.pirard.pa...@gmail.com>>:


On 2015-09-06 23:54, Nicolas Pettiaux wrote :

Dear

In March, I have met the directeur général adjoint of IGN during
a meeting about GIS in Belgium where I represented the OSM.BE
<http://OSM.BE> team (Ben had been invited too and I have
coordinated with him) and he let me know that he would be willing
to share data with us.

We could prepare to go and meet officially (as the OSM-be
representatives) IGN to discussi licences, compatibility and
mutual help.

Who is interested ?

The IGN/NGI is a most important source of information indeed.
I'm very surprised that no one else replied.
Thanks.  Keep us informed.

But the first thing to know is if what we do isn't allowed
already, like for the SPW.
IGN states conditions almost as vague as the SPW.
For the SPW, now that we know that "we cannot copy yet" isn't true
and now that the SPW fixed the PICC bug that I have asked 5 years
ago (and that was being laughed at), we can now redo with JOSM
with a 20cm precision much of the work that was made over 5 years
with a 2 to 5 m error and more with other editors.

Cheers

André.




Best regards,

Nicolas

Le dim 6 sep 2015 à 21:45, André Pirard
 <mailto:a.pirard.pa...@gmail.com> a
écrit :

Hi,

In their now official Cartesius project
<http://www.cartesius.be/CartesiusPortal/>, IGN/NGI/NGI/NGI et
al. too are now using OpenStreetMap
<http://www.cartesius.be/arcgis/home/webmap/viewer.html?> (click
Basemap).

It would have been surprising that NGI did not display the OSM ©
notice ;-)
Please notice that they reproduce without a frown the OSM
mapping of the so-called © NGI boundaries that we "cannot copy
yet" (belonging to the various successive governments (French
and Belgian mainly)) !

Cheers ,

André.








L’IGN a pris la décision d’arrêter le service en ligne Testbed ouvert 
depuis 2008, au *31 janvier 2016.*


En effet, ce service-test ne répond plus aux exigences et aux données 
techniques des services en ligne.


Cependant, afin de rencontrer la demande croissante des utilisateurs, 
nous avons développé et mis en ligne, un service performant appelé 
*‘CartoWeb.be’*.


Vous pouvez trouver l’ensemble des informations ainsi que les 
conditions d’utilisation concernant ce service sur notre site à la 
page : http://www.ngi.be/FR/FR1-19-1.shtm ou 
http://www.ngi.be/NL/NL1-19-1.shtm


Vous pouvez également le visualiser via notre application ‘Topomapviewer’

http://www.ngi.be/topomapviewer/public?lang=fr ou 
http://www.ngi.be/topomapviewer/public?lang=nl


CartoWeb.be possède de nombreux avantages. En plus d’être un WMTS et 
d’être donc largement plus rapide qu’un WMS, CartoWeb.be fonctionne 
avec une mise à jour continue et permet d’afficher 13 niveaux 
d’échelles avec des représentations cartographiques adaptées au zoom.


Ce changement peut amener des différences significatives pour vous. 
C’est pourquoi nous vous encourageons à nous faire part de toute 
remarque ou critique (positive ou négative) de façon à ce que nous 
puissions concentrer nos efforts pour améliorer nos services dans la 
mesure de nos possibilités.


L’adresse de contact est carto...@ngi.be <mailto:carto...@ngi.be> .

En vous remerciant d’avance pour votre collaboration,

L’équipe CartoWeb.be de l’institut géographique national

cid:image001.jpg@01D0CADF.4A296910





Op *31 januari 2016*

Re: [OSM-talk-be] Rise of the voetwegen

[André Pirard]

On 2015-12-04 08:13, joost schouppe wrote :
>
> I don't think it's realistic to ask everyone to translate into the
> three languages. It is too much work, but also: I'm not sure anyone
> would understand my French :)
>
> There is no perfect solution as some of us are monolingual. But I
> think we're actually doing pretty good. People do tend to write in
> English when their message is relevant to all Belgians.
>
> Some things we might do to improve:
> - try to write auto-translate friendly. So try to avoid typical
> expressions, mixing languages, etcetera.
> - try to be mindful of a conversation  turning from local interest to
> Belgian interest. Consider switching to English in those cases.
> - when you're interested in a conversation but can't follow because of
> the language, just ask for a summary of the conversation in English or
> the other  main national language.
>
Good thoughts.
Sorry I hadn't seen Lionel's message and Jo's and Joost's answers before
sending my last message.
(I'm a threaded messages display newbie ;-) )

First, I repeat, and maybe update, my previous advice for translation
for Thunderbird and Firefox:
S3.Google Translator (extension): no need to copy and paste to read
messages, just select.
This (the following) is done with it.  Even a "language learning" function.

Tout d'abord, je le répète, et peut-être mettre à jour, mon conseil
précédent pour la traduction pour Thunderbird et Firefox:
S3.Google Translator: pas besoin de copier et coller à lire les
messages, sélectionnez simplement.
Cela se fait avec elle. Même une fonction "d'apprentissage de la langue".

Ten eerste, ik herhaal, en misschien werken, mijn vorige advies voor
vertaling voor Thunderbird en Firefox:
S3.Google Translator: geen behoefte om te kopiëren en te plakken om
berichten te lezen, gewoon selecteren.
Dit wordt gedaan met het. Zelfs een functie "leren van talen".

Second, as an experiment, I used Google Translation from nl.wikipedia.
Google has a terrible problem with word order (1), for example, the verb
at the end of the phrase.
I understood most of the translation to English directly, but I rather
often had to read the phrase a second time to understand.  So, why was
it so difficult with talk-be?

"try to write auto-translate friendly" says Joost.
Perfectly true. When I write text on my Web site which uses translation
buttons, I often check the translation. But Google are a real pest, they
made a translation cache, they don't check the file date and you don't
see any change. So the trick is to write in Thunderbird and to check
the  translation with S3.Google Translator.
But this feedback process is tedious and without it it's only guesses.
The only advice I can think of is to make simple and unambiguous phrases.
I don't know Dutch enough to give advices for it.
But maybe Jo, who knows the three languages so well, could repeat my
experiment, see if he finds a translation quality difference and why and
conclude with advices to write his mother language more simply.

Hoping this can help,

André.


(1) I once put in the Wikipedia "Google Translation" page a Russian ->
English translation that said exactly the opposite because of word order
(but, as usual, they removed it and they asked me 2€ instead).
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Rise of the voetwegen

[André Pirard]

On 2015-12-02 21:35, Jo wrote :
> It seems like a way to prove that Google Translate is not quite up to
> spec...
It is indeed one reason that you should know: Google does not help
understanding such messages, possibly because of turns of phrases.
When I was an OSM newbie, although I fairly know Dutch from school, I
did not subscribe to talk-be because of that.
It seemed Dutch-only at first sight.
On the other hand, I almost never saw a French-only message, even for
Southern matters.
But Marc is reading Russian ;-)
> The list is multilingual. The topic concerns "slow" paths in Flanders.
> If we'd try to have the conversation in English we'd exclude people
> who need to participate and that can't be the intention.
OK. Let us not exclude people who need to participate in Southern matters.
I recently read "C'est quoi talk-be ?".
> Op deze lijst kan in meerdere talen gepost worden. Het gaat over Trage
> Wegen in Vlaanderen. Als we de conversatie in het Engels zouden
> trachten te voeren, dan sluiten we mensen uit die betrokken zijn en
> dat kan de bedoeling niet zijn.
Пока

André.


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

Re: [OSM-talk-be] WMTS and JOSM

[André Pirard]

On 2015-12-07 00:34, Jo wrote :
> Thank you André. I hadn't been able to get WMTS configured yet,
> probably because of that reason.
The fix should be in the latest snapshot already for any eagerness to know.
>
> Cheers,
>
> Jo
>
> 2015-12-06 23:17 GMT+01:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> Hi,
>
> I see that OSM.be members are using WMTS.
> A WMTS layer is slow to start on JOSM, to the point that JOSM may
> seem to be looping (>3 min start).
> I have filed a ticket and the next JOSM version will have a
> drastically sped up Capabilities parser.
>
> André.
>
>

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

[OSM-talk-be] WMTS and JOSM

[André Pirard]

Hi,

I see that OSM.be members are using WMTS.
A WMTS layer is slow to start on JOSM, to the point that JOSM may seem
to be looping (>3 min start).
I have filed a ticket and the next JOSM version will have a drastically
sped up Capabilities parser.

André.



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

Re: [OSM-talk-be] Rise of the voetwegen

[André Pirard]

On 2015-12-02 14:43, Glenn Plas wrote :
> Hi,
>
> Effe korte peer check:  Ik zie veel voetwegen verschijnen in de buurt,
> op zich super natuurlijk maar ik begin een wildgroei aan tags te zien
> voor dezelfde voetweg per segment.  Het is een zootje aan het worden met
> footways die overgaan naar paths en terug footway.
>
> Naast het feit dat ze vaak als name='voetweg 1234'(, of erger: 'chemin
> 1234' in vlaanderen)  worden gemarkeerd ipv. hun officiele benaming, zie
> ik toch iets teveel footway's door velden en akkers trekken...
>
> Instinctief zou men snel geneigd zijn er 'footway' van te maken, wat op
> de map op zich niet lelijk 'rendert'.  Maar de renderer.
>
> Ik vind dat een 'path' meer geschikt is, zeker als ik de voetweg door
> velden zie gaan en waar een geen visible pad is volgens AGIV sat pics.
>
> Iemand daar zelf ook al issue's mee gehad.  Is er iemand die 'footway'
> meer geschikt vind voor vaak -kwasi denkbeeldige- wegen?  Waarom?
>
> Ik pas dit meestal in alt_name='voetweg 1234' en dan als
> name='Liposuctievoetweg'.
>
> Voorbeeld bv deze: https://www.openstreetmap.org/way/383827575
>
> Graag wat input van de wandelaars en andere kenners onder ons, hoe
> pakken jullie dit vast ?
>
> Glenn
>
> Effe courte poire Vérifier: Je vois beaucoup de sentiers apparaissent près, 
> surnaturel en soi, mais je commence à voir une prolifération de points pour 
> le même sentier par segment. Il est un gâchis d'être avec trottoirs qui sont 
> transférés à des chemins et trottoir arrière. Outre le fait qu'ils nomment 
> souvent = 'rue piétonne en 1234 "(ou pire:' chemin 1234 en Flandre) sera 
> marquée à la place. leur nom officiel, je vois le feu de quelque chose de 
> beaucoup trottoir à travers les champs et les terres agricoles ... 
> Instinctivement, on serait enclin il «trottoir» de ce qui est pas laid sur le 
> sur le dossier rend. Mais le moteur de rendu. Je trouve cela un «chemin» est 
> plus approprié, surtout quand je vois le sentier à travers champs et aller là 
> où aucun chemin visible, selon AGIV satellite photos. Quelqu'un là-bas lui 
> même question a eu il. Est-ce qu'il ya quelqu'un qui «trottoir» le plus 
> souvent à trouver des routes denkbeeldige- -kwasi appropriés? Pourquoi? Je 
> fais juste habituellement ce alt_name = 'sentier 1234 et puis comme name = 
> "liposuccion Voetweg. Cet exemple: 
> https://www.openstreetmap.org/way/383827575 comme une entrée des randonneurs 
> et d'autres experts parmi nous, comment abordez-vous ce fixe? 
>
> Glenn
>
> Check Effe short pear: I see many paths appear almost supernatural in itself, 
> but I begin to see a proliferation of points to the same path segment. It is 
> a mess to be with sidewalks that are transferred back to the roads and 
> pavement. Besides the fact that they often name = 'pedestrian street in 1234 
> "(or worse: 1234 Road in Flanders) will be marked instead their official 
> name, I see the fire of something far sidewalk and across the fields. 
> farmland ... Instinctively, one would be inclined it "sidewalk" what is not 
> ugly on the folder makes. But the renderer. I find that a "path" is more 
> appropriate, especially when I see the trail through fields and go where no 
> visible way, according AGIV satellite photos. Someone out there same question 
> he had it. Is there anyone who "sidewalk" often find roads denkbeeldige- 
> -kwasi appropriate? Why? I just usually do this alt_name = 1234 trail and 
> then as name = "Voetweg liposuction. This example: 
> https://www.openstreetmap.org/way/383827575 as an input for hikers and other 
> experts among us, how do you approach this fixed?
>
> Glenn
???


  * French - detected
  * English
  * French
  * Russian

  * English
  * French
  * Russian



  * English
  * French
  * Russian

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

Re: [OSM-talk-be] New UrbIS presets for Bruno and everybody

[André Pirard]

On 2015-11-26 10:07, Sander Deryckere wrote :
> Do we really need these old URBIS urls? What use are they for regular
> mappers (in contrast to people interested in recent history of a
> region)? IMO they would clutter the list.
Old versions of aerial photos are often very interesting when something
is difficult to see on recent ones.
An example that their users know very well is trees that are hiding the
ground or not.
Also, I was very impressed to discover the works over 6 years in Brussels.
And they may be useful, for example to check that what's on the map is
an old topology.
But if the general opinion is to lessen chance to see better and not
find older years exist, I will remove them.
Don't forget (obviously) to tell which years you want removed.
And install what you like before removal, those who like.

André.



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

Re: [OSM-talk-be] New UrbIS presets for Bruno and everybody

[André Pirard]

Hi,

For a test, I'd like a few streets of Urbis where the houses are still
to map (with number).
I may erase tags, do my test and not save the result, of course.
But I prefer to be useful as well.
Does that exist?

Cheers

André.




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

Re: [OSM-talk-be] New UrbIS presets for Bruno and everybody

[André Pirard]

On 2015-11-26 00:42, Jo wrote :
> Hi Bruno,
>
> André did a great job to provide you with the rendered version of what
> UrbIS has in their GIS. Thank you for that André.
>
> From your originial post I understand you wanted aerial photography
> though. So I added that as:
>
> URBIS Orthorectified aerial imagery covering Brussels Region (2014)
> <https://josm.openstreetmap.de/wiki/Maps/Belgium#URBISOrthorectifiedaerialimagerycoveringBrusselsRegion2014>
Oops, I was understanding that I was  taking care of Urbis and as there
was no answers to my messages I added

Configure
Imagery>Imagery preferences>refresh (whirling arrows)>select *BE URBIS
20xx*>Activate>OK
Activate
Imagery>URBIS 20xx and there should come your layer


with xx = 09, 12, 14, 15 and the same advantages over the WMS versions
as explained below.
It was just a few characters to change and right when I saved the file:
clash.
That's OSM, that's life ;-)

Thanks for AGIV, Jo.

Cheers

André.








>
> To the website of JOSM, which means you can 'install' it in your local
> copy of JOSM by updating the WMS sources, and then selecting it for use.
>
> https://josm.openstreetmap.de/wiki/Help/Preferences/Imagery
>
> I'm still trying to figure out how to the same for the new AGIV
> imagery that covers Flanders.
>
> Also try JOSM's Mapillary plugin for streetview images. PhilippeC has
> already made a lot of pictures in and around Brussels. It's nice for
> double checking from a different perspective.
>
> Cheers,
>
> Polyglot
>
> 2015-11-25 23:48 GMT+01:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> On 2015-11-24 12:37, Bruno Veyckemans wrote :
>> Hi all,
>>
>> I became an enthusiastic OSM mapper following Julien Fastré's
>> presentation at Foss4G BE last month, and now have big projects
>> to map all I can in Brussels. 
>>
>> I focus on using Overpass / PHP to create listings and see what's
>> missing in the capital (museums, parks, churches, artwork,
>> hospitals...), such as: http://ici.brussels/liste-musees (website
>> in french, but I take care to add tags in FR/NL/EN... By the way,
>> I would be glad if some users helped to fill the blanks).
>>
>> My question is about OSM's Bing imagery. I know Brussels has
>> beautiful and precise 2015 aerial pictures thanks to UrbIS (see
>> here: http://geoloc.irisnet.be/ , ArcGIS server), but I don't
>> know how to use it in OSM to map Brussels (their 2015 WMS isn't
>> yet available). Do you think it's possible ?
> Hi Bruno,
>
> Welcome to OSM !!!  I have made new JOSM presets for Urbis as
> described below.
>
> When I am mapping, I meet many elements that were previously
> mapped with a 2-5-10m+ precision and I remap them with a 20 cm
> precision using the SPW servers.  The best advices I can give to
> map precisely are:
>
>   * use JOSM, even if it seems harder to start with, it's much
> rewarding in the long term; suboptimal mapping is usually done
> with other editors
>   * use digitalized maps: aerial photographs are shot from an
> angle: they are rectified horizontally but not vertically: the
> walls or other vertical features are slanted and the roofs are
> offset relatively to the ground; digitalized maps are the
> result of calculations that a human cannot do to put all that
> right.
>
> On 2015-11-24 22:11, Julien Fastré wrote :
>> Hi Bruno,
>> Hi the list
>>
>> You can add easily the WMS server of Urbis in JOSM.
>>
>> ...
>>
>> 
>> http://geoserver.gis.irisnet.be/urbis/wms?service=wms&version=1.3.0&request=GetCapabilities
>
> Forget about that URL and what I have said before about using it.
> I have made new presets that are prettier, faster, more simple,
> more precise by supporting 3857 and without the pesky message.
>
> Configure
>   Imagery>Imagery preferences>refresh (whirling arrows)>select *BE
> URBISfr*>Activate>OK
> Imagery>Imagery preferences>refresh (whirling arrows)>select *BE
> URBISnl*>Activate>OK
> Activate
>   Imagery>URBISfr or URBISnl and there should come your layer
>
>
> Let me know if everything is right for you.
>
> Happy mapping.
>
> André.
>
>
>>
>> ---
>>
>> Bonjour à tous,
>>
>> Je suis devenu un "mapper" enthousiaste d'OSM à la suite de la
>>

Re: [OSM-talk-be] New UrbIS presets for Bruno and everybody

[André Pirard]

On 2015-11-24 12:37, Bruno Veyckemans wrote :
> Hi all,
>
> I became an enthusiastic OSM mapper following Julien Fastré's
> presentation at Foss4G BE last month, and now have big projects to map
> all I can in Brussels. 
>
> I focus on using Overpass / PHP to create listings and see what's
> missing in the capital (museums, parks, churches, artwork,
> hospitals...), such as: http://ici.brussels/liste-musees (website in
> french, but I take care to add tags in FR/NL/EN... By the way, I would
> be glad if some users helped to fill the blanks).
>
> My question is about OSM's Bing imagery. I know Brussels has beautiful
> and precise 2015 aerial pictures thanks to UrbIS (see here:
> http://geoloc.irisnet.be/ , ArcGIS server), but I don't know how to
> use it in OSM to map Brussels (their 2015 WMS isn't yet available). Do
> you think it's possible ?
Hi Bruno,

Welcome to OSM !!!  I have made new JOSM presets for Urbis as described
below.

When I am mapping, I meet many elements that were previously mapped with
a 2-5-10m+ precision and I remap them with a 20 cm precision using the
SPW servers.  The best advices I can give to map precisely are:

  * use JOSM, even if it seems harder to start with, it's much rewarding
in the long term; suboptimal mapping is usually done with other editors
  * use digitalized maps: aerial photographs are shot from an angle:
they are rectified horizontally but not vertically: the walls or
other vertical features are slanted and the roofs are offset
relatively to the ground; digitalized maps are the result of
calculations that a human cannot do to put all that right.

On 2015-11-24 22:11, Julien Fastré wrote :
> Hi Bruno,
> Hi the list
>
> You can add easily the WMS server of Urbis in JOSM.
>
> ...
>
> http://geoserver.gis.irisnet.be/urbis/wms?service=wms&version=1.3.0&request=GetCapabilities

Forget about that URL and what I have said before about using it.
I have made new presets that are prettier, faster, more simple, more
precise by supporting 3857 and without the pesky message.

Configure
Imagery>Imagery preferences>refresh (whirling arrows)>select *BE
URBISfr*>Activate>OK
Imagery>Imagery preferences>refresh (whirling arrows)>select *BE
URBISnl*>Activate>OK
Activate
Imagery>URBISfr or URBISnl and there should come your layer


Let me know if everything is right for you.

Happy mapping.

André.


>
> ---
>
> Bonjour à tous,
>
> Je suis devenu un "mapper" enthousiaste d'OSM à la suite de la
> présentation de Julien Fastré au Foss4G BE le mois dernier, et j'ai
> maintenant des projets assez ambitieux pour compléter tout ce que je
> peux en Région bruxelloise.
>
> J'utilise Overpass et PHP pour générer des listes des infrastructures
> de la capitale (musées, parcs, églises, oeuvres d'art, hôpitaux...)
> comme celle-ci: http://ici.brussels/liste-musees (et je serais heureux
> si certains se joignaient à moi pour compléter les tags manquants).
>
> Ma question porte sur les images satellites d'OSM, fournies par Bing.
> Je sais que Bruxelles possède des images aériennes de 2015 beaucoup
> plus belles et précises grâce à UrbIS (par exemple ici:
> http://geoloc.irisnet.be/ ), mais je ne sais pas comment les utiliser
> dans les outils d'édition d'OSM. Pensez-vous que ce soit possible ?
> J'ai notamment envie de redessiner les chemins du Cimetière de
> Bruxelles, parfaitement visibles sur BrugIS 2015 mais pas sur Bing, et
> d'y ajouter ses tombes célèbres...
>
>
> Merci/Thanks/Dank u et belle journée malgré le #BrusselsLockdown
> Bruno - ici.Brussels
>

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

Re: [OSM-talk-be] UrbIS aerial pictures for Brussels on OSM - Vues aériennes UrbIS 2015 sur OSM

[André Pirard]

On 2015-11-25 00:12, André Pirard wrote :
> On 2015-11-24 22:11, Julien Fastré wrote :
>> ...
>>
>> Add the URL [1] in the required field, and click on "get the layers".
>> You will see all the layer available !
>>
>> Choose your layer and give him a name.
>
> On 2015-11-24 22:19, Julien Fastré wrote :
>> Does someone have the power to do that ? For newbies (like the recet
>> message) it would be useful. We could also update the AGIV luchtfotos
>> link.
> Agathe Thepower, but it's like setting a Rendez Vous without telling
> where ;-)
> Could you, or someone(s) who's used to use Urbis tell me what layers
> they need.
>
> It seems that "AGIV(laanderen) aerial imagery (covers Brussels region
> as well)".
> (to me, it seems that AGIV, URBIS and SPW use the same runs of photos).
> So, you don't need the URBIS photos, you use AGIS, right?
>
> Regarding the digitalized tiles, there is B/W vs color and what they
> call FR vs NL, which is not France vs Netherlands, but fr vs nl,
> French vs Dutch.  So I make two versions, right?
> Now there are a lot of optional, additional layers to choose.
> Should I add them all, or is there anything annoying according to your
> experience?
>
> I think that I'll add everything. Anyone can remove anything he wants
> from the command.
>
> But, after all, the most simple would be to send me an URL you're
> working with from the config.
>
> What is there to change to AGIV?
> Aren't there usable, digitalized pictures for Flanders as well?
>
> Cheers
>
> André.
>
>
I have added a, URBIS fr preset as I said: Base color fr + all optional
layers.
Yet a detail about bbox (boundaries) to fix.

Imagery>Imagery preferences>refresh (whirling arrows)>select URBIS
fr>Activate>OK
Imagery>URBIS fr  and there should come your layer

The projection related message is new to JOSM, shouldn't exist (1) and
should  be avoidable.
I'll tell my JOSM friends about it.

Let me know if everything is right for you.
I first thought that this map was scanty, but I looked at their preview
and it seems it's what I must get.
Then will you want an URBIS nl?

I wanted to check the AGIV photos over Brussels, but they don't work.
Jo, the author, could you check what's going on there?
Please note that, for photos, you'd better use jpeg than bmp.

It would be better that Urbis supported the projection 3857 too.
Should I contact them to explain why? Who's best?

(1) JOSM underwent a drastic update two versions ago.
The WMS and TMS caches were unified and, at my and other's request, they
now support WMTS.
WMTS stresses the server less, is supported by URBIS and we should use it.
But it loops with URBIS. Yet another JOSM bug to report.
I'll let you know when this issue will be solved.

WMTS generally does not work with the SPW.
That is because, contrarily to what was said, it supports neither 4326
nor 3857.
I won't explain that all over again.
Please tell us when this issue will be fixed.   Hi Julien!


André.






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

Re: [OSM-talk-be] UrbIS aerial pictures for Brussels on OSM - Vues aériennes UrbIS 2015 sur OSM

[André Pirard]

  
  
On 2015-11-24 22:11, Julien Fastré
  wrote :


  ...

Add the URL [1] in the required field, and click on "get the layers".
You will see all the layer available !

Choose your layer and give him a name.



On 2015-11-24 22:19, Julien Fastré
  wrote :


  Does someone have the power to do that ? For newbies (like the recet
message) it would be useful. We could also update the AGIV luchtfotos
link.


Agathe Thepower, but it's like setting a Rendez Vous without telling
where  ;-) 
Could you, or someone(s) who's used to use Urbis tell me what layers
they need.

It seems that "AGIV(laanderen) aerial imagery (covers Brussels
region as well)".
(to me, it seems that AGIV, URBIS and SPW use the same runs of
photos).
So, you don't need the URBIS photos, you use AGIS, right?

Regarding the digitalized tiles, there is B/W vs color and what they
call FR vs NL, which is not France vs Netherlands, but fr vs nl,
French vs Dutch.  So I make two versions, right?
Now there are a lot of optional, additional layers to choose.
Should I add them all, or is there anything annoying according to
your experience?

I think that I'll add everything. Anyone can remove anything he
wants from the command.

But, after all, the most simple would be to send me an URL you're
working with from the config.

What is there to change to AGIV?
Aren't there usable, digitalized pictures for Flanders as well?

Cheers



  

  André.

  



  


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

Re: [OSM-talk-be] Packaging Urbis ortho by default in JOSM

[André Pirard]

On 2015-11-24 22:19, Julien Fastré wrote :
> Hi,
>
> I have read a message from Polyglot some months ago about adding some
> WMS services by default in JOSM.
You may also have read that, when the reprojection SPW bug was solved, I
added their servers (photos and PICC).
Since then, everything that was done during 5 years with a 2-5-10m+
precision can be redone with 20cm precision.
Doing so, you should not have a projections problem [MODE PRIVATE JOKE
ON] Hi Julien! [MODE PRIVATE JOKE OFF].
I have worked with JOSM to solve problems with SPW.
> Would it be possible to add the urbis ortho amongst those services ? I
> think we had to add the link into a CVS/Git repository, or something
> like that.
>
> Does someone have the power to do that ? For newbies (like the recet
> message) it would be useful. We could also update the AGIV luchtfotos
> link.
I will do that tonight.
[MODE PRIVATE JOKE ON] unless Jo picks my work again [MODE PRIVATE JOKE
OFF].

Cheers

André.


> More info about the WMS server from urbis :
>
> http://cirb.brussels/fr/nos-solutions/urbis-solutions/urbis-tools
>
> The WMS "get capabilities" link :
>
> http://geoserver.gis.irisnet.be/urbis/wms?service=wms&version=1.3.0&request=GetCapabilities
>
> Julien
>

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

Re: [OSM-talk-be] Friendliness with attacked mapped places in Paris

[André Pirard]

On 2015-11-14 17:24, Ruben Maes wrote :
> Hi
>
> I'm sorry, but just no. Though I am personally shocked just like everyone 
> else, I feel that OSM is IMO not the place for these kind of messages. I 
> would rather have your changeset reverted.
My mind was not agreeing with my heart when clicking "send" because I
feared this reply.
> Furthermore, you have no right to speak on behalf of *all* OSM mappers. 
That is exactly why I posted this message, to know the general opinion
about it.
At this time, it's 1 no 2 yes.
I'm waiting for more reactions and if there is not a strong majority of
yeses, I will revert.
So, please say yes if you feel like it, not just no.

By all means, do not tell anybody else that the OSM community until a
decision is made by Monday.

And please everybody, say something else that just noes and tell us what
you think about the Wikipedia link.  That is, a link that is not the
website of the element but to information related to it.
> There may even be terrorists here for all we know.
>
> If this were to appear in the press like you suggest, I would feel ashamed 
> and have the feeling that we are using the events for our own cause, which 
> too many people are already doing.
I don't feel like that at all.  There is no boasting.
Would you suppress humanitarian tagging about which there is much boasting?

Cheers

André.


> Regards
> Ruben
>
>
> Saturday 14 November 2015 17:14:57, André Pirard:
>> Hi,
>>
>> OpenstreetMap often extends friendliness by humanitarian tagging.
>> In this case of desolation, there is little to tag.  Little...
>> Wikipedia have been extremely fast
>> <https://en.wikipedia.org/wiki/November_2015_Paris_attacks> in all
>> languages !!!
>> After some mourning period, the note below may be replaced by this (but
>> how?):
>> Attentats du 13 novembre 2015 en Île-de-France
>> <https://fr.wikipedia.org/wiki/Attentats_du_13_novembre_2015_en_%C3%8Ele-de-France>
>>
>> I have just uploaded this change set (scroll down the left pane):
>> Our deepest condolences about the horrible terrorist attacks that
>> happened here on 2015-11-13.
>> <http://www.openstreetmap.org/changeset/35307155>
>> It adds the following note <http://wiki.openstreetmap.org/wiki/Key:note>
>> to the OSM elements at the 6 attacked locations.
>> (they were perfectly mapped, bravo)
>>> Nos plus sincères condoléances à propos des monstrueuses attaques
>>> terroristes qui ont eu lieu ici le 2015-11-13. Vous avez l'amitié de
>>> tous les contributeurs à OpenStreetMap de par le monde.
>> In their language.  Sorry no room for added English in <256 characters. 
>> Translates to:
>> Our deepest condolences about the horrible terrorist attacks that
>> happened here on 2015-11-13.
>> Receive the friendship of all the Openstreetmap contributors around the
>> world.
>>
>> Please forward this to other concerned OSM mailing lists.
>> Please let me know any change you come to an agreement with.
>> I will make any change easily using my *.osm file.
>>
>> By Monday, you may like to send the URL to the Press.
>> It won't be bad advertising for OpenStreetMap to show the places and to
>> join the world's cry .
>> But let us hope that vandalism will not be added to terrorism.
>>
>> Cheers
>>
>> André.
>>
>>
>

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

[OSM-talk-be] Friendliness with attacked mapped places in Paris

[André Pirard]

Hi,

OpenstreetMap often extends friendliness by humanitarian tagging.
In this case of desolation, there is little to tag.  Little...
Wikipedia have been extremely fast
 in all
languages !!!
After some mourning period, the note below may be replaced by this (but
how?):
Attentats du 13 novembre 2015 en Île-de-France


I have just uploaded this change set (scroll down the left pane):
Our deepest condolences about the horrible terrorist attacks that
happened here on 2015-11-13.

It adds the following note 
to the OSM elements at the 6 attacked locations.
(they were perfectly mapped, bravo)
> Nos plus sincères condoléances à propos des monstrueuses attaques
> terroristes qui ont eu lieu ici le 2015-11-13. Vous avez l'amitié de
> tous les contributeurs à OpenStreetMap de par le monde.
In their language.  Sorry no room for added English in <256 characters. 
Translates to:
Our deepest condolences about the horrible terrorist attacks that
happened here on 2015-11-13.
Receive the friendship of all the Openstreetmap contributors around the
world.

Please forward this to other concerned OSM mailing lists.
Please let me know any change you come to an agreement with.
I will make any change easily using my *.osm file.

By Monday, you may like to send the URL to the Press.
It won't be bad advertising for OpenStreetMap to show the places and to
join the world's cry .
But let us hope that vandalism will not be added to terrorism.

Cheers

André.


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

[OSM-talk-be] Does Google lack data?

[André Pirard]

Hi,

I've been surprised when Searching Google for Щорса Кричев

to find the result Остановка - Щорса - Кричев - WikiRoutes.info

which is a map containing the Google Logo but an OSM map (and Copyright,
is the logo decent?).
And notice that it's not an OSM background layer as usual, but OSM
itself !!!
(I wonder what routing that is. Beware, it's for public transport.)

Not believing my eyes, I made the request for Красная площадь wikiroutes

which is the Red Square.
and this time an answer was:  Остановка - Красная площадь - Москва -
WikiRoutes.info 
which is now a "real" Google map !!!

I seem to conclude that WikiRoutes.info uses Google when it contains
data and OSM otherwise.

And indeed Кричев is a place where friends of mine live and OSM is the
only way to see their house and neighbourhood. I wanted to add some
street names with the help of my friends and when I came back some time
later, it was already done, and beyond.

This should encourage us to continue, especially in under-mapped areas.

André.


  * Russian - detected
  * English

  * English


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

Re: [OSM-talk-be] IGN/NGI/NGI/NGI too now using OpenStreetMap

[André Pirard]

On 2015-09-06 23:54, Nicolas Pettiaux wrote :
> Dear 
>
> In March, I have met the directeur général adjoint of IGN during a
> meeting about GIS in Belgium where I represented the OSM.BE team (Ben
> had been invited too and I have coordinated with him) and he let me
> know that he would be willing to share data with us.
>
> We could prepare to go and meet officially (as the OSM-be
> representatives) IGN to discussi licences, compatibility and mutual help.
>
> Who is interested ?
The IGN/NGI is a most important source of information indeed.
I'm very surprised that no one else replied.
Thanks.  Keep us informed.

But the first thing to know is if what we do isn't allowed already, like
for the SPW.
IGN states conditions almost as vague as the SPW.
For the SPW, now that we know that "we cannot copy yet" isn't true and
now that the SPW fixed the PICC bug that I have asked 5 years ago (and
that was being laughed at), we can now redo with JOSM with a 20cm
precision much of the work that was made over 5 years with a 2 to 5 m
error and more with other editors.

Cheers

André.


>
> Best regards,
>
> Nicolas
>
> Le dim 6 sep 2015 à 21:45, André Pirard  a
> écrit :
>> Hi,
>>
>> In their now official Cartesius project
>> <http://www.cartesius.be/CartesiusPortal/>, IGN/NGI/NGI/NGI et al.
>> too are now using OpenStreetMap
>> <http://www.cartesius.be/arcgis/home/webmap/viewer.html?> (click
>> Basemap).
>>
>> It would have been surprising that NGI did not display the OSM ©
>> notice ;-)
>> Please notice that they reproduce without a frown the OSM mapping of
>> the so-called © NGI boundaries that we "cannot copy yet" (belonging
>> to the various successive governments (French and Belgian mainly)) !
>>
>> Cheers ,
>>
>> André.
>>
>>

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

Re: [OSM-talk-be] IGN/NGI/NGI/NGI too now using OpenStreetMap

[André Pirard]

On 2015-09-06 23:54, Nicolas Pettiaux wrote :
> Dear 
>
> In March, I have met the directeur général adjoint of IGN during a
> meeting about GIS in Belgium where I represented the OSM.BE team (Ben
> had been invited too and I have coordinated with him) and he let me
> know that he would be willing to share data with us.
>
> We could prepare to go and meet officially (as the OSM-be
> representatives) IGN to discussi licences, compatibility and mutual help.
>
> Who is interested ?
The geographic sites conditions usually limit the vision of what is
conceivable to do with their maps to "you can print a map" (waste paper,
what about copying the picture to a smartphone/GSM instead?). But we
have learned after 5 years of "we cannot copy (yet)" that what the SPW
conditions do not say is that "what OSM is doing is not copying". Hence,
it would be *very interesting* indeed to *at least* know the
corresponding opinion of IGN/NGI about what we are doing.  And even more
that they are willing to share data as Minister Henry wad told to have
asked the SPW to do.
And, btw, to ask the Minister if the boundary data is the property of
IGN/NGI or theirs (btw, should I explain that if M. Henry is no longer
the right minister, his successor should be asked after crossing one's
fingers).
A typical case is this map
<http://www.ngi.be/testbed/wms/top10r_l08_fr?FORMAT=image/png&VERSION=1.1.1&SERVICE=WMS&REQUEST=GetMap&LAYERS=0&STYLES=&SRS=EPSG:3857&WIDTH=1000&HEIGHT=512&BBOX=688544.7507928,6539340.6438534,690990.7356980,6540563.6363060>
that can be obtained from here <http://www.ngi.be/testbed/pages>  (tag
Visualisez) (or otherwise).
What can exactly be done with it, especially the +++ borderlines beside
not printing it?
Compare it with others, help understanding others, correcting others,
... or, if, like the SPW secret, "être copiées et reproduites de manière
excessive" is not what OSM is doing?
I'd like to know that, as a contributor of 5000 km of very precisely
mapped Walloon borders, who would rectify other borders 10, 25, 50 m off
their location, I started with a 250m shift in Banneux.

The IGN/NGI is a most important source of information indeed.
Thanks.  Keep us informed.

Cheers

André.


>
> Best regards,
>
> Nicolas
>
> Le dim 6 sep 2015 à 21:45, André Pirard  a
> écrit :
>> Hi,
>>
>> In their now official Cartesius project
>> <http://www.cartesius.be/CartesiusPortal/>, IGN/NGI/NGI/NGI et al.
>> too are now using OpenStreetMap
>> <http://www.cartesius.be/arcgis/home/webmap/viewer.html?> (click
>> Basemap).
>>
>> It would have been surprising that NGI did not display the OSM ©
>> notice ;-)
>> Please notice that they reproduce without a frown the OSM mapping of
>> the so-called © NGI boundaries that we "cannot copy yet" (belonging
>> to the various successive governments (French and Belgian mainly)) !
>>
>> Cheers ,
>>
>> André.
>>
>>

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

Re: [OSM-talk-be] What is "The Smart Box" ?

[André Pirard]

On 26-09-15 11:41, Marc Gemis wrote:
> thanks
>
> since it is a "personal" device there is no need to map it imho.
No more than "personal" houses and their surrounding ;-)
In fact, it is a a kind of private letterbox.
BTW, it must be fun to use a 40×40 red letterbox (without a horn) as
one's own and watch what's dropped in it ;-)

Smile here.

André.


> m
>
> On Fri, Sep 25, 2015 at 10:30 PM, Gerard Vanderveken  > wrote:
>
> __
> This 
>
> Regards,
> Gerard
>
> Marc Gemis wrote:
>> Hallo,
>>
>> Anyone knows what a "The Smart Box" is ?
>> pictures [1], [2]
>>
>> and how do you map one ?
>>
>>
>> regards
>>
>> [1] 
>> https://xian.smugmug.com/OSM/OSM-2015/2015-OSM-Miscellaneous/i-RTTDHJR/0/O/20150922_200213_HDR.jpg
>> [2] 
>> https://xian.smugmug.com/OSM/OSM-2015/2015-OSM-Miscellaneous/i-q8kCgv3/0/O/20150922_200222_HDR.jpg
>> 
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-be
>>   
>

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

[OSM-talk-be] For Jo

[André Pirard]

For Jo
.

André.


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

[OSM-talk-be] For Jo

[André Pirard]

  
  
For
Jo.
  
  

  
André.
  

  
  

  


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

[OSM-talk-be] IGN/NGI/NGI/NGI too now using OpenStreetMap

[André Pirard]

Hi,

In their now official Cartesius project
, IGN/NGI/NGI/NGI et al. too
are now using OpenStreetMap
 (click Basemap).

It would have been surprising that NGI did not display the OSM © notice ;-)
Please notice that they reproduce without a frown the OSM mapping of the
so-called © NGI boundaries that we "cannot copy yet" (belonging to the
various successive governments (French and Belgian mainly)) !

Cheers ,

André.



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

Re: [OSM-talk-be] missing affiliation on BIPT website

[André Pirard]

On 2015-08-27 07:26, Nicolas Pettiaux wrote :
> Thanks Olivier for letting us know
>
> I know personnally a member of the board of IPBT (Charles Cuvelliez,
> see http://www.bipt.be/fr/operateurs/ibpt/le-conseil) whom I can
> contact on behalf of the OSM-be community to say something like "We
> appreciate that OSM be used by IBPT but we would like that OSM be
> properly cited as requested by the licence".
>
> Would any of you have ideas or suggestions (and the time) to
> contribute to the letter that I would send ?
Yes, you might ask him if, in return of the help we bring, IBPT would
let us import and update their antenna data.
They would in turn benefit from that in being able to display antennas
on that map right from OSM.
I once tried to get in contact with their official e-mail address but
they did not reply.
Trying to convince someone of them would be a more successful way.
The SPW contains an antenna map (cadastre), but not all the details the
IBPT could provide.
In case of reluctance, but only then, tell them that they can restrict
the data they send us (or let us use).
The minimum is obviously the coordinates.  They have address, operators,
IDs  and maybe more.

Thanks for doing this,

Cheers

André.


Note; we call that "attribution".

>
> Best regards,
>
> Nicolas

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

Re: [OSM-talk-be] Relaties aanpassen

[André Pirard]

On 2015-08-26 22:02, Tom Lauwereins wrote :
> Hoi
>
> Ik zou enkele relaties moeten aanpassen (wijzigingen in
> fietsknoopuntennetwerk en fietsroutes)
> Kan iemand me zeggen wat de makelijkste manier is om dit te doen. Waar
> vind ik ergens een handleiding. Ik heb een beetje schrik dat ik de
> hele relatie kapot ga maken.
>
> Ik werk nu met Potlatsh2, maar misschien gaat dit makkelijker met een
> andere editor.
>
Hi,

Read instructions here

and if more are necessary, the best idea is to ask to add them for the
whole world's benefit.
Including Comparison of editors
 answering
your question, that ID and Potlatch are not well suited for power users.
You will find the Belgian
Cycle_Routes
Conventions
here

 
for the benefit of whole Belgium.

Cheers

André.



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

Re: [OSM-talk-be] POIs

[André Pirard]

On 2015-07-27 18:56, Jo wrote :
> In the case of Openstreetmap (and of Google), this is 1 entity which
> have several servers.
> In the case of Overpass API, these are different parties running
> (possibly different versions) of the same software. They may have
> different policies for updating the data or for the region they
> deliver services for.
Je sais, mais tous ces problèmes sont solubles.
Ce que j'imagine, c'est une amorce de solution de farming auquel
pourraient, sachant que faire, venir s'ajouter petit à petit des
machines ayant des ressources matérielles libres et travaillant en
miroir, plutôt que de stagner dans l'immobilisme d'un ou deux serveurs
surmenés.
Ce serait dommage que openpoimap devienne populaire, qu'il atteigne un
seuil critique d'engorgement des serveurs et qu'on demande de le supprimer.

André.


> For software/services where this doesn't matter, it's still possible
> to try and use the servers with a fallback system. If one doesn't
> answer, try another.
>
> Jo
>
> 2015-07-27 18:47 GMT+02:00 André Pirard  <mailto:a.pirard.pa...@gmail.com>>:
>
> On 2015-07-25 22:01, Marc Zoutendijk wrote :
>> Recently OSMF asked for money to support their servers and within
>> short time they collected that money from the community.[1]
>> Don't you think that if a service (like overpass) is succesfull
>> and really needed, they should do everything possible to improve
>> that service and keep it for the community?
> This is already possible somehow for no money.
> It might be suggested that all the servers running overpass be
> accessed with a single DNS name like overpass.openstreetmap.org
> <http://overpass.openstreetmap.org> that would contain, with a
> short TTL,  the IP addresses, or, better, the true names of all
> the overpass servers that can be used.
> This would not only balance the load across the servers, but also
> free the developers from updating their applications when servers
> close or open (and get removed from/added to that list), and let
> the application continue to work if a server is temporarily
> unavailable (an application is supposed to try all the IP
> addresses until they get a reply).
>
> I guess the person to ask directly is (if he replies):
>> $ dig openstreetmap.org <http://openstreetmap.org> SOA
>>
>> ;; ANSWER SECTION:
>> openstreetmap.org <http://openstreetmap.org>.2560IN  
>>  SOAa.ns.bytemark.co.uk <http://a.ns.bytemark.co.uk>.
>> *hostmaster.openstreetmap.org
>> <http://hostmaster.openstreetmap.org>*.
>
> That is what OSM.org already does with 3 servers (addresses in bold):
>
>> $ dig www.openstreetmap.org <http://www.openstreetmap.org> A
>> @a.ns.bytemark.co.uk <http://a.ns.bytemark.co.uk>
>>
>> ; <<>> DiG 9.8.1-P1 <<>> www.openstreetmap.org
>> <http://www.openstreetmap.org> A @a.ns.bytemark.co.uk
>> <http://a.ns.bytemark.co.uk>
>> ;; global options: +cmd
>> ;; Got answer:
>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26370
>> ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3, ADDITIONAL: 7
>> ;; WARNING: recursion requested but not available
>>
>> ;; QUESTION SECTION:
>> ;www.openstreetmap.org <http://www.openstreetmap.org>.INA
>>
>> ;; ANSWER SECTION:
>> www.openstreetmap.org <http://www.openstreetmap.org>.600  
>>  INA*193.63.75.103*
>> www.openstreetmap.org <http://www.openstreetmap.org>.600  
>>  INA*193.63.75.99*
>> www.openstreetmap.org <http://www.openstreetmap.org>.600  
>>  INA*193.63.75.100*
>>
>> ;; AUTHORITY SECTION:
>> openstreetmap.org <http://openstreetmap.org>.259200IN  
>>  NSa.ns.bytemark.co.uk <http://a.ns.bytemark.co.uk>.
>> openstreetmap.org <http://openstreetmap.org>.259200IN  
>>  NSb.ns.bytemark.co.uk <http://b.ns.bytemark.co.uk>.
>> openstreetmap.org <http://openstreetmap.org>.259200IN  
>>  NSc.ns.bytemark.co.uk <http://c.ns.bytemark.co.uk>.
>>
>> ;; ADDITIONAL SECTION:
>> a.ns.bytemark.co.uk <http://a.ns.bytemark.co.uk>.86400  
>>  INA80.68.80.26
>> a.ns.bytemark.co.uk <http://a.ns.bytemark.co.uk>.86400  
>>  IN2001:41c8:2::3
>> a.ns.bytemark.co.uk <

Re: [OSM-talk-be] POIs

[André Pirard]

  
  
On 2015-07-25 22:01, Marc Zoutendijk
  wrote :


  
Recently OSMF asked for money to support their servers and
  within short time they collected that money from the
  community.[1]
Don't you think that if a service (like overpass) is
  succesfull and really needed, they should do everything
  possible to improve that service and keep it for the
  community?
  

This is already possible somehow for no money.
It might be suggested that all the servers running overpass be
accessed with a single DNS name like overpass.openstreetmap.org that
would contain, with a short TTL,  the IP addresses, or, better, the
true names of all the overpass servers that can be used.
This would not only balance the load across the servers, but also
free the developers from updating their applications when servers
close or open (and get removed from/added to that list), and let the
application continue to work if a server is temporarily unavailable
(an application is supposed to try all the IP addresses until they
get a reply).

I guess the person to ask directly is (if he replies):
$ dig openstreetmap.org SOA
  
  ;; ANSWER SECTION:
  openstreetmap.org.    2560    IN    SOA    a.ns.bytemark.co.uk. hostmaster.openstreetmap.org.
  


That is what OSM.org already does with 3 servers (addresses in
bold):

$ dig www.openstreetmap.org A
@a.ns.bytemark.co.uk
  
  ; <<>> DiG 9.8.1-P1 <<>>
www.openstreetmap.org A @a.ns.bytemark.co.uk
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status:
NOERROR, id: 26370
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 3, AUTHORITY: 3,
ADDITIONAL: 7
  ;; WARNING: recursion requested but not available
  
  ;; QUESTION SECTION:
  ;www.openstreetmap.org.        IN    A
  
  ;; ANSWER SECTION:
  www.openstreetmap.org.    600    IN    A    193.63.75.103
  www.openstreetmap.org.    600    IN    A    193.63.75.99
  www.openstreetmap.org.    600    IN    A    193.63.75.100
  
  ;; AUTHORITY SECTION:
  openstreetmap.org.    259200    IN    NS  
 a.ns.bytemark.co.uk.
  openstreetmap.org.    259200    IN    NS  
 b.ns.bytemark.co.uk.
  openstreetmap.org.    259200    IN    NS  
 c.ns.bytemark.co.uk.
  
  ;; ADDITIONAL SECTION:
  a.ns.bytemark.co.uk.    86400    IN    A    80.68.80.26
  a.ns.bytemark.co.uk.    86400    IN      
 2001:41c8:2::3
  a.ns.bytemark.co.uk.    86400    IN    A    80.68.80.26
  b.ns.bytemark.co.uk.    86400    IN    A    85.17.170.78
  c.ns.bytemark.co.uk.    86400    IN    A    80.68.80.27
  c.ns.bytemark.co.uk.    86400    IN      
 2001:41c8:2::5
  c.ns.bytemark.co.uk.    86400    IN    A    80.68.80.27
  
  ;; Query time: 47 msec
  ;; SERVER: 80.68.80.26#53(80.68.80.26)
  ;; WHEN: Mon Jul 27 18:09:22 2015
  ;; MSG SIZE  rcvd: 288

and Google with 36 servers ...

Cheers



  

  André.

  


$ dig mts.google.com @ns1.google.com
  
  ; <<>> DiG 9.8.1-P1 <<>>
mts.google.com @ns1.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status:
NOERROR, id: 21896
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0,
ADDITIONAL: 0
  ;; WARNING: recursion requested but not available
  
  ;; QUESTION SECTION:
  ;mts.google.com.            IN    A
  
  ;; ANSWER SECTION:
  mts.google.com.        604800    IN    CNAME  
 mts.l.google.com.
  mts.l.google.com.    300    IN    A    194.78.0.231
  mts.l.google.com.    300    IN    A    194.78.0.224
  mts.l.google.com.    300    IN    A    194.78.0.244
  mts.l.google.com.    300    IN    A    194.78.0.217
  mts.l.google.com.    300    IN    A    194.78.0.223
  mts.l.google.com.    300    IN    A    194.78.0.245
  mts.l.google.com.    300    IN    A    194.78.0.230
  mts.l.google.com.    300    IN    A    194.78.0.251
  mts.l.google.com.    300    IN    A    194.78.0.210
  mts.l.google.com.    300    IN    A    194.78.0.237
  mts.l.google.com.    300    IN    A    194.78.0.238
  mts.l.google.com.    300    IN    A    194.78.0.216
  
  ;; Query time: 41 msec
  ;; SERVER: 216.239.32.10#53(216.239.32.10)
  ;; WHEN: Mon Jul 27 18:21:45 2015
  ;; MSG SIZE  rcvd: 244
  
  $ dig mts0.google.com @ns1.google.com
  
  ; <<>> DiG 9.8.1-P1 <<>>
mts0.google.com @ns1.google.com
  ;; global options: +cmd
  ;; Got answer:
  ;; ->>HEADER<<- opcode: QUERY, status:
NOERROR, id: 36260
  ;; flags: qr aa rd; QUERY: 1, ANSWER: 13, AUTHORITY: 0,
ADDITIO

Re: [OSM-talk-be] POIs

[André Pirard]

  
  
On 2015-07-25 22:01, Marc Zoutendijk
  wrote :


  
  I am the developper of openpoimap,
  

And I congratulate you deeply.
Myself and on behalf of all the non-OSM computer geeks that I let
know OPM.
All replied that they are amazed and in love.
 C'est une très bonne découverte: vraiment
  très pratique et j'aime beaucoup, surtout avec la base HikeBike ou
  Mapnik.



  

  André.

  


  


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