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?_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=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=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_source=sendgrid.com_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_source=sendgrid.com_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

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 

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 

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=fr=auto%7Cen=1=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 <a.pirard.pa...@gmail.com
> <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.
> 

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 <a.pirard.pa...@gmail.com
> <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
<wms:http://geoservices.wallonie.be/arcgis/services/TOPOGRAPHIE/PICC_VDIFF/MapServer/WmsServer?SERVICE=WMS=1.1.1=image/png8=TRUE=GetMap==%7Bproj%7D=%7Bwidth%7D=%7Bheight%7D=%7Bbbox%7D=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=photo=50.86767032=4.3280441=17=0.510308202857=0.4999=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=next=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] 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" <a.pirard.pa...@gmail.com> 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 <a.pirard.pa...@gmail.com
>> <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 about it, It would 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%0Aout%20body%3B%0A%3E%3B%0Aout%20skel%2

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]

roblems 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 <seppe.sant...@stad.gent> 
>> 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 <vdmfrank...@gmail.com>:
>>>> 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] 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] [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 <a.pirard.pa...@gmail.com
> <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 <a.pirard.pa...@gmail.com
> <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. Right now, the list is not complete and The N

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=BL83OJVENO>
(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=BL83OJVENO>
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 French, I'll
>> translate it to English for him.

[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] 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-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 = 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 = 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] 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=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?=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 <a.pirard.pa...@gmail.com 
<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
<a.pirard.pa...@gmail.com> <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

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 <a.pirard.pa...@gmail.com
> <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

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] 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 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-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=1.3.0=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] 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 <a.pirard.pa...@gmail.com
> <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=1.3.0=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 dernie

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=1.3.0=GetCapabilities
>
> Julien
>

___
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

[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

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] 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.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é.
>>
>>

___
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=1.1.1=WMS=GetMap=0==EPSG:3857=1000=512=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.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é.
>>
>>

___
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] 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
https://www.google.be/search?q=how+to+edit+relations+openstreetmap
and if more are necessary, the best idea is to ask to add them for the
whole world's benefit.
Including Comparison of editors
http://wiki.openstreetmap.org/wiki/Comparison_of_editors answering
your question, that ID and Potlatch are not well suited for power users.
You will find the Belgian
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_RoutesCycle_Routes
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_RoutesConventions
here
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes
 
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] 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 http://www.sites.bipt.be/index.php?language=FR 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] 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 a.pirard.pa...@gmail.com
 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 http://a.ns.bytemark.co.uk.86400  
  INA80.68.80.26
 b.ns.bytemark.co.uk http://b.ns.bytemark.co.uk.86400  
  INA85.17.170.78
 c.ns.bytemark.co.uk http://c.ns.bytemark.co.uk.86400  
  INA80.68.80.27
 c.ns.bytemark.co.uk http://c.ns.bytemark.co.uk.86400  
  IN2001:41c8:2::5
 c.ns.bytemark.co.uk http://c.ns.bytemark.co.uk.86400  
  INA80.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 http://mts.google.com @ns1.google.com
 http://ns1.google.com

 ;  DiG 9.8.1-P1  mts.google.com http

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,
ADDITIONAL: 0
  ;; WARNING: recursion 

Re: [OSM-talk-be] POIs

[André Pirard]

Hi,

My point was that, in this civilization, people are perfectly happy with
many bad links in Wikipedia or elsewhere.
(I, personally, would run a program to check them)
Now, if you want to digress...

On 2015-07-24 21:32, Ruben Maes wrote :
 Op vrijdag 24 juli 2015 heeft André Pirard a.pirard.pa...@gmail.com
 mailto:a.pirard.pa...@gmail.com het volgende geschreven:

  FYI, I once wrote an improvement to a Wikipedia page.  A
 self-appointed vigilante came down on me and accused be of
 self-research (what I wrote was as verifiable as 1+2=3). I was
 requested to add a link to a page saying 1+2=3.  I replied that what I
 said could be proved, and that, of the existing 3 links in the page, 3
 were incorrect.

 That's because Wikipedia does not aim to tell the truth, they want to
 summarize what can be found in other sources[1]. That's why you have
 to add sources for everything except for the most trivially
 verifiable[2]. Even if you know/think you're right. ;)

 [1] https://en.wikipedia.org/wiki/WP:TRUTH
 [2] https://en.wikipedia.org/wiki/WP:VER
