Re: [OSM-talk-be] Hoppin / Mobipunt

[Yves bxl-forever]

Hello,

A Hoppin point normally has a digital display where people can get information. 
 I suppose it should be included in the relation as well.
An example here: https://www.nieuwsblad.be/cnt/dmf20200927_95769504

Yves




On Mon, 28 Sep 2020 17:33:18 +0200
Jo  wrote:

> Hi,
>
> I wanted to map our shiny new Hoppin points meant to group sharing
> facilities for bicycles and cars + public transport.
>
> https://www.openstreetmap.org/relation/11683352/history#map=16/50.8633/4.7005
> https://www.openstreetmap.org/relation/11683353#map=18/50.86545/4.69504
>
> are my first attempts.
>
> I used a site relation, because we already have tags for the amenities that
> form part of the group. They are supposed to be concentrated in a 'point',
> but sometimes the bus or train stops are a bit further away.
>
> There should also be a sign, possibly with a map on them, but I didn't map
> those yet.
>
> For those I thought of
>
> tourism=information
> information=board
> maybe
> board_type
>
>
> Any comments?
>
> Jo

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

Re: [OSM-talk-be] regional cycle routes in Brussels

[Yves bxl-forever]

Hello,

Thanks for this.

@Polyglot, I saw you updated numbered cycle routes (1 to 12).
The Brussels cycle route network also has 7 routes with letters.  I suppose we 
should apply the same change.
A small circle: https://www.openstreetmap.org/relation/237027
B middle circle: https://www.openstreetmap.org/relation/116569
C large circle: https://www.openstreetmap.org/relation/7418111 
CC: Canal/Kanaal: https://www.openstreetmap.org/relation/1119347
SZ Senne/Zenne valley: https://www.openstreetmap.org/relation/116611
MM Maalbeek valley: https://www.openstreetmap.org/relation/114235
PP (King’s Palace): https://www.openstreetmap.org/relation/2133184

Cheers.
Yves


On Thu, 3 Sep 2020 10:40:29 +0200
Jo  wrote:

> I had a look at them after downloading them using Overpass API and started
> making them continuous where they were 'broken'. So I went ahead and also
> converted them all to rcn.
> 
> Jo
> 
> On Thu, Sep 3, 2020 at 9:41 AM Jo  wrote:
> 
> > Hi Joost,
> >
> > In Flanders it depended more on topology than anything else. We used:
> >
> > lcn: for loops
> > rcn: for the numbered node networks, this logic was taken to rwn and rhn
> > later on
> > ncn: for long routes going from A to B (LFx) and then later for the Fxxx
> > cycle highways
> > icn: for European routes going from A to B
> >
> > In Brussels rcn doesn't seem to be used and those routes are topologically
> > more similar to the numbered routes system used in Flanders and Wallonia.
> >
> > I agree with you that it makes more sense to tag them as rcn.
> >
> > Jo
> >
> > On Thu, Sep 3, 2020 at 9:14 AM joost schouppe 
> > wrote:
> >  
> >> Hi,
> >>
> >> I was always a little confused that the regional cycle network is mapped
> >> as lcn in Brussels. Since this network is organized by Brussels-the-region,
> >> not Brussels-the-city, it seems logical that it should have the rcn tag. In
> >> fact, more so than the Flemish cycle node network, which is composed of
> >> several networks and almost by coincidence covers the region.
> >>
> >> This is also what we say in the wiki:
> >>
> >> https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycle_Routes#Itin.C3.A9raires_Cyclables_R.C3.A9gionaux_-_Gewestelijke_Fietsroute
> >>
> >> But the example given there (https://www.openstreetmap.org/relation/9623
> >> I believe), is now mapped as an lcn.
> >>
> >> Looking at the edit history, it looks like there was a minor edit war
> >> about this, where user RoRay repeatedly changed it from rcn to lcn
> >> https://www.openstreetmap.org/changeset/8141976
> >> https://www.openstreetmap.org/changeset/12902663
> >> (RoRay is still mapping, still using the not-very helpful default
> >> changeset description "update")
> >>
> >> User BenoitL tried to change it back to rcn (with much better changeset
> >> comments :) - https://www.openstreetmap.org/changeset/12849599), but I
> >> guess he gave up. Polyglot later seems to have mapped most of the other
> >> routes; my guess is he just went with lcn because that's how the others
> >> were mapped.
> >>
> >> Apart from the network not showing up when it should on some maps, it
> >> doesn't really matter much. However, bxl-forever is now mapping -actual-
> >> lcn routes in the Brussels region, operated by Anderlecht municipality.
> >> Example: https://www.openstreetmap.org/relation/11544325
> >> Putting both types of routes in the same level is just wrong IMHO.
> >>
> >> Can anyone provide some more context? Based on my own research, I'd
> >> suggest we simply retag all the regional operated routes from lcn to rcn.
> >>
> >> Best,
> >> Joost Schouppe
> >> ___
> >> 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] Changing default maxspeed for Brussels in 2021

[Yves bxl-forever]

Hello, folks,

As of January 2021, Brussels will change the default maxspeed on urban roads to 
become an all-30-kph city.  This goes for the entire Brussels-Capital Region 
(161 km²).
Basically, the idea is the following:
* no speed roadsign will mean 30-kph
* on the main roads there will be C43 signs with a 50-kph limit (or possibly 
70-kph on the biggest ones); those signs are to be repeated after every 
intersection.
* living streets (20-kph) or pedestrian areas are left untouched
* motorways are left untouched

The good point is that it will be much easier than now—for drivers and for 
mappers alike—to know whether 50 or 30-kph applies somewhere.
I will no longer use BE:urban because it’s not the same in every Region.

May I suggest the following tagging scheme
* maxspeed=30 + source:maxspeed=BE-BXL:urban
* maxspeed=50 (or 70) + source:maxspeed=sign

What do you think?

Cheers.
Yves

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

Re: [OSM-talk-be] bridge or tunnel?

[Yves bxl-forever]

Hello,

I would consider each situation from #3 to #9 here as a bridge.

Here’s why.  If there had never been a railway, the road would be where it is 
now, and it is perfectly flat and aligned with the houses nearby (implicitely 
level=0 and layer=0 in OSM).
On the contrary, the embankment is an artificial structure that has been built 
to raise the railway and make it fly over the road.

I tried to have a look at Infrabel’s Open Data portal, but couldn’t find a list 
of their bridges so far.  They manage about 4,800 bridges and it would make 
sense that our data match theirs.

Cheers.
Yves


On Mon, 27 May 2019 22:24:32 +0200
ghia  wrote:

> I think  some passages are called a mole pipe, but that makes it not a
> tunnel. 
> 
> Don't have tunnel vision: All your examples are railroad bridges. 
> 
> A tunnel has mosttimes also a depth: it lies not under, but beneath
> something and/or crosses several things. 
> 
> Also, sometimes a traffic sign F8 can be found near the entrence. 
> 
> Regards, 
> 
> Gerard
> 
> OSMDoudou schreef op 2019-05-27 21:32:
> 
> > If it can help, Wikipedia cites criteria like twice as long as wide and 
> > "creating a confined area". 
> > 
> > https://en.m.wikipedia.org/wiki/Tunnel 
> > https://fr.m.wikipedia.org/wiki/Tunnel 
> > ___
> > 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] Mapping of motorways - use of int_ref tag on nodes?

[Yves bxl-forever]

OK, thanks.  I’ve talked to the mapper and it was a mistake, indeed, not a "new 
tagging scheme".
Problem solved.



On Fri, 22 Jun 2018 09:24:46 +0200
Marc Gemis  wrote:

> int_ref only on way.
> I think most motorways in Belgium where mapped correctly, before this change.
> 
> Perhaps a mistake of the user which selected ways and nodes before
> adding/changing the int_ref ?
> Feel free to reach out to the mapper that made the mistake.
> 
> regards
> 
> m.
> On Fri, Jun 22, 2018 at 1:26 AM Yves bxl-forever
>  wrote:
> >
> > Hello,
> >
> > I came across something fishy:
> >
> > node
> >   [int_ref="E 411"]
> >   (50.792806,4.417019,50.823614,4.481392);
> > out;
> >
> >
> > It seems that someone is routinely applying the "int_ref" tag on all 
> > individual nodes of motorways.  This seems weird and it duplicates a lot of 
> > information, because this is normally already there on the way.
> >
> > If that is not okay, I’ll try to get in touch with the mapper who did that.
> > Is anyone familiar with how to map motorways properly?
> >
> > Thanks.
> > Yves
> >
> > ___
> > 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] Mapping of motorways - use of int_ref tag on nodes?

[Yves bxl-forever]

Hello,

I came across something fishy:

node
  [int_ref="E 411"]
  (50.792806,4.417019,50.823614,4.481392);
out;


It seems that someone is routinely applying the "int_ref" tag on all individual 
nodes of motorways.  This seems weird and it duplicates a lot of information, 
because this is normally already there on the way.

If that is not okay, I’ll try to get in touch with the mapper who did that.
Is anyone familiar with how to map motorways properly?

Thanks.
Yves

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

Re: [OSM-talk-be] Conflation OpenData Brussels

[Yves bxl-forever]

Hello,

Let aside the technical aspect—this is a good question and I hope somebody will 
be able to give valuable advice—I believe that some datasets in government open 
data portals are poisoned with either incorrect or outdated data.  Importing 
them into OSM could make some damage without extensive review by humans with 
local knowledge.

Here are two examples I am familiar with, and for which I believe bulk imports 
should be avoided.

1) Villo! stations: name tag is an odd upper-case string concatenating the name 
and the address, and capacity seems to be missing in the source data (but can 
be manually retrieved for the website by clicking each station one by one).

2) STIB/MIVB stops: not only the GTFS export replaces the name of the stop with 
a truncated and upper-case version of it—to cope with limitations of their 
real-time app on smaller devices—but the lat/lon values refer to the stop 
position… in OSM it must be a node that is part of the way used by the route 
(and they do not match).  Incidently, STIB/MIVB does not maintain any database 
with the location of the stop *posts*; the only place in the world where this 
information exists is in OSM.