I know that, but I find that those words of Wikipedia you summarize
nicely are complete nonsense in the case everyone would find unnecessary
or even stupid to write that source.
The points of my contribution were:

  * That Google Translation is a two (at least) step process,
translating source to destination via en  s - en - d.
No one would have written that except an Ukrainian explaining : s -
en - ru - uk.
The vigilante's question was how do you know?
I finally imagined to provide as source[1] the URL of a few
translation cases like this:
/le mot 'obvious' n'est pas français → очевидными слово не
французское

https://translate.google.com/#fr/ru/le%20mot%20%27obvious%27%20n%27est%20pas%20fran%C3%A7ais
/Not finding 'obvious' in the French dictionary when translating to
English, GT leaves it untranslated./
/Finding 'obvious' in the English dictionary when translating to
Russian, GT translates it.
Since my explanation, contributors seem to speak of that 2-step
process without citing a source and without any vigilante intervention.
  * The Google Translation methodology ignores the grammar and fails
when the grammar, e.g. declensions, is necessary to understand the
phrase.  Again, I provided the URL of a Russian to English
translation saying exactly the opposite of the original text because
GT was based on the order and not the declensions of the words.

In short, I find excellent to request providing sources but I find
stupid to, when there are no sources, forbid to say something true that
everyone will learn, understand and agree.
If we were allowed to say only what someone else already said, no one
would speak.

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

Re: [OSM-talk-be] POIs

[André Pirard]

On 2015-07-24 10:08, Marc Gemis wrote :

 On Fri, Jul 24, 2015 at 9:58 AM, André Pirard
 a.pirard.pa...@gmail.com mailto:a.pirard.pa...@gmail.com wrote:

 May I recall another approach that I presented as a way for OSM.be
 to make money.
 For each customer or usage, a POI list is built that contains
 the IDs of the OSM elements + icon URL.
 The server whose task is to display the map + POIs can fetch the
 list from any URL.
 http://server  http://list
 node/way/area ID icon_URL


 As you know, the ID of OSM elements is not stable, so you can't really
 use them in queries.
 Is this similar to creating an Overpass Query with some mapcss  and
 share that link ?
 I'll agree that creating the Overpass Query might be simplified with
 e.g. picking POIs from a list.