Have a nice day.
Yves




On Tue, 3 Apr 2018 21:22:33 +0200
eMerzh  wrote:

> Hi all :)
> 
> I'm just discovering the data sets that are in
> http://opendatastore.brussels/  (brussels region)
> and some of them might be really interesting for osm.
> Like :
> - school list
> - streets surfaces
> - 3d buildings
> - parkings
> - transports stop poles
> and much more
> 
> , but I was wondering if there was an "easy" way to do the conflation...
> automatically or semi-manually ...
> for now the only way I see is to transform data, put them in a postgis
> then doing all the work manually... but...
> ** there must be a better way **
> no?

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

Re: [OSM-talk-be] Importing Villo! API data

[Yves bxl-forever]

Hello,

In the past weeks I have also wanted to do some cleanup on Villo! stations and 
it’s a fact that there still quite a lot of work to be done.

Just a few thoughts about the idea of bulk data imports because this is what 
gave us really "ugly" nodes sometimes.

The name itself is a problem because what they present as the name is actually 
a string that concatenates the ID of the station, the name and its address.  
This is why tagging this as "official_name" does not seem to make any sense.

Their JSON dataset usually looks like this:

"name":"076 - PLACE VAN MEENEN/VAN MEENENPLEIN",
"address":"PLACE VAN MEENEN/VAN MEENENPLEIN - AV PAUL DEJAER (FACE 35 - 39) / 
PAUL DEJAERLAAN (TEGENOVER 35 - 39)"


And we must translate it as such in our OSM nodes:

ref=76
name="Place Van Meenen - Van Meenenplein"
name:fr="Place Van Meenen"
name:nl="Van Meenenplein"
addr:street="Place Maurice Van Meenen - Maurice Van Meenenplein"
addr:housenumber="35-39"


It’s probably feasible to parse the fields automatically and make something 
that looks clean.
But I am not sure that the street name will always match (see example here, 
official name has "Maurice" somewhere and our parsing script will not guess it 
unless you feed it with a list of all streets).

About missing names in one language, this is tricky: normally we should stick 
with the official name given by the operator.  But another approach will be 
that if we know of an official translation (because it is the same name as the 
street or even a bus stop nearby, or a building) it should be used.  And I 
agree that we should fix typos without asking, like in your example.

Another problem is that the longitude and latitude fields must be checked to 
avoid putting stations in the middle of an intersection or inside a building.


In summary, I will recommend a safer approach, i.e. extracting a list of 
missing stations, and add them one by one manually, after checking whether the 
data looks fine.
But it will be nice to hear the thoughts of other members of the community.

Have a nice day.

Yves



On Sun, 15 Oct 2017 13:48:42 +0200
CedB12  wrote:

> Hello all,
> 
> Lately I have been looking at the Villo! dataset from the JCDecaux API
> at [1], which is released under the Etalab Open License (see also [2]).
> I want to consult the community about the use of this data to improve
> the tagging of the stations we have already mapped. I would also like to
> discuss a potential import of the hundred or so stations that are
> reported in the API but have not been mapped yet in OSM.
> 
> My priority is to fix the tagging of station names and reference
> numbers, which are often wrong or missing in the already-mapped
> stations. I am aware of a few quality issues in the names reported by
> the API (which, as far as I know, are actually the names reported at the
> stations themselves), so this cannot be a fully automated process. As
> far as ref tags are concerned, only 25 existing station nodes do not
> match the API. I have not pushed any change yet in case this thread
> brings up an objection to the use of this API data.
> 
> More importantly, given the quality issues in the API names, we would
> need to discuss how exactly we want to tag names vs. what the "official"
> names are.
> 
> To give you a quick example of what kind of problems we can find in the
> API, consider that one station is named "342 - MAISON COMMUNALE DE
> BERCHEM ST AGHATE". Like all other stations, the name is in all-caps.
> This one in particular contains a misspelling: the commune is actually
> spelled "Berchem-Ste-Agathe". Also, unlike other stations, this one has
> no official Dutch name, and it is not clear to me whether we should
> provide our own translation in the name and name:nl tags.
> 
> I actually got a little bit ahead of myself and had prepared a diary
> entry draft as well as a more detailed and specific email for this
> mailing list, but I now realize that unloading all of this at once might
> have felt a bit forceful. So before I go into the details of all the
> quirks in the API data and formulate a general proposal for tagging, I
> wanted to take a more open-ended approach and ask if anyone had anything
> to share regarding our mapping and tagging of Villo! stations. I am also
> interested in your thoughts on how we should tag the station I gave
> above as an example (in terms of name, name:fr, name:nl, and maybe other
> kinds of name tags like official_name).
> 
> But before that, I would like to make sure that it is OK to import
> Etalab-licensed data, because otherwise this effort will be pointless. I
> assume it must be fine because the license states to be compatible with
> "any licence which requires at least the attribution of the «
> Information »" [3], including the Open Government License which is in
> turn listed on the OSM wiki page on ODbL compatibility [4]. How are the
> requirements of the license (attribution by source name + date + URL)
> 

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

[Yves bxl-forever]

Hello,

It may be a good idea to freshen up the pages on the wiki to remove all 
confusion about this.
Perhaps we could summarize all the discussions as such.


1) If a street is one-way for motor traffic but open to cyclists in both 
direction, we use this:

oneway=yes
oneway:bicycle=no

(This scheme is better than the legacy cycleway=opposite tag, because it also 
allows to add oneway:moped_P=no if we have the new M11 roadsign allowing speed 
pedelecs too.)



2) A properly-marked lane 
(http://wiki.openstreetmap.org/wiki/File:Cycleway_lane1_be.jpg), i.e. stripped 
lines
In Belgian traffic rules, this is the same as a track (fietspad/piste cyclable) 
and gives right-of-way to cyclists

cycleway=lane

(if cyclists can use the street in both directions, use cycleway:left
or cycleway:right if the situation is not the same on both sides)



3) Just logos (http://redac.cuk.ch/archives_v3/5237/bandecyclablesuggeree.png) 
or color, but without the stripped lines
This is the example eMerzh brought up to start the discussion.
This situation does not do anything with regard to traffic rules, but is useful 
for cycling applications because it feels a little safer than a street with 
nothing.

cycleway=shared_lane
 



What do you think?
Yves



On Sat, 30 Sep 2017 18:08:21 +
marc marc  wrote:

> Hello,
> 
> Le 30. 09. 17 à 18:36, joost schouppe a écrit :
> > I think everyone agreed that this is nothing more than "maquillage"  
> not me, not always :)
> 
> > https://www.google.be/maps/@50.8674422,4.3297542,3a,60y,141.06h,86.52t/data=!3m6!1e1!3m4!1srWr6HwmC8P9LgEfOSk2Xpg!2e0!7i13312!8i6656
> >   
> this traffic sign is not a "maquillage".
> It is the traffic sign that tells you that another traffic sign at the 
> other end of the street allows a cyclist to take the one-way street.
> If this mark did not exist, you do not know it when going forward
> in this street in the "one-way" direction.
> 
> > https://www.google.be/maps/@50.8676849,4.3295925,3a,75y,183.24h,93.62t/data=!3m6!1e1!3m4!1sLOB7wV_P3Sqi3kbypjpQcw!2e0!7i13312!8i6656
> >   
> here is the second traffic sign.
> 
> > https://www.touring.be/fr/articles/regles-de-circulation-pour-les-cyclistes 
> >  
> Without any sign, a cyclist can not go backward in a "one-way" street.
> 
> maybe the regionalization of the road code has * the situation but 
> that is, as far as I know, the rule in Brussels where is the street of 
> the first photo.
> 
> So this street should be tagged with cycleway=opposite. see wiki :
> https://wiki.openstreetmap.org/wiki/Key:cycleway
> Use cycleway=opposite for situations where cyclists are permitted to 
> travel in both directions on a road which is one-way for normal traffic, 
> in situations where there is no dedicated contra-flow lane marked for 
> cyclists.
> 
> Regards,
> Marc
> ___
> 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] bug adresse

[Yves bxl-forever]

Hello,

This is a really interesting problem, and it looks like a documented weakness 
of the algorithm.

This is what the Wiki says about this 
(https://wiki.openstreetmap.org/wiki/Nominatim/FAQ#How_was_the_address_calculated.3F)
Features down to street level addresses are calculated using a 
combination
of admin boundaries, is_in tags and place features.  For building level 
features
addresses are calculated using the address of the most suitable street.
If no explicit boundaries or relations are included the system will 
fall back
to a simple 'nearest' calculation—this will often be wrong! 

This is how Nominatim computes the address for that house.
https://nominatim.openstreetmap.org/details.php?place_id=26946130

In this case, it appears that the street is found within 2 municipalities.  
Node 66192903 (Koekelberg) is closer than node 66196464 (Molenbeek) → it 
assumes the house is located in Koekelberg.
If we want to solve this, either we should fill "is_in" keys everywhere or 
split the street exactly on the boundary.

Have a nice day.
Yves



On Sat, 26 Aug 2017 14:29:18 +
marc marc  wrote:

> Bonjour,
> 
> Je ne comprend pas où est l'erreur pour l'adresse de ce nœud
> http://www.openstreetmap.org/node/2528505484
> 
> Un clic droit "afficher l'adresse" donne "1, Rue de Normandie, 
> Koekelberg, Bruxelles-Capitale, 1081, Belgique"
> L'erreur est 1081 au lieu de 1080.
> 
> La rue a un côté 1080 et l'autre côté 1081 mais je ne trouve
> pas où se trouve le 1081 erroné. Le nœud fait partie de :
> - is_in Chemin : Stade du Stippelberg (30163631)  pas de postal_code
> - Relation : Rue de Normandie (3321170) addr:postcode=1080
> - is_in  Relation : Postal code 3379417
>   qui a boundary=postal_code + postal_code=1080
> - is_in Relation : Molenbeek-Saint-Jean (58255)
>   qui a boundary=administrative + addr:postcode=1080
> 
> Il y a quelque chose que je n'ai pas vu ou c'est un bug ?
> 
> Cordialement,
> Marc
> ___
> 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] Fwd: [Tagging] Brasserie