The list approach is for s.o. to show their selection: all shops X,
municipality shops..., nearby bus stops, whatever?
Such a list needs maintenance, the POIs are changing much more often
than the IDs and there can be warnings.
The URLs are not stable either, so you can't really use them for links.
People don't use the possibility to be warned when a link dangles, there
are plenty of blind links, and yet that link system is used intensively.

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-24 08:55, Marc Zoutendijk wrote :
 Op 24 jul. 2015, om 07:16 heeft Marc Gemis marc.ge...@gmail.com het 
 volgende geschreven:


 Joost Schouppe heeft eventjes een vergelijking gemaakt voor Antwerpen: 
 slechts 37 van de 294 bakkers zouden gemapped zijn.

 Dus als POIs je ding zijn, dan mag je gerust zijn, er is nog werk genoeg :-)


 En met openpoimap (http://openpoimap.org) kun je ze ook mooi zichtbaar maken:
 https://dl.dropboxusercontent.com/u/17226226/OSM/bakkersantwerpen.png

 Joost Schouppe ran a test on bakeries in Antwerp. Only 37 of the 294 
 bakeries are mapped.

 So, when you love to map POIs, you'll still have plenty of work :-)

 openpoimap (http://openpoimap.org) is a great tool to show them all:
 https://dl.dropboxusercontent.com/u/17226226/OSM/bakkersantwerpen.png

 Marc.
Lovely, welcome info forwarding, Marc.  And congratulations !!!

Impressive but ouch, Marc #2, they use overpass, and extensively.
If everybody were using their page much, overpass would soon be on their
knees.

I think that how to use POIs should be thought out before making them.
It's great how a GPS uses a selection offline and how a Web display
could do the same.
But they use predetermined kinds of POIs that they selected as data they
store locally.
May I recall another approach that I presented as a way for OSM.be to
make money.
For each customer or usage, a POI list is built that contains the IDs
of the OSM elements + icon URL.
The server whose task is to display the map + POIs can fetch the list
from any URL.
http://server  http://list
node/way/area ID icon_URL
...
For speed and to spare the sources, it can build a cache.

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-24 12:04, Marc Gemis wrote :


  Are you

  On Fri, Jul 24, 2015 at 11:47 AM,
André Pirard a.pirard.pa...@gmail.com
wrote:

  
  The URLs are not stable either, so you can't
really use them for links. People don't use the
possibility to be warned when a link dangles, there
are plenty of blind links, and yet that link system
is used intensively.
  
 
  



Are you saying that URLs like http://overpass-turbo.eu/s/azw
  are discarded after awhile ? I didn't know that. I've
  bookmarked several queries like that, so I need to find
  another way to keep them.

  

  

No. Not particularly speaking of that. I don't know if/when they
discard and I myself don't wonder because I simply use the expanded
or clear request. This is the same as your example.
http://overpass-turbo.eu/?q=PCEtLQpUaGlzIHF1ZXJ5IGxvb2vEiGZvciBub2Rlcywgd2F5xIjEliByZWxhdGlvbsSICndpdGggxLJlIGdpdmVuIGtleS92YWzEiyBjb21iaW7EqcSrbi4KQ2jEkXPEtnlvdcSXxKbEuMSsIGFuZCDEhnTEtGjEtlJ1xLxidXR0xZ1hYm_EuiEKxII-Cnt7xL55PcWxxalkYcSNfX3FuHvFgsWEZT1wb3N0xYNfxYfEm8aDxoV0eXDGicSmxKjEqsSsxpM8xoxtLXNjcmlwxaTFmHRwxaw9ImpzxKwixbcgIDzEisSMxI7GlcaXxqzFuca5ZcaDxrEKxrPGszxoYXMta3bEvca7xbrEv8a_IHbHjMaHxIvGvy_GsseCPGLFsXgtxrbEjSDFuceab3jGg8eWx4HG
tC_HnnnHlzxwxqRuxaRtxJrGiSLFsWR5Isemx4PEpmPFmcWVxLTGlse0ZG93bse5x6zHrsWLx7HHs8asc8S-bGXFrsiGx6Y8L8afxqHGo8aldD4

I was saying that the Web is crowded with invalid links, that people
are happy with that fuzzy situation and that, unlike what you said,
a few wrong IDs, much less than wrong links, do not make using IDs a
wrong method.

FYI, I once wrote an improvement to a Wikipedia page.  A
self-appointed vigilante came down on me and accused be of
self-research (what I wrote was as verifiable as 1+2=3). I was
requested to add a link to a page saying 1+2=3.  I replied that what
I said could be proved, and that, of the existing 3 links in the
page, 3 were incorrect.
The Internet is full of contradictors.

Cheers



  

  André.

  



  


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

Re: [OSM-talk-be] Someone a idea when the cycling map is renderd

[André Pirard]

  
  
On 2015-07-12 09:49, Jakka wrote :

Hi,
  
  
  Someone a idea when the cycling map is renderd, had to change/move
  two "knooppunten" 91 79 wrong places and adapt there relations?
  
  Do not want to lose contact with person who show the mistake.
  
  Changes made Saturday 11/7 in afternoon.
  
  
  http://www.openstreetmap.org/#map=15/50.7392/3.6310layers=CN
  

FYI, if that's equivalent for you,
http://cycling.waymarkedtrails.org/en/?zoom=15lat=50.7392lon=3.6310
update at least 1/24h.  Last update: July 12, 2015 11:07 UTC.


  

  André.

  



  


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

Re: [OSM-talk-be] Josm: aerial images as layer

[André Pirard]

On 2015-06-21 10:32, Jakka wrote :
 Are these links/image layers automatic update?
I suppose you speak of new map versions on the servers.
 ...

 Wallonie part

 Geoservices Wallonie aerial imagery
 wms:http://geoservices.wallonie.be/arcgis/services/IMAGERIE/ORTHO_2012_2013/MapServer/WMSServer?FORMAT=image/bmpVERSION=1.1.1SERVICE=WMSREQUEST=GetMapLAYERS=0STYLES=SRS={proj}WIDTH={width}HEIGHT={height}BBOX={bbox}
You should use JOSMImagery... Preferences... providersselectActivate
I have highly optimized them and, for example, your bmp uses much bigger
tiles than jpeg.

The SPW map catalog is here http://geoportail.wallonie.be/home.html,
with publication dates.
I have asked their helpdesk how to be warned of new releases, e.g. a
mailing list.
No reply.  Anybody knows?  RSS?

Jakka, do I really scare newcomers?

André.



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

Re: [OSM-talk-be] SPW PICC 2000 map on JOSM (not 2000)

[André Pirard]

On 2015-06-04 14:57, Julien Fastré wrote :
 Hi Erik,

 This licence applies to the visualization service :
 http://geoportail.wallonie.be/files/LicServicesSPW.pdf

 The text is quite uncomprehensible. I had a discussion with them that it
 is not forbidden if you copy that on a map and mix with other data (what
 we do in OSM).
Hi Julien,

This is what I see (as conditions particulières I suppose) (my display
set to English language):

Conditions d'accès et d'utilisation
- Aucune contrainte d'accès pour la consultation
- Les termes de la licence s'appliquent.
http://geoportail.wallonie.be/files/LicData.pdf
- Les termes de la licence s'appliquent.
http://geoportail.wallonie.be/files/LicData.pdf
Obtaining formalities   
Pour toutes demandes, complétez le formulaire de licence
(http://geoportail.wallonie.be/files/LicData.pdf) et l'envoyer à
helpdesk.ca...@spw.wallonie.be

But I see absolutely no explanation of what consultation and license
allow to do.

You once wrote that Minister Henry has told SPW (his department) to open
all their data.
And later that we can now copy the data.

Maybe Minister Henry should be asked to be sure that the answer is what
he wants.
Also making sure that the boundary data belongs to the Belgian people
represented by its government.

To put an end to these endless discussions (repeated for every server),
I have once opened a JOSM ticket suggesting that JOSM could read the ©
information from where it belongs in the server meta-data and display it
to the JOSM user on first use of the server, any time the © is modified
and on request.
The ticket was closed with wontfix status.  That doesn't make © seem
an important topic.
The PICC meta-data contains:
Fees/FeesAccessConstraints/AccessConstraints
In which case JOSM should automatically suggest the user to send a
prepared e-mail to
ContactElectronicMailAddresshelpdesk.ca...@spw.wallonie.be/ContactElectronicMailAddress
suggesting them to fill meta-data as AccessConstraints©-URL
Iso-date/AccessConstraints
and referring to an OpenStreetMap document explaining what ©-URL should
explain clearly for OSM usage.

These are facts and is is in no way trying to convince that anybody is
doing bad job as you claim, but is my usual suggestions to improve the
situation.
Unfortunately, they cannot be written in two lines as you request, just try.

PS: I made a confusion when calling it PICC 2000 with DWG 2000 which is
a data distribution format.
PICC was created in 1991 and the last data update is 2015-01-08.
But that does not say what exactly was updated and I don't see in PICC
houses that are built for a long time, hence my confusion.
Anyway, checking with the aerial layer is necessary, that's a reason why
I made PICC transparent.

André.








 Julien

 Le 29/05/15 21:21, Erik Beerten a écrit :
 Hello,

 I am Flemish but regularly mapping things in the south of Belgium.
 To be clear, is it correct that all map data on the Walloon PICC 2000
 (including the shape of the buildings) are free for copying to OSM?
 PICC is about the same as the Flemish AGIV GRB map but the building
 shapes on that map may not be copied.

 Regards,

 Erik




 Op 23-05-15 om 18:14 schreef André Pirard:
 On 2015-05-15 15:13, Nicolas Pettiaux wrote :
 Dear all,

 I want to learn how to use JOSM and benefit from your work, and use
 the belgian settings whatever this is that as I suppose simplify
 the tasks.
 ...
 Bon maintenant,

 Regarding the Belgian settings, I have mentioned before that JOSM
 requires WMS EPSG:4326/3857 and reported to SPW in 2010 and here later
 that the best WA server, which was the PICC server, returned blank
 4326 tiles. It even contained many WMS configuration errors such that
 JOSM failed to configure it automatically.  There have been no
 follow-ups to those comments, just that they are not interesting.
 I have lately discovered purely by chance that the PICC bugs are now
 corrected. It's possible to configure it with JOSM.

 The optimized PICC configuration can be installed with:
 JOSMImageryImagery PreferencesRefresh
 JOSMImageryImagery Preferencesselect BE|SPW(allonie) PICC 2000
 numerical imageryActivate

 You may want to remove layer 49 to prevent redundant street names
 obscuring the highways:
 In ...Selected entries:SPW(allonie) PICC...double-click column 2,
 edit 49, out, return ... OK
 Place names are in layers 56-60.

 The maximum zoom is 21.
 I have filed a request that JOSM scaled the images above that zoom.
 This will be done in June (JOSM guys are really great!).  While waiting:
 JOSMWindowsLayersright-click SPW...PICC...turn OFF: Automatically
 change resolution
 JOSMView/Jump to Positionmap=21... or zoom=5 metres
 (repeat each time the layer is added)

 That PICC data is old (2000 I think, missing houses etc.).
 I wish the more recent BASE imagery were available for JOSM.
 But these do not support WMS EPSG:4326/3857 (;-) ).
 PICC has a wonderful 25 cm precision.

 May I recall that (airplane) *aerial **photographs

Re: [OSM-talk-be] Wallonie picarde à vélo / ODBL compatible ?

[André Pirard]

On 2015-05-26 23:13, Matthieu Gaillet wrote :
  I'm currently busy mapping a huge cycling network in Wallonie
 Picarde http://www.openstreetmap.org/relation/4128428.
 ...
 — Ma question est la suivante :

 J’ai immédiatement demandé et obtenu l’autorisation d’intégrer les
 données du réseau sous license ODBL. Au fil de quelques
 correspondances avec l’administration wallonne, la personne qui
 m’avait officiellement donné accord pour intégrer les données m’a
 soudainement demandé *de signer une convention* pour pouvoir obtenir
 le dernier fichier correspondant aux données les plus à jour du réseau.

 Voici le texte de la convention (attachée ci-dessous) :

 ...

 • Le logo de l’IDETA (ou à défaut la mention « source : ©IDETA »)
 devra figurer sur toute sortie cartographique exploitant les données,
 de manière explicite et lisible. Il en va de même pour les
 partenaires de l’IDETA  qui sont à l’origine des données (cf. tableau
 de détail). Les conditions d’utilisations spécifiques aux
 fournisseurs sont mentionnées en annexe. Toute utilisation de ces
 données devra faire l’objet d’une demande écrite préalable à l’IDETA
 qui le cas échéant la transmettra au(x) propriétaire(s). Dans le cas
 de diffusion externe, un exemplaire de chaque document utilisant ces
 données sera adressé, au format papier ou numérique, à l’IDETA
 ...

 A votre avis, cette convention est-elle compatible avec la license
 ODBL ? Suis-je habilité à la signer ? Dans le cas contraire, quelle
 est la meilleure stratégie à observer ? 


Salut,

Je crois que, comme dans la plupart des conditions d'utilisation
cartographiques, cette convention est à 1000 lieues d'imaginer qu'on
puisse, je schématise, faire autre chose que de photocopier des cartes
papier. Vouloir mettre sur une carte OSM (un dessin) un © pour toutes
les sources des données qu'elle contient serait évidemment de la folie (1).

Les © (2) doivent en fait se trouver à côté des balades dans le tag
source=* et ne sont visibles que dans le panneau gauche de OSM.org ou
équivalent quand le lecteur a l'idée saugrenue de l'ouvrir.
Sauf que Polyglot dit que c'est dans dans les changesets que doivent se
trouver ces informations et qu'il y a encore moins de chances que
l'utilisateur ouvre l'history que le panneau de gauche, surtout quand
Polyglot utilise l'history pour communiquer ses états d'âme. Je vois mal
des services comme Waymarged Trails montrer l'history des balades dans
les changesets.
Sauf que les contributeurs OSM ne cessent de répéter qu'il n'y a pas de
carte et que OSM est un model of decoupling the factual mapping
database from the data consumers and their choices.
Marc Gemis expliquera en effet que l'utilisateur peut tout aussi bien
ouvrir openstreetmap.de et qu'il n'y verra pas de panneau gauche du tout.
Et tout cela est bien vrai pour les routes cyclistes, pédestres, etc.
car, à part le calque Cycle Map dans lequel je ne parviens pas à voir
des tags source, la meilleure manière de les voir est d'utiliser
Waymarked Trails
http://cycling.waymarkedtrails.org/en/?zoom=14lat=50.22969lon=5.3472hill=0#routes
dans lequel on voit (cliquer sur Route et puis sur une route) que
Polyglot n'a mis aucun © du tout.

Bref, OSM n'est pas une carte sur laquelle, comme le conçoit IDETA, on
écrit un ©, mais des données que vont utiliser d'autres personnes (les
consumers) pour (éventuellement) faire des cartes ou des produits
montrant ou devant montrer l'attribution des sources.
Et donc, si ce que IDETA impose est que ce © se trouve sur des cartes,
c'est à ces dernières autres personnes que IDETA doit faire signer une
convention, par exemple à Waymarked Trails
http://cycling.waymarkedtrails.org/en/?zoom=14lat=50.22969lon=5.3472hill=0#routes.
OSM n'agit en effet que comme un distributeur des données (de IDETA),
comme un grossiste, et lui faire signer une convention serait aussi
bizarre que de demander à un grossiste de signer un accord promettant
que les appareils vendus ne seront pas démontés.

Je crois donc que la meilleure tactique est:

  * comme il me semble être peine perdue de vouloir leur faire
comprendre tous les détails qui précèdent,  d'expliquer que OSM
intègre pas mal de données semblables à celles de IDETA sans
préjudice pour leurs auteurs et même plutôt à leur bénéfice et qu'il
serait dommage que leurs données ne bénéficient pas du même
traitement (améliorer, édulcorer au mieux cette formulation
sentimentale)
  * de leur expliquer de manière subtile que le texte de leurs
conditions ne correspond pas au fonctionnement de OSM et qu'il est
plus simple qu'ils signifient leur accord sur le texte clair d'ODBL
avec d'éventuels amendements non contradictoires.

Maintenant, un © ne peut pas modifier ses conditions en les
restreignant, il est définitif. Est-il bien nécessaire de chercher une
autre autorisation que celle que nous avons déjà (si celle-ci est valable)?

On 27 May 2015, at 23:24, Ben Abelshausen ben.abelshau...@gmail.com

Re: [OSM-talk-be] Wallonie picarde à vélo / ODBL compatible ?

[André Pirard]

On 2015-05-29 15:50, Marc Gemis wrote :

 2015-05-29 11:53 GMT+02:00 André Pirard a.pirard.pa...@gmail.com
 mailto:a.pirard.pa...@gmail.com:

 BTW, using registered letters makes me laugh.  One may claim that
 the envelope was empty.


 totally of topic,
Not off topic. It was part of a reply to a remark that your usual
incomplete quotation does not show.
 but the right way to do this is to only send the letter (folded and
 address on the same paper as the text) and not put it in an envelope.
And how does that prevent someone to claim that he received an empty
envelope?
As I have received all my registered letters in an envelope, you should
explain the whole world how to send registered letters correctly (while
I am explaining that e-mail is better).

Cheers

André.


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

[OSM-talk-be] For OSM copyright enforcers: strangest map yet

[André Pirard]

Hi,

I stumbled on this map http://www.balnam.be/boninne/sentier/21.
They've got the Google Pegman, markers, zoom bar and logo.
They've got a Google Terms of Use
https://www.google.com/intl/en_US/help/terms_maps.html.
But, gulp, the map is OSM (what I've just mapped, looked like an echo ;-) )

In fact, the map is multi-background.
There seems to be a cookie to remember your preference.
And the default preference was OSM as I got it from Google Search.

But yet...
Cheers

André.



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

Re: [OSM-talk-be] Osmand en JOSM

[André Pirard]

On 2015-05-15 08:21, Guy Vanvuchelen wrote :

 I am using:

 Smartphone Sony Xperia  model: ST21i

 Android-version: 4.0.4

 OsmAnd: 2.0.1 (2015-04-28)  with the earlier version (1.9)  it works
 perfect.

What is the JOSM version?
 I'm doing this and I see that.
How (which menus) do you produce the GPX file? What does JOSM when you
load the file?

Maybe the shortest path is to send me privately a GPX file that doesn't
load.
I'll try to load it and try the figure the difference with what you do.

Cheers

André.






  

  

  

 Guy Vanvuchelen

  

 *Van:*André Pirard [mailto:a.pirard.pa...@gmail.com]
 *Verzonden:* vrijdag 15 mei 2015 4:37
 *Aan:* OpenStreetMap Belgium
 *Onderwerp:* Re: [OSM-talk-be] Osmand en JOSM

  

 On 2015-05-14 17:28, Guy Vanvuchelen wrote :

 Sinds enkele dagen kan ik een GPX bestand dat gemaakt werd met
 Osmand niet meer rechtstreeks inladen in JOSM. Vroeger lukte dat wel.

 Als ik op de website http://www.gpsvisualizer.com/convert_input
 het GPX bestand inlees en terug bewaar als GPX bestand dan kan
 JOSM er ineens wel overweg mee.

 Ik hoorde van een collega mapper dat hij vandaag hetzelfde
 probleem ondervonden heeft. Weet iemand de oplossing of oorzaak?

  

 Ouch, my Thunderbird translator seems to be out of its mind. Google
 Translate speaking:

 For severaldays I a GPX file that was created with OsmAnd not directly
 loading into JOSM. Previously it was more feasible.

 When I'm on the website http://www.gpsvisualizer.com/convert_input GPX
 file read-in and back save as GPX file, then JOSM can handle it there
 once.

 I heard from a colleague mapper that he has encountered the same
 problem today. Does anyone know the solution or cause?

 No problem here to load an Osmand GPX file in JOSM.
 But the best method to describe a problem is I'm using version X of
 this and that, I'm doing this and I see that.
 If you do so, I might be able to compare and help you.

 Cheers

 André.

  


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

Re: [OSM-talk-be] Osmand en JOSM

[André Pirard]

On 2015-05-15 13:58, Guy Vanvuchelen wrote :

 JOSM: versie:8339

  

 A track in attachement.

OK, but you still don't reply the questions:

 I'm doing this and I see that.

Answer #2  is JOSM (mine 8109) issuing message
 Could not read file '2015-05-09_09-43_za.gpx'. Error is: null
The reason is that your GPX file contains references to .3gp video files
for some waypoints like
   wpt lat=... lon=...
 ...
name0EKtetAj---1.3gp/name
 link link=0EKtetAj---1.3gp /
   /wpt
but (probably) that there are no such files next to the .gpx file.
I ran the following filter
 perl -pe 's/link link=.* \///' 2015*.gpx fixed.gpx
to remove the link tags and fixed.gpx loaded fine into JOSM.

My Answer #2 is : 1) I created a route, 2) I opened Route details 3) I
clicked the share icon
and the produced file contains no links and loads fine.

You must see if your secret method to produce the GPX file has a way not
to contain the links, e.g. to have no videos attached, or try to move
the .3gp files alongside the .gpx.

You may send a summary of this reply as a JOSM ticket, they will
probably think it's a bug and fix it.

Hoping this will help,

Cheers

André.




  

  

 Thanks

  

 Guy Vanvuchelen

  

 *Van:*André Pirard [mailto:a.pirard.pa...@gmail.com]
 *Verzonden:* vrijdag 15 mei 2015 12:29
 *Aan:* OpenStreetMap Belgium
 *CC:* Guy Vanvuchelen
 *Onderwerp:* Re: [OSM-talk-be] Osmand en JOSM

  

 On 2015-05-15 08:21, Guy Vanvuchelen wrote :

 I am using:

 Smartphone Sony Xperia  model: ST21i

 Android-version: 4.0.4

 OsmAnd: 2.0.1 (2015-04-28)  with the earlier version (1.9)  it
 works perfect.

 What is the JOSM version?

 I'm doing this and I see that.

 How (which menus) do you produce the GPX file? What does JOSM when you
 load the file?

 Maybe the shortest path is to send me privately a GPX file that
 doesn't load.
 I'll try to load it and try the figure the difference with what you do.

 Cheers

 André.







  

  

  

 Guy Vanvuchelen

  

 *Van:*André Pirard [mailto:a.pirard.pa...@gmail.com]
 *Verzonden:* vrijdag 15 mei 2015 4:37
 *Aan:* OpenStreetMap Belgium
 *Onderwerp:* Re: [OSM-talk-be] Osmand en JOSM

  

 On 2015-05-14 17:28, Guy Vanvuchelen wrote :

 Sinds enkele dagen kan ik een GPX bestand dat gemaakt werd met
 Osmand niet meer rechtstreeks inladen in JOSM. Vroeger lukte dat wel.

 Als ik op de website http://www.gpsvisualizer.com/convert_input
 het GPX bestand inlees en terug bewaar als GPX bestand dan kan
 JOSM er ineens wel overweg mee.

 Ik hoorde van een collega mapper dat hij vandaag hetzelfde
 probleem ondervonden heeft. Weet iemand de oplossing of oorzaak?

  

 Ouch, my Thunderbird translator seems to be out of its mind. Google
 Translate speaking:


 For severaldays I a GPX file that was created with OsmAnd not directly
 loading into JOSM. Previously it was more feasible.

 When I'm on the website http://www.gpsvisualizer.com/convert_input GPX
 file read-in and back save as GPX file, then JOSM can handle it there
 once.

 I heard from a colleague mapper that he has encountered the same
 problem today. Does anyone know the solution or cause?

 No problem here to load an Osmand GPX file in JOSM.
 But the best method to describe a problem is I'm using version X of
 this and that, I'm doing this and I see that.
 If you do so, I might be able to compare and help you.

 Cheers

 André.

  

  


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

Re: [OSM-talk-be] Osmand en JOSM

[André Pirard]

On 2015-05-14 17:28, Guy Vanvuchelen wrote :

 Sinds enkele dagen kan ik een GPX bestand dat gemaakt werd met Osmand
 niet meer rechtstreeks inladen in JOSM. Vroeger lukte dat wel.

 Als ik op de website http://www.gpsvisualizer.com/convert_input het
 GPX bestand inlees en terug bewaar als GPX bestand dan kan JOSM er
 ineens wel overweg mee.

 Ik hoorde van een collega mapper dat hij vandaag hetzelfde probleem
 ondervonden heeft. Weet iemand de oplossing of oorzaak?

  

Ouch, my Thunderbird translator seems to be out of its mind. Google
Translate speaking:
 For several days I a GPX file that was created with OsmAnd not
 directly loading into JOSM. Previously it was more feasible.

 When I'm on the website http://www.gpsvisualizer.com/convert_input GPX
 file read-in and back save as GPX file, then JOSM can handle it there
 once.

 I heard from a colleague mapper that he has encountered the same
 problem today. Does anyone know the solution or cause?
No problem here to load an Osmand GPX file in JOSM.
But the best method to describe a problem is I'm using version X of
this and that, I'm doing this and I see that.
If you do so, I might be able to compare and help you.

Cheers

André.


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