[Yves bxl-forever]

Hello,

opening_hours:kitchen is normally intended for this.  But do many data 
consumers already handle it?

I like the idea of using two separate nodes, it makes sense especially when a 
location encompasses two different functions, i.e. a bar and a restaurant.

Yves




On Wed, 9 Aug 2017 13:26:37 +0200
Marc Gemis  wrote:

> There is no established way to map "kitchen-hours" at this moment AFAIK.
> You could solve this with 2 nodes, one restaurant, one pub with
> different opening hours, grouped together in a site relation. But if
> this is the best way to do so, is debatable.
> 
> According to the wikipedia definition, I think  the izakaya could be
> mapped with amenity=pub; food=yes
> 
> m.
> 
> 
> 
> On Wed, Aug 9, 2017 at 12:35 PM, Thomas Bertels  wrote:
> > Reposting my message from tagging:
> >
> > Based on https://www.lemoniteur.be/documentation/horeca-135.html it seems
> > that a brasserie is a café that serves simple food, and hence the manager
> > doesn't need to be a professional cook:
> >
> > Café
> > Vous ne devez pas avoir un accès à la profession Restaurateurs et
> > Traiteurs-organisateurs de banquets à condition de n'offrir que de la petite
> > restauration (potages, croques et toutes sortes de toasts, croquettes, à
> > l’exception de croquettes de pommes de terre, vol-au-vent, boudins noirs et
> > boudins blancs, brochettes grilles, pains fourrés, hamburgers, hot-dogs,
> > pittas et croissants, pâtes, pizzas, quiches ou autres tartes sales, salades
> > froides, assiettes anglaises, œufs prépares, desserts (notamment des crêpes,
> > des glaces, des gaufres, des gâteaux, des brioches, des yaourts et des
> > milk-shakes). Ces repas légers ne peuvent être servis qu’avec du pain.
> >
> > This category applies too to the "restaurants" that serve only pizzas
> > (pizzerias), pitas, hamburgers... except french fries ("à l’exception de
> > croquettes de pommes de terre").
> >
> > Currently, amenity=pub food=yes seems to be the most used.
> >
> >
> > I've noticed that some places are called "Restaurant-Brasserie", and those
> > don't just serve simple foods, but also classic restaurant foods.
> >
> > So we should probably differentiate them based on that (at least in
> > Belgium):
> >
> > - The "Brasserie" ones could be tagged as amenity=pub food=yes (although pub
> > has an Anglo-Saxon connotation, which is to be expected given the UK origin
> > of osm).
> >
> > - The "Restaurant-Brasserie" ones could be tagged as amenity=restaurant, but
> > something is needed to specify that it's opened not just during classic
> > hours (or do we just always add opening_hours?) and that we can drink
> > without eating (so basically that it's also a café).
> >
> > In addition to brasserie, bistro and taverne, there's also izakaya in Japan.
> > So I guess all of these could be tagged as amenity=pub food=yes?
> >
> >
> > Le 8/08/2017 à 19:12, Glenn Plas a écrit :
> >
> > cuisine described the food served, not the restaurant type.
> >
> > The wiki is quite clear on that
> > https://wiki.openstreetmap.org/wiki/Key:cuisine
> >
> > So I quite agree with Marc that putting brasserie as this key's value is
> > not a description of the food being served.
> >
> > Glenn
> >
> > I'm not sure whether I like the cuisine=brasserie. Do all the
> > brasseries serve the same type food ? Can't you have a brasserie that
> > is only serving fish dishes, or meat or vegetarian or a combination ?
> > Can you expect the same food from a brasserie in Belgium and France ?
> >
> > as for amenity=brasserie (and amenity=tavern) I fear that is a useless
> > tag, as long as the data consumers will not start using it.
> > What about the Danish Kro ? should they use amenity=tavern as well ?
> >
> > Furthermore what is the difference between a brasserie, bistro,
> > taverne, eetcafe ? (I see Thomas has an explanation for brasserie)
> >
> > 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] meerdere postcodes voor één gemeente

[Yves bxl-forever]

Hi,

Yes, it is a fact that in Belgium, there can be several postcodes for one same 
commune/gemeente.
Moreover, one same postcode can span over several communes/gemeenten too.
Therefore, and contrary to popular belief, we should never expect a one-to-one 
correspondence between addr:postcode and addr:city.  Osmose’s complain looks 
here like a false positive because it makes sense to have multiple values.

A spectacular example is the City of Brussels with 8 postcodes: 1000, 1020, 
1120 and 1130 on its own, and 1030, 1040, 1050 and 1070, which it shares with 
other communes (respectively Schaarbeek, Etterbeek, Ixelles/Elsene and 
Anderlecht).


That being said, using addr:postcode on boundary relations is rather uncommon 
practice.  Having another relation for Bellem with role=subarea and using 
addr:postcode on its administrative centre could be considered as an 
alternative.


Have a great day.
Yves



On Sun, 30 Jul 2017 22:33:49 +
Santens Seppe  wrote:

> Hi all,
> 
> Osmose complains that my hometown has two postal codes: 
> http://www.openstreetmap.org/relation/721879
> In fact, 9880 is the "general" postal code for Aalter, but there is also 
> 9881, which is used for Bellem, a town that is part of Aalter (deelgemeente).
> 
> Should the relation for Aalter (admin_level=8) only contain the 9880 postal 
> code? Or is this a false positive from Osmose?
> 
> Seppe

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

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

[Yves bxl-forever]

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

___
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

[Yves bxl-forever]

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



On Thu, 25 May 2017 03:08:56 +0200
"André Pirard"  wrote:

> Hi,
> 
> Just like Osmose does, JOSM accused me of those errors with tags I never
> wrote: here  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

[OSM-talk-be] Combination of a speed cushion and a rising bollard

[Yves bxl-forever]

Hello,

An innovative traffic calming device has been installed in central Brussels 
this week on rue du Midi/Zuidstraat: a rising bollard inserted inside a speed 
cushion [1].  This is a fairly unusual combination.

I feel this should be mapped as a single node [2] with barrier=bollard and 
traffic_calming=cushion.
According to the Overpass, this is the first such node in Belgium.  Since it is 
designed to block a pedestrian street I suppose routing apps will not care much 
but if I am misguided or if this is bad mapping practice please do not hesitate 
to correct this node.

Have a great day.
Yves



1: http://www.multimob.be/uploads/midi-zuidstraat_bollard.jpg
2: https://www.openstreetmap.org/node/4866555287

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

Re: [OSM-talk-be] old notes: sometimes useful

[Yves bxl-forever]

Good job, Joost!

We can solve that kind of issue by creating a node with "shop=vacant".
That way, we can close the note once and for all.
Moreover, this "vacant" tag is useful when a shop closes down because that way 
we can keep the node—and preserve the history—instead of removing it.

Cheers.
Yves



On Thu, 27 Apr 2017 10:08:47 +0200
joost schouppe  wrote:

> Hi,
> 
> I decided to take the bike from Brussels-North to Brussels-Midi instead of
> the train yesterday, and tried to fix some of those controversial notes by
> Math1985. I thought the best way to get them out is by fixing them.
> 
> Anyway, there were a couple of shops where Math marked them as "couldn't
> see because of closed shutters" (example [1]). Several months later, most
> of them still had closed shutters. Without the old Note, you would never
> know that this shop is probably permanently closed.
> 
> 
> 1: http://www.openstreetmap.org/note/726366
> 
> -- 
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 

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

Re: [OSM-talk-be] talk: "responding to vandalism"

[Yves bxl-forever]

The idea is interesting.  Wikipedia uses a similar process: edits by anonymous 
or new users are flagged as potentially suspicious, and users can validate 
contributions by other users.

I understand Karel’s concern: perhaps that there isn’t much *vandalism* in OSM 
in Belgium so far.
But the problem may be that newbie-friendly apps—such as MAPS.ME or 
Wheelmap—encourage lots of new people to add data to OSM without having to 
learn the data model or how to check whether that data is already existing.  I 
often remove duplicate nodes, fix tags or fix location of objects created by 
users of those apps.  The more newcomers, the more we’ll have to deal with 
incorrect data.  These people certainly have good intentions but having a 
process to validate potentially incorrect changes will be necessary as the 
community grows.  And that will work for deliberate vandalism too.

Cheers.
Yves



On Sun, 19 Mar 2017 19:19:39 +
Karel Adams  wrote:

> What's urgent or important about this? Is vandalism an issue on OSM? A 
> problematic issue? I have as yet not seen any.
> 
> 
> 
> On 19/03/17 17:20, Ben Abelshausen wrote:
> > This is an excellent idea, perhaps we should discuss this the next 
> > hackday? Or can someone try and set this up for Belgium?
> >
> > Met vriendelijke groeten,
> > Best regards,
> >
> > Ben Abelshausen
> >
> > On Sun, Mar 19, 2017 at 6:07 PM, joost schouppe 
> > > wrote:
> >
> > Hi,
> >
> > There is an interesting thread going on in the talk mailing list:
> >
> > https://lists.openstreetmap.org/pipermail/talk/2017-March/077672.html
> > 
> >
> > It started of with some complaining about vandalism, but it got
> > interesting when Thomas Straupis started explaining how they work
> > in Lithaunia. Basically, ALL changesets are validated. But
> > changesets by "known mappers" are automatically approved, and some
> > changesets are highlighted because they are marked by other tools
> > as "suspicious".
> > (this is the same Thomas I interviewed recently about their
> > dataconflation strategies:
> > http://www.openstreetmap.org/user/joost%20schouppe/diary/40605
> > )
> >
> > With Zors already checking all new mappers' changesets using the
> > welcome tool (thank you!), it might be interesting to see if we
> > can expand on that here too.
> >
> > Here's some practical stuff from his e-mail:
> >  
> > > Is your process documented anywhere and is the code available?  
> >
> >   There is a "help" page, but it is in Lithuanian... Maybe google
> > translate can help:
> > http://patrulis.openmap.lt/pagalba.html
> > 
> >
> >   Code (php+postgresql) is very basic and dirty (i'm not a web
> > developer) and I didn't have time to put it on github yet (planning to
> > do that for a year or so...). But code is also full of Lithuanian
> > comments and names...
> >
> >   If somebody wants to have a look at it - I can share/send the code
> > and give any information required in English.
> >
> > P.S. This patrolling stuff is integrated with QA tools (fetching a
> > list of errors from keepright, osmose as well as doing local error
> > checking) and data synchronisation tools. So "all in one" solution.
> > You get a list of unapproved changes, a list of not yet fixed errors
> > and a status of synchronisation of different items.
> >
> > -- 
> > Joost Schouppe
> > 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  
> 

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

Re: [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery gone?

[Yves bxl-forever]

Thanks a lot for this.  Indeed, not only does this URL work but 2016 aerial 
views are now available too.
I am also following Joost’s suggestion and am preparing a GeoJSON file to 
upload onto the list of Belgian imagery (set as "best=false" to avoid clashing 
with other layers).

Cheers.
Yves


On Wed, 1 Mar 2017 14:09:26 +0100
Jonathan Beliën <j...@geo6.be> wrote:

> Hi Yves,
> 
> If I remember correctly, I think you use the old URL.
> 
> The new URL should be : 
> 
> wms:http://geoservices-urbis.irisnet.be/geoserver/ows/?SERVICE=WMS=1.3.0=GetMap=image%2Fpng=true=Urbis%3AOrtho2015={width}={height}=EPSG%3A3857=={bbox}
> 
> :)
> 
> Jonathan Beliën
> 
> -Message d'origine-
> De : Yves bxl-forever [mailto:bxl-fore...@linuxmail.org] 
> Envoyé : mercredi 1 mars 2017 13:48
> À : talk-be@openstreetmap.org
> Objet : [OSM-talk-be] Where has Brussels UrbIS 2015 aerial imagery gone?
> 
> Hello,
> 
> The most recent set of aerial imagery for Brussels comes from low-altitude 
> flights commissioned by the Region.
> Very useful to map public space in Brussels and it integrates perfectly in 
> JOSM.
> The layer with images taken during Spring 2015 used to be available here: 
> wms:http://www.gis.irisnet.be/arcgis/rest/services/basemap/ortho2015/MapServer/export?f=image=jpeg=False={proj}=3857=3857={bbox}={width},{height}
> 
> It’s been a few days where this data seems to have been removed from their 
> server.
> Apparently, only the 2004 and 2012 aerial views are still available.
> http://www.gis.irisnet.be/arcgis/rest/services/basemap
> 
> Does anyone know of an alternative location to get this data?
> I wrote to CIRB-CIBG, the Brussels institute in charge of this, but no reply 
> so far.
> 
> 
> Cheers.
> Yves
> 
> ___
> 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] Where has Brussels UrbIS 2015 aerial imagery gone?

[Yves bxl-forever]

Hello,

The most recent set of aerial imagery for Brussels comes from low-altitude 
flights commissioned by the Region.
Very useful to map public space in Brussels and it integrates perfectly in JOSM.
The layer with images taken during Spring 2015 used to be available here: 
wms:http://www.gis.irisnet.be/arcgis/rest/services/basemap/ortho2015/MapServer/export?f=image=jpeg=False={proj}=3857=3857={bbox}={width},{height}

It’s been a few days where this data seems to have been removed from their 
server.
Apparently, only the 2004 and 2012 aerial views are still available.
http://www.gis.irisnet.be/arcgis/rest/services/basemap

Does anyone know of an alternative location to get this data?
I wrote to CIRB-CIBG, the Brussels institute in charge of this, but no reply so 
far.


Cheers.
Yves

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

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

[Yves bxl-forever]

Yes, this looks like we are in agreement, thanks Marc.

I wonder about one more thing: supposing the cycle lane is only in the 
contraflow direction, and if the way was drawn in the direction of traffic, 
what is the difference between:
* cycleway=opposite_lane
* cycleway:left=lane

I have encountered both situations and they seem to say the same thing, but I 
would like to know whether one should be the recommended way.

Cheers.
Yves 



On Tue, 14 Feb 2017 21:06:19 +0100
Marc Gemis  wrote:

> opposite_lane should only be used when there is a lane in the opposite
> direction of the one_way and there is no lane in the direction of the
> oneway. See https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dopposite_lane
> Or as indicated in the above M1, when you tag forward/backward
> separately. It is not enough to indicate a oneway street with cycle
> lanes in both directions.

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

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

[Yves bxl-forever]

Hi,

André is right but I think that part of the problem comes from the fact that 
the available documentation is sometimes contradictory.
A good starting point for anyone wanting to learn more is the Belgian 
conventions page 
(http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Cycleways).

Indeed, oneway:bicycle=no is the recommended tag if cyclists can use the way in 
both directions.  This works best with most apps.

Using additional tags to describe more precisely the kind of infrastructure the 
users will enjoy is nevertheless helpful, for routing apps, for statistics 
about rate of protection, etc.
Despite Belgian traffic rules use the same word (fietspad - piste cyclable) for 
a reserved track (with D7 or D9 signs) and for markings (two stripped lines), 
in OSM-taal those could be tagged with cycleway=opposite_track and 
cycleway=opposite_lane respectively.  In Brussels, it is fairly common to paint 
logos or inverted V-signs on the street but those have no legally binding value 
and would probably not count as anything with "cycleway" in it.

I know that the wiki is not always the Bible but I saw that someone has 
recently rewritten the page about cycleway=opposite 
(http://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dopposite), to recommend 
*against* oneway:bicycle=no.  Shouldn’t we try to find a way to clarify this, 
so that we could tell new users how to map properly?


Cheers.
Yves




On Tue, 14 Feb 2017 17:33:36 +0100
"André Pirard"  wrote:

> 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

Re: [OSM-talk-be] Wrong tagging of name bicycle_rental

[Yves bxl-forever]

Yes, this is clearly a mistake caused by careless bulk imports or someone 
blindly copying information directly from the Villo! website because the text 
strings match.

When we see names such as "Station n° 312 CENTRE CULTUREL / CULTUREEL CENTRUM - 
BD DU SOUVERAIN FACE 282 / VORSTLAAN VOOR 282" we should change that and move 
the information into the appropriate keys: name (name=), address (addr:*=) and 
reference number (ref=).

In recent weeks I have done some work and fixed most stations in the city 
centre already.  It’s tricky because it is not only a tagging problem but quite 
often the nodes are not located correctly, so this requires proper surveying 
too.  Doing the rest of the network is part of my personal to-do list, but if 
someone else is willing to contribute, any help is welcome.

Cheers.
Yves



On Tue, 31 Jan 2017 16:47:28 +0100
Jakka  wrote:

> What must be done here? finding the mapper ? or organisation?
> The mapper puts into the "name" tag the adress...I thought adress are in 
> adress tagfor sure
> example this node... See also the relation 271476 of the rentals...
> https://www.openstreetmap.org/#map=19/50.83401997926138/4.457859929800588
> Are these the correct names or was it to show it on the maps..
> Have a nice day.
> 
> 
> ___
> 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] Proper tagging of wine or champagne bars

[Yves bxl-forever]

Thanks to both of you for helping.

Indeed, despite the awkward grammar to the "drink" key—and the current lack of 
consensus about its use—it might be the way to go.
Perhaps one day someone will want an app to search where they serve one 
particular kind of beverage—let alone a rare beer—and that will come in handy.

Yves


On Mon, 2 Jan 2017 16:32:19 +0100
joost schouppe <joost.schou...@gmail.com> wrote:

> While that allows to tag the availability of drinks, it doesn't allow to
> map the focus on wine. The values used in the fair trade or diet tag (
> https://wiki.openstreetmap.org/wiki/Key:diet ) seem more useful, though
> drink:wine=only would be rather strange. Maybe an extra value like
> drink:*=specialty would do?
>  
> 2016-12-31 13:54 GMT+01:00 Guy Vanvuchelen <guy.vanvuche...@gmail.com>:
> 
> >
> > http://wiki.openstreetmap.org/wiki/Key:drink
> >
> > Guy Vanvuchelen
> >
> > -Oorspronkelijk bericht-
> > Van: Yves bxl-forever [mailto:bxl-fore...@linuxmail.org]
> > Verzonden: zaterdag 31 december 2016 13:34
> > Aan: OpenStreetMap Belgium
> > Onderwerp: [OSM-talk-be] Proper tagging of wine or champagne bars
> >
> > Hello folks,
> >
> > This case has been puzzling me for a while.
> > A few establishments in Brussels specialize in serving only one type of
> > drinks: champagne, wine, beer…
> >
> > amenity=bar seems appropriate but does anyone know what tags one could use
> > to inform about the kind of beverages being served?
> > There are a few taginfo entries with cuisine=wine or cuisine=wine_bar but
> > I wouldn’t advise this.
> > As a last resort, the description key can contain the information, but
> > perhaps there are more useful ways to convey it.
> > Any suggestion or hint?
> >
> > A few selected nodes here:
> > http://www.openstreetmap.org/node/4573612074
> > http://www.openstreetmap.org/node/4582561453
> >
> >
> > Cheers.
> > Yves

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

[OSM-talk-be] Proper tagging of wine or champagne bars

[Yves bxl-forever]

Hello folks,

This case has been puzzling me for a while.
A few establishments in Brussels specialize in serving only one type of drinks: 
champagne, wine, beer…

amenity=bar seems appropriate but does anyone know what tags one could use to 
inform about the kind of beverages being served?
There are a few taginfo entries with cuisine=wine or cuisine=wine_bar but I 
wouldn’t advise this.
As a last resort, the description key can contain the information, but perhaps 
there are more useful ways to convey it.
Any suggestion or hint?

A few selected nodes here:
http://www.openstreetmap.org/node/4573612074
http://www.openstreetmap.org/node/4582561453


Cheers.
Yves

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