Re: [OSM-talk-be] Importing polygons of administrative boundaries for Belgium into OSM

[Kurt Roeckx]

On Fri, Jun 07, 2019 at 02:18:49PM +0200, Pierre Parmentier wrote:
> Hello,
> 
> I just read this "L’Administration Générale de la Documentation
> Patrimoniale du SPF Finances a été désignée par les autres institutions
> comme étant la source authentique de ces limites administratives belges et
> les gère donc en tant que telle." or "De Algemene Administratie van de
> Patrimoniumdocumentatie (AAPD) van de FOD financiën is door de andere
> instellingen aangeduid als authentieke bron van de Belgische
> administratieve grenzen en beheert ze daarom als zodanig." on
> https://finances.belgium.be/sites/default/files/20181023_Limitesadministratives.pdf
> and
> https://financien.belgium.be/sites/default/files/20181023_Administratievegrenzen.pdf
> .
> 
> The available files with .shp data allow everybody to check the
> administrative limits of our municipalities. See
> https://finances.belgium.be/fr/particuliers/habitation/cadastre/plan-cadastral
> or
> https://financien.belgium.be/nl/particulieren/woning/kadaster/kadastraal-plan
> .

In short, they have decided who will deterime the official
boundaries.

If you follow the links, depending on Flanders, Brussels or
Wallonia, they will merge existing information, and it's still a
work in progress. At the end of, there will only be 1 source of
this information.

For Flanders, they will base this on GRB, and apply corrections.
They started in 2018, and it should be finnished by mid 2021. The
GRB and CADGIS should have the same information end up with the
same information.

For Brussels they have already done this based on UrbIS, and it
was finnished in 2018.

For Wallonia they don't seem to have a good source of this, and it
seems they have a lot of work, which should be finnished by 2025.

Note that the data you can download is from 1 January 2018, as in
before they actually have done any corrections. I suggest you
don't import it at this time.


Kurt


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

Re: [OSM-talk-be] preset Traffic-signs-BE

[Kurt Roeckx]

On Sun, Apr 30, 2017 at 04:33:23PM +0200, Guy Vanvuchelen wrote:
> Als je de Voorkeuzen (presets) - Traffic_signs_BE gebruikt dan wordt voor
> het verkeersbord BE:F99c; access=destination ingevuld. Dat lijkt me fout.
> Access= Agricultural lijkt me juister want op sommige van die wegen staat er
> 'onverwacht' een tractor-sluis! 
> 
> In het verkeersreglement staat:
> 
> Het begin van de wegen voorbehouden voor landbouwvoertuigen, voetgangers,
> fietsers, ruiters en bestuurders van speed pedelecs, wordt aangeduid met het
> verkeersbord F99c en het einde met het verkeersbord F101c.

In het zelfde artikel staat daarvoor:
Buiten de categorieën van weggebruikers waarvan het symbool is
weergegeven op de verkeersborden die bij de toegang geplaatst
zijn, mogen deze wegen slechts gevolgd worden door volgende
categorieën van weggebruikers :

a) voertuigen van en naar de aanliggende percelen;

Waar je "vehicle=destination" van kan maken, of gewoon
access=destination


Volgens deze pagina:
https://wiki.openstreetmap.org/wiki/Key:agricultural
lijkt access=agricultural te slagen op het doel om daar te zijn,
niet het type van voertuig, en lijkt dus niet overeen te komen
met het bord.


Kurt


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

Re: [OSM-talk-be] rise of the voetwegen, part 2

[Kurt Roeckx]

On Thu, Jan 28, 2016 at 08:33:28AM +0100, joost schouppe wrote:
> Hi,
> 
> After the "rise of the voetwegen" thread, I'm glad to hear that the
> available data from Trage Wegen is getting ever more available for mapping.
> There now is a WF and a WMS server we can use:
> 
> http://geo.vlaamsbrabant.be:/TrageWegen/MapServer/WFSServer?
> 
> http://geo.vlaamsbrabant.be:/TrageWegen/MapServer/WMSServer?
> 
> There's also a viewer for those who don't like to work with WMS/WFS:
> 
> http://geo.vlaamsbrabant.be/tragewegen/

So looking at this data that I mapped myself for the municipality,
I see that they made some errors in inputting the data I gave
them.  Do you suggest I contact them with the errors?


Kurt


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

Re: [OSM-talk-be] GRB open data

[Kurt Roeckx]

On Sun, Dec 06, 2015 at 11:36:01AM +0100, Pieter Colpaert wrote:
> Njah... Het probleem is ook wat dat we iedere dag een nieuwe manuele
> downloadprocedure moeten starten ipv gewoon een URI opnieuw te kunnen
> afhalen.

Ik dacht dat dit allemaal al een tijd beschikbaar was via wms,
inclusief een vector (svg) layer.  Ik heb dat maanden geleden toch al
gebruikt.


Kurt


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

Re: [OSM-talk-be] Jachtpaden are not cycleway Highway (path along the rivers)

[Kurt Roeckx]

On Sun, Dec 07, 2014 at 07:08:20PM +0100, Marc Gemis wrote:
 On Sun, Dec 7, 2014 at 12:51 PM, Glenn Plas gl...@byte-consult.be wrote:
 
  @Ben : The legal definition (see website url) of 'Jaagpad' starts with:
  Het jaagpad is een private dienstweg of exploitatieweg .  That means
  it's not a public highway.
 
 
 This is the reason that I would use access=private. According to the wiki
 page on access this means Only with permission of the owner on an
 individual basis.  Which is IMHO exactly the same as permit.
 
 access=private
 foot=yes
 bicycle=yes
 moped_a=yes
 horse=???
 
 is simple and does IMHO what it should do: navigations software for cars
 will not route you along the path.
 Everybody that really needs to be there will have to ignore the car
 navigation to get at their destination.
 
 I think that are some jaagpaden where the access=destination (or even yes).

Every few months I find that someone changes is back to cycleway,
but it's always someone else as far as I know.   I've been fixing
this for years.  It's really annoying.

Those roads are private property, where they give permissions to
use them.  So I think access=private makes the most sense.
access=designated does not apply to any that I saw, but those
would be with one of the blue signs.  So I think this makes
perfect sense:
access=private
foot=yes
bicycle=yes

There somethings are also parts to be able to reach a house, and
you might need to change it to access=destination.

As far as I know they typically use one side as service road and
that side is ussually paved.  Around here it's ussually with
asphalt.  So it makes most sense to me to use highway=service for
that side.

You can actually argue that both sides are service roads, so that
would work for me too.  But so would things like unclassified and
track and maybe path depending on surface and width.


Kurt


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

Re: [OSM-talk-be] decreet openbaarheid van bestuur / decreet hergebruik van overheidsinformatie

[Kurt Roeckx]

On Tue, Dec 17, 2013 at 12:54:54PM +0100, Ben Abelshausen wrote:
 Hi All,
 
 We recieved this email on the okfn-be list from Pieter:
 
 
  Noël Van Herreweghe of Corvé/Bestuurzaken Flemish government published a
  list of datasets that should be open data according decreet openbaarheid
  van bestuur / decreet hergebruik van overheidsinformatie and the new
  policy at the Flemish Government that databases should be open by default,
  not by exception.
 
  If you cannot access a certain dataset in this list:
  http://demo.thedatatank.com/flanders/datasets
  you should send an email to the responsible organisation. If the
  organisation declines you the access to this we can start a
  beroepsprocedure. In all other cases we will have a bunch of new open
  data :)
 
  I already did this for Codex Vlaanderen. They first reacted a bit slow and
  asked me question about how I wanted the data. When I got it, I've put it
  on Github. Right now they are moving towards a more professional way of
  opening up their data. All because just one question.
 
  Conclusion: we need your help! Send a couple of emails, open Flanders :)
 
 
 This is also relevant here, the data in this list should be available as
 open-data (same licence as CRAB) and there is a lot of geo-data. A few
 highlights from that list:
 
 - GRB
 - MRB Wegen
 - De Lijn routeplanner
 - ...

At least GRB is currently not available, and I think that would be
really useful to have.  MRB doesn't exist yet.

But basicly anything mentioned on download.agiv.be should be made
freely available, unless they have some good reason not to?


Kurt


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

Re: [OSM-talk-be] Afkortingen/Abbréviations

[Kurt Roeckx]

On Tue, Dec 10, 2013 at 03:40:34PM +0100, Marc Gemis wrote:
 I wonder whether there is a scenario that a non-native speaker sees the
 abbreviation and wants to look up this abbreviation in OSM, but cannot find
 it because only the full (expanded) name is in OSM.
 If so, we would need both names in OSM (or another DB).

The idea would be that the software that is used to do the
searching such handle it and at least known about common
abbreviations.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Sat, Dec 07, 2013 at 11:26:27PM +0100, Jo wrote:
 I haven't worked on boundaries before, but this discussion triggered it.
 
 So I added boundary=postal_code relations for 3000, 3001, 3010, 3012 and
 3018 and since I had to split the boundary of Groot-Leuven, I went all
 around it to align it more on AGIV WMS imagery.

I did some more changes, and did some other postal codes nearby.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Sat, Dec 07, 2013 at 11:26:27PM +0100, Jo wrote:
 I haven't worked on boundaries before, but this discussion triggered it.
 
 So I added boundary=postal_code relations for 3000, 3001, 3010, 3012 and
 3018 and since I had to split the boundary of Groot-Leuven, I went all
 around it to align it more on AGIV WMS imagery.

I fixed some of those boundaries and added some admin_level 9
boundaries for it too, but some are still broken.  Will try to
fix the rest tomorrow.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Fri, Dec 06, 2013 at 12:58:21AM +0100, Glenn Plas wrote:
 On 05-12-13 22:57, Kurt Roeckx wrote:
 On Thu, Dec 05, 2013 at 10:52:31PM +0100, Marc Gemis wrote:
 Since in Belgium the postal code areas coincide with village borders
 I've read somewhere that Brussels has some exceptions to that.
 
 Also Big cities in general, not only BXL but Antwerpen en Gent too,
 or Liege, the postal codes have no logic compaired to village
 borders in plenty of cases.

The information in CRAB seems to suggest that mostly it follows
the administrative borders that we have but that Brussels has
a lot of exceptions to that.  For instance 1040 is both Etterbeek,
but the Louisalaan in Brussels is also 1040.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Thu, Dec 05, 2013 at 05:23:12AM +0100, Marc Gemis wrote:
 Glenn,
 
 I just used the node that was already in OSM.  I'll move it. I've done some
 surveys there, so I know where you want it.

So what would be the difference between the place= node and this
admin_centre for admin_level 9?  You currently seem to be using
that node for it.

PS: I see 2 relations for Muizen?  3359778 (admin) and 3360497
(post).  They have exactly the same members, just some difference
in the tags.  Can't we just delete one of them?

Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

At least the shapefile is clear about the license, and you can
just open that in josm.  You need the OpenData plugin for it.

See:
https://download.agiv.be/Producten/Detail?id=10title=Voorlopig_referentiebestand_gemeentegrenzen

Since the WMS is just a rending of that information, I don't think
it's a problem to use it.


Kurt

On Thu, Dec 05, 2013 at 10:35:17AM +0100, Marc Gemis wrote:
 I'll try to get the wms layer for the boundaries and adapt the boundary to
 the one from AGIV (or are we not allowed to use that ?)
 
 m
 
 
 On Thu, Dec 5, 2013 at 9:46 AM, Glenn Plas gl...@byte-consult.be wrote:
 
  On 05-12-13 05:54, Marc Gemis wrote:
 
  Another question related to this boundary. Originally I did not touch the
  boundary between Mechelen en Bonheiden. I just reused it for the
  Muizen-boundary. I now noticed that the Bonheidensteenweg (
  http://www.openstreetmap.org/way/146650425) was partially in
  Muizen-Mechelen and Bonheiden. So I moved the boundary at that point, i.e.
  moved 1 point by merging it with the streetname change point.
 
  But now I wonder whether the boundary should not be over the stream
   Boeimeerbeek. That makes more sense to me. In this case the street name
  change should occur in the middle of the bridge.
 
  I just checked AGIV, there is no (street) name on the bridge, but the
  street names are different on both sides of the stream. Also, the name of
  the stream is Vrouwvliet according to AGIV.
 
  Can we improve the boundaries with data from AGIV ? Is there a WMS layer
  or shape files we can use ?
 
 
  m
 
 
  I was born and raised in Bonheiden, I always thought that was the border,
  you could actually spot the border between Mechelen(Muizen) and Bonheiden
  for years by looking at the quality difference of the road.  I only visit
  it once in a while and now it seems the road has been redone.   But it used
  to be pretty close to the bridge over the Boeimeerbeek you mention.
 
  The road in Bonheiden is called the Muizensteenweg, in Muizen that road is
  called Bonheidensteenweg.  By looking at the map alone I think that the
  point on the road should not be merged with the administrative boundary
  like it is now. I noticed someone messed with that area a good while back
  and he lacked some mapping knowledge.
 
  That bridge is the border, atleast by popular knowledge.
 
 
  Glenn
 
 
  ___
  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] My first attempt at a boundary

[Kurt Roeckx]

On Thu, Dec 05, 2013 at 05:19:35PM +0100, Bart Van Lancker wrote:
 
 That's what I'm trying to do in Ghent, and it doesn't work. I've defined the
 deelgemeenten with their postal code (actually as a
 boundary=administrative), but there seem to be some postal codes hardcoded
 in Nominatim, which seem to have preference over the postal code
 bounbdaries.

As far as I know it always takes the closest place node, and I
think I've open a bug about that.  But as ussual there doesn't
seem to be much reaction to it.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Thu, Dec 05, 2013 at 10:52:31PM +0100, Marc Gemis wrote:
 Since in Belgium the postal code areas coincide with village borders

I've read somewhere that Brussels has some exceptions to that.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Wed, Dec 04, 2013 at 01:49:56PM +0100, Marc Gemis wrote:
 Today, I did my first attempt add adding a boundary. The boundary is for
 the deelgemeente Muizen near Mechelen. The changeset is
 http://www.openstreetmap.org/changeset/19271107
 
 I used http://gisgeoloket.provant.be/ to export a jpg file of the boundary.
 I could not use the geo information that was generated by the file,
 probably due to a different projection. I then used JOSM + PicLayer plugin
 for positioning the exported jpg-file manually. Then I tried to trace the
 border.

AGIV also has border information. It's easy to convert this to CSV
file you can import into josm.  Alternative there is also a WMS
layer with that avaialble.

It's available under their public license and there shouldn't be a
problem using that.


Kurt


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

Re: [OSM-talk-be] My first attempt at a boundary

[Kurt Roeckx]

On Wed, Dec 04, 2013 at 06:04:10PM +0100, Kurt Roeckx wrote:
 On Wed, Dec 04, 2013 at 01:49:56PM +0100, Marc Gemis wrote:
  Today, I did my first attempt add adding a boundary. The boundary is for
  the deelgemeente Muizen near Mechelen. The changeset is
  http://www.openstreetmap.org/changeset/19271107
  
  I used http://gisgeoloket.provant.be/ to export a jpg file of the boundary.
  I could not use the geo information that was generated by the file,
  probably due to a different projection. I then used JOSM + PicLayer plugin
  for positioning the exported jpg-file manually. Then I tried to trace the
  border.
 
 AGIV also has border information. It's easy to convert this to CSV
 file you can import into josm.  Alternative there is also a WMS
 layer with that avaialble.
 
 It's available under their public license and there shouldn't be a
 problem using that.

Buth muizen is of course part of Mechelen and so isn't available
there.


Kurt


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

Re: [OSM-talk-be] Straten met 2 namen

[Kurt Roeckx]

On Wed, Nov 27, 2013 at 11:53:55AM +0100, Bart Vanherck wrote:
 Zijn er geen straatnamen met een - ? Ik denkt aan de St.-Barbarastraat en
 andere Sint straten.

St.-Barbarastraat is niet volgens de regels.  Het moet altijd
volledig geschreven worden, dus Sint-Barbarastraat.  En als
we het dan toch over Sint hebben, Sint Barbarastraat is volgens
de spellings regels fout, na Sint moet altijd een koppelteken.


Kurt


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

Re: [OSM-talk-be] Brussels and Belgium

[Kurt Roeckx]

On Tue, Nov 26, 2013 at 02:08:02PM +0100, Ben Laenen wrote:
 On Monday 25 November 2013 23:37:41 Kurt Roeckx wrote:
  There should be a hole in the language area (which we don't have)
  and the region
  (http://www.openstreetmap.org/browse/relation/53134), which seems
  to be the case, and you can argue about the communitie
  (http://www.openstreetmap.org/browse/relation/53136)
 
 You can't really argue, the constition is pretty clear that the Brussels-
 Capital-Region belongs to both French and Flemish Communities.

So the Dutch-speaking community is the Dutch language area with the hole
in it for Brussels, and then you add Brussels again and you end up
with that hole filled.  So you can map this as:
- Start with the language area which has the hole in it, and
  add Brussels to it.  So you start with the complete thing
  and substrct and add the same piece of land.
- Don't bother will all the adding and substracting, which 
  is like it's now.



Kurt


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

Re: [OSM-talk-be] Brussels and Belgium

[Kurt Roeckx]

On Tue, Nov 26, 2013 at 02:57:05PM +0100, Wouter Hamelinck wrote:
 If you really want to use it as a geographical definition for the
 communities, why would you use the one from art127 and not the ones
 from articles 128 or 129? Especially 129 doesn't mention Brussels.

Please note that 129 is about languages.  It basicly doesn't allow
the communities to say what language should be used in Brussels
because it's bilingual.

Maybe I wasn't clear enough, but I have always had a problem with
mapping the communities in the first place since they are about
the person and not the land.  But there are people that want to
map that.  And if we're going to map them than we should try to do
it as correctly as possible.


Kurt


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

Re: [OSM-talk-be] Brussels

[Kurt Roeckx]

On Wed, Nov 13, 2013 at 06:12:30PM +0100, Marc Gemis wrote:
 All those problems are important to a group of people, but they are all
 exceptions to the general rules. So maybe we should just take up all those
 complaints with the Nominatim developers, because they might not be aware
 of all those exceptions.

There are already various bugs open with no reaction.  It's not
because nominatim gets it wrong that we should change something.


Kurt


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

Re: [OSM-talk-be] AGIV CRAB import

[Kurt Roeckx]

On Mon, Nov 11, 2013 at 11:07:38AM +0100, Ben Abelshausen wrote:
 Hi Kurt,
 
 Your tool may come in handy when generating diffs because it has a
 database. I deliberately did not use a database because it can be a lot of
 work to set this up and I believe the AGIV CRAB data should be usable by
 anyone.

It shouldn't be that hard to set it up with a database.  And I
need the database for the other things I want to do with it.

 The interface here is translated: http://addr.openstreetmap.fr/vlaanderen/
 
 I just send the csv files to frédéric rodrigo and he uploads them and
 creates relations etc. If you can send me a new file that would be great
 when the issue I had have been solved:
 
 - Improve the script to handle 'special' chars.
 - Improve the script to Always take the most accurate position.
 - Improve the script to remove data with an end-date before today.
 
 But if i followed your explanation this should all be ok no? Thanks for the
 good work. Oh and can you keep the format I used?
 
 https://www.dropbox.com/s/w0nglkunw4x2osk/crab.csv
 
 Dot-comma seperated and the same columns? This will make it easier for
 frederic to update.

I assume your first problem is that the CRAB database is in latin1
and maybe you want it in UTF-8?  I can at least not see problems
with non-ASCII chars.

But I do believe it should deal properly with the rest.

I've put a file with the same header on:
http://www.roeckx.be/osm/crab.csv

I've made that file in UTF-8.  I hope that is what's expected.


Kurt


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

[OSM-talk-be] AGIV CRAB import

[Kurt Roeckx]

Hi,

I've been looking at creating my own tools for the CRAB data.
I've made some software to import the files provided by AGIV
into a postgresql database.  You can find it here:
https://github.com/kroeckx/crab-tools

To create the same .csv files as Ben generates I suggest you
use the following query:
SELECT
DISTINCT ON (point)
postcode, municipality_name, street_name, house_number_label, 
ST_Y(ST_Transform(point, 4326)), ST_X(ST_Transform(point, 4326))
FROM crab.address_position
WHERE postcode = ?
ORDER BY point;

This should give you more addresses and only the valid addresses,
and in most cases it should now end up on the building.  It should
also have grouped all the different numbers belonging to the same
building into 1 node.

I'm not sure how the data on http://addr.openstreetmap.fr/vlaanderen
is generated exactly.  But I'm going to look into improving
things.


Kurt


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

[OSM-talk-be] AGIV datasets, gemeente grezen

[Kurt Roeckx]

Beste,

Ik zie dat AGIV tegenwoordig meer data ter download beschikbaar
stelt.  Voor de volledige catalogus zie:
https://download.agiv.be/Catalogus

Als die waar geen slotje voor staat zijn te downloaden.

Ze zijn blijkbaar ook allemaal onder de zelfde licentie als CRAB,
het document dat er bij met de gebruiksvoorwaarde heeft dezelfde
tekst als bij CRAB.

Het gaat vooral om luchtfoto's, maar bv ook gemeentegrenzen:
https://download.agiv.be/Producten/Detail?id=10title=Voorlopig_referentiebestand_gemeentegrenzen

Ik heb eens effe die shapefiles gedownload, en die geven heel
schoon de gemeente grezen, beter als die dat we nu hebben.

Ben, kun je eens horen of we al die dingen echt kunnen gebruiken?

Is dat iets dat we willen importeren?  Er staan blijkbaar zowel
gemeentes, arrodisementen, provincies als het gewest in.


Kurt


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

Re: [OSM-talk-be] New Boundary for Belgium - NL?

[Kurt Roeckx]

On Thu, Nov 07, 2013 at 05:00:51PM +0100, André Pirard wrote:
 I was just writing a few days ago that, as the law says that the law
 cannot be copyrighted, there can be no copyright for boundaries, as
 well as for traffic signs.  Shouldn't the boundary maps normally be
 found in the Moniteur together with this kind of announcement?br

I'm pretty sure it will be published with coordinates.  There are
existing laws with coordinates in them, at least for borders
between municipalities.  But it's hard to find them all since only
the recent changes are made available digitally.

 I wonder what happens when the river or stream used as a borderline
 by OSM changes its course by itself.

There are defentily cases where the border is the historic path
of a river, and either the river changed by itself or man altered
it's path but that the border stayed.

But it's not only rivers.  Roads are often also the border and
might later be widened, straighten out and so on.

You can do 2 things when currently mapping them and you don't have
official coordinates:
- Re-use the existing nodes, nodes end up in 2 ways
- Use other points for them, they don't share nodes

In the first case you of course need to be careful when moving
such a node.  But we might not know better where the border really
is so it's often easier to map re-use the nodes.


Kurt


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

Re: [OSM-talk-be] question on relation 2404021

[Kurt Roeckx]

On Sun, Nov 03, 2013 at 02:04:59PM +0100, marc bessieres wrote:
 
  * Ville/Stad* de Bruxelles is in fact a *Commune/Gemeente* made of 4
  anciennes communes/deelgemeenten Brussels, La(e)ken, Neder-Over-Heembeek
  and Haren.
  What you see incomplete is the first one, but the other ones are
  incomplete too.
  The boundaries between them are missing. They must be added with the right
  name and the four boundaries must be closed over them. My only problem is
  finding the missing pieces if I do that, but I know where to look for them.
 
  Cheers,
 
André.
 
 Thank you André for your explanations, I saw the administrative level
 difference, but I didn't know how to interpret them. Now I do :)
 If you could find the missing boundaries it'd be perfect! Or tell us where
 to look for them, may be me or someone else in the community can help there.

I would normally look this up in the atlas der buurtwegen / des
chemins vicinaux, but I can't find them for Brussels.

So I've looked at urbis (http://geoloc.irisnet.be/) which I
understand we can use, under extra it has an option to show
the municipalities.  But that would only be the one for level
8 and no information about the level 9 since they don't really
exist anymore.

I suggest you try to find the atlas der buurtwegen / des
chemins vicinaux, or the Popp card for that information.


PS: The URLs in your e-mail missed the 1 at the end, but it's in
the subject.

Kurt


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

Re: [OSM-talk-be] covered or tunnel

[Kurt Roeckx]

On Sun, Nov 03, 2013 at 02:36:53PM +0100, marc bessieres wrote:
 Hello,
 
 With Keep Right, there is the following error:
 http://keepright.at/report_map.php?schema=72error=25113833
 
 The error text is:
 This node is a junction of ways on different layers:
 #38962740http://www.openstreetmap.org/browse/way/38962740
 (-1),#116844652 http://www.openstreetmap.org/browse/way/116844652(0)
 
 It is because the way http://www.openstreetmap.org/browse/way/38962740 has
 the tag tunnel=yes

As far as I know tunnel=yes doesn't imply layer=-1, which
keepright seems to be doing.  I think keepright is wrong to assume
that.  But then Key:layer says that for bridges and tunnels that
are at level 0 you should explicitly put the layer.

 When I look at the wiki for the tunnel definition
 https://wiki.openstreetmap.org/wiki/Key:tunnel
 
 And the one of covered
 https://wiki.openstreetmap.org/wiki/Key:covered
 
 I presume that tunnel shall be replaced by covered as this way is a
 galerie at the same ground level as the 2 streets it connects to.

There is also tunnel=building_passage, which might be more clear
then just yes.  It's also very explicit in saying that it should
have the same layer as the buildings (none/0).

As far as I understand it, covered means that there aren't 2 walls
on each side and so that it's open, which as far as I know isn't
the case.


Kurt


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

Re: [OSM-talk-be] Naam van boerderij / Name of Farm

[Kurt Roeckx]

On Fri, Nov 01, 2013 at 07:18:00PM +0100, Marc Gemis wrote:
 What's the best way to tag the name of a farm ?
 
 As addr:housename or name ? Do you place the name tag on the main building,
 all buildings or the farmyard (tagged as landuse=farmyard) ?

On the landuse=farmyard makes most sense to me.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Wed, Oct 23, 2013 at 10:13:29AM +0200, Glenn Plas wrote:
 In pseudo:
 
 - get data from osm (assuming here , the data is partial, so lets
 say, everything with an 'addr' tag in your field of view.)  , the
 same effect you have when exporting a certain key using overpass.
 - get data from crab, craft is as such (preparse it) to facilitate
 merging with osm data set.
 - Make the diff, but create an OSM compliant xml (with meta data,
 otherwise you won't be able to create a changeset from it)
 - open the changeset with JOSM, verify, correct, validate and push.

So I was looking at changeset formats yesterday.  It seems that
josm has it's own xml format for that which would contain all the
data and then have things like action=delete, and so is a
changeset format.  But it's not something I really like since it
doesn't contain just the difference but the whole objects.  And it
seems that this is the only one supported by josm.  But none of the
diff files really seem to do what I'm expecting a diff to do.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Wed, Oct 23, 2013 at 07:17:42PM +0200, Marc Gemis wrote:
 I assume you are talking about http://wiki.openstreetmap.org/wiki/API_v0.6 ?
 This API is not only used by JOSM, but by any editor, including iD I
 assume.

I was talking about things like:
http://wiki.openstreetmap.org/wiki/JOSM_file_format
http://wiki.openstreetmap.org/wiki/OsmChange
http://wiki.openstreetmap.org/wiki/Overpass_API/Augmented_Diffs


Kurt

 On Wed, Oct 23, 2013 at 6:54 PM, Kurt Roeckx k...@roeckx.be wrote:
 
  On Wed, Oct 23, 2013 at 10:13:29AM +0200, Glenn Plas wrote:
   In pseudo:
  
   - get data from osm (assuming here , the data is partial, so lets
   say, everything with an 'addr' tag in your field of view.)  , the
   same effect you have when exporting a certain key using overpass.
   - get data from crab, craft is as such (preparse it) to facilitate
   merging with osm data set.
   - Make the diff, but create an OSM compliant xml (with meta data,
   otherwise you won't be able to create a changeset from it)
   - open the changeset with JOSM, verify, correct, validate and push.
 
  So I was looking at changeset formats yesterday.  It seems that
  josm has it's own xml format for that which would contain all the
  data and then have things like action=delete, and so is a
  changeset format.  But it's not something I really like since it
  doesn't contain just the difference but the whole objects.  And it
  seems that this is the only one supported by josm.  But none of the
  diff files really seem to do what I'm expecting a diff to do.
 
 
  Kurt
 
 
  ___
  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] CRAB Import Tool

[Kurt Roeckx]

On Tue, Oct 22, 2013 at 05:36:28AM +0200, Marc Gemis wrote:
 So you are going to write an algorithm that matching addresses in OSM with
 addresses in Crab in order to add an id. Right now there are already
 addresses in OSM that are not in Crab. The same might happen next year.
 People might have added POIs with addresses. So you will always need an
 address based matching algorithm. So there is no reason to add the Crab id
 in OSM.

I don't follow your reasoning here.  Addresses in OSM but not CRAB
shouldn't be a problem.  I also don't understand your comment
about POIs with an address.

It's not because you can match a lot of the addresses based on
al algorithm that you can find all of them.  This *will* require
people to manually fix things and manually add the relation
between the 2.

 What do you mean by Fix our data ? Is Crab suddenly the holy grail ?

I didn't say anything like that.  I just say that our data *does*
contain errors.  I'm also pretty sure theirs contain errors.  If
we look at the differences we need to find out which one is correct,
and then try to get the correct information in both.

 Their DB contains mistakes as well. I'm against a full automatic import.
 I'm still in favor of the workflow that Ben proposes. Using a website to
 download a street. Manually merging with existing data, drawing buildings,
 merging or splitting buildings were needed. Who wrote a few days back that
 house nodes without buildings are not so good (I'm not saying it was you) ?
 An automatic import cannot prevent that.

I did say that I would prefer the address information is added to
building, but that just having a housenumber and no building is
better then nothing.

I also don't see myself drawing all the buildings when I'm going
to import the address information because it will take a lot more
time.  But I will at some point draw them.  You might have
different priorities than I.

If I were to write an import tool, I would be careful on when to
import something, and when in doubt don't import the address.  I
already have several rule in my head that could be useful.  But it
looks to me like nobody wants me to do this, so I'm not going to
put any effort in this.

 It would be nice though to have something like Jo did for the busstops.
 Have a table for mismatches between the OSM data and the imported data.
 Such a list could be generated every year to see which data should be added
 or updated

AGIV delivers updated files on daily basis.  There should not be a
problem to actually also compare them on daily basis, and update
the list of nodes that still need to be imported on daily basis.
But I don't see myself putting time in this if there is no
relation between the 2 databases.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 21, 2013 at 08:05:50PM +0200, Ben Abelshausen wrote:
  I'm also wondering if we want to add some kind of reference to
  the ID from CRAB.
 I'm not in favour of keeping external id's in OSM, the address itself
 should be the id and you cannot rely on it staying on the map because
 anyone can remove it.

I was just thinking about how to keep in sync with their database,
and to try and find out which points are mapped and which are not.

I'm also considering trying to do a full import and merging
existing nodes / houses with their data and things like that.  I
would actually like to mostly automate importing updates comming
from them.  I think that at some point we will at least need a way
to see see the difference between the 2, and having a direct
relation betweem them could make things easier.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 21, 2013 at 09:40:07PM +0200, Ben Abelshausen wrote:
 I think we can use CRAB as a source but we will never be able to update
 automatically but even without an ID we should be able to detect changes
 and if not then most likely there will be some error in OSM or CRAB (if
 streetnames do not match or something).
 
 I even think there is no 'one-id-per-address' in the CRAB datamodel. I will
 ask someone on Wednesday when I will be back at AGIV but I think there are
 only linked buildings/percelen and those tend to change too.

They actually have pretty good documentation, and really thought
about their data model.  They have a total of 20 tables with
foreign keys between them.

Their is a many-to-many relationship between addresses and points
on the map.  That is a building can have multiple addresses, and
1 address can have multiple buildings.  An address can also have
subaddresses.  And each table has an ID in it.

Having the IDs in osm would make it a lot easier to compare the
databases.  Having 2 databases you can compare is very handy to
check for mistakes.

You can of course compare their old database against a newer and
try to import that, but I have a feeling that that is going to
give you more manual work in the long end.  I think it's important
to try automate things.

I really see no good reason not to add those IDs at this point.
I don't see the harm in them.  I can only see them being useful.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 21, 2013 at 10:06:03PM +0200, Kurt Roeckx wrote:
 I really see no good reason not to add those IDs at this point.
 I don't see the harm in them.  I can only see them being useful.

I would actually want to propose a different import strategy:
- Add the CRAB IDs to all existing addresses in Flanders
- Import the rest or large parts of CRAB in one big import

The first part would actually be the hard part, and would need
to be done carefully.  It will probably require large parts to
be checked manually.  We would probably first need to fix our
existing data, which I think is useful to do anyway.

Therefor it would be useful that if you're going to import data
from CRAB that you don't complicate that and already import the
IDs.  It should then be possible to combine both ways of importing.

PS: Do we actually already have clearance to import this data?


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 14, 2013 at 08:26:43PM +0200, Ben Abelshausen wrote:
 
 I also converted the entire dataset to readable csv files and the
 coordinates to lat/lon:
 
 https://github.com/xivk/crab-tools/tree/master/crab_csv

So I've been looking at at their database, which contains all
kinds of useful data.

So one thing I noticed is that they contain dates from when the
housenumber was valid until when it stopped being valid.  For the
cases I've looked at, it seems that you just imported those
housenumbers, even though they really don't seem to exist anymore.
So can you take a look at how you generate those files?

I'm also wandering if we want to add some kind of reference to
the ID from CRAB.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Sat, Oct 19, 2013 at 02:00:12PM +0200, Ben Abelshausen wrote:
 Hallo,
 
 Wat zeg ik nu om de adressen te importeren?
 
 Het is het één of het ander:
 
 - Alles op de node.
 - Alles op relatie behalve nummer.

Ik dacht dat het al duidelijk was, maar ik ben voorstaander van
het op de relatie te doen.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Wed, Oct 16, 2013 at 09:06:00AM +0200, Marc Gemis wrote:
 2013/10/16 Ben Abelshausen ben.abelshau...@gmail.com
 
  1) Zouden we misschien kunnen afstappen van de regel om huisnummers op de
  gebouwen te plaatsen ? Zeker in steden waar al grote blokken getekend zijn,
  is het een serieuze job om die allemaal te verbeteren (want op Bing
  gebaseerd) en dan nog eens te splitsen. En wat is de toegevoegde waarde ?
  Je zal bovendien nog dikwijls naar de Agiv website moeten gaan kijken om te
  weten welke bijgebouwen nu bij welk huisnummer hoor.
  Mensen die toch willen splitsen kunnen dat nog altijd doen. Het is een
  beetje zoals de kerken die nu soms met 1 enkel punt zijn aangeduid. Later
  kan iemand nog altijd het gebouw tekenen.
 
 
  Normaal zijn die adressen uit CRAB, als ze op een gebouw staan als, ook in
  de csv-files even accuraat als op de AGIV-webiste. Misschien zit er nog een
  fout in mijn script.
 
 
 Ik heb geen voorbeeld van waar het misloopt, maar staan de huisnummers echt
 op een huis, of staan ze op een perceel ?

Ik heb de indruk dat er veel op het huis zelf staan, maar een deel
op het perceel.  Ik heb het gevoel dat i.v.m. GRB ze daar mee
bezig zijn geweest.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Tue, Oct 15, 2013 at 05:54:26AM +0200, Marc Gemis wrote:
 I thought the consensus from an earlier discussion here was
 
 1) addr:housenumber + addr:street on building (not as node)
 2) for those that want to do it: associatedStreet relation with name,

If you use a associatedStreet relation, you want to set the street
only once there and not for each node or building.

On the other hand if you don't use the associatedStreet relation
you do want to have the addr:street on the node or building.

It would of course be nicer to have a shape for each buiding,
but a node with the address is better then nothing.


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Tue, Oct 15, 2013 at 01:08:14AM +0200, Jo wrote:
 side note: I prefer to put the source tags (AGIV;CRAB) on the changeset
 instead of on each and every separate object we're adding.
 
 I'm sorry about adding Herentalsesteenweg. I should have read the message
 before trying to click through to test it... Anyway, it's properly
 attributed and it's mostly manual labour anyway. It's far less automated
 than the UrbIS integration, as we still have to draw the building outlines
 ourselves.
 
 I had to create the associatedStreet relation myself. Was that intentional?

When I tried it it had an associatedStreet with the name added,
maybe something changed?


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

Since the CRAB data is actually from flanders, it would probably
make sense to do this either in English or Dutch.


Kurt

On Mon, Oct 14, 2013 at 09:28:57PM +0200, Peter Verschueren wrote:
 Hello all,
 
 New to OSM and JOSM.
 If there are any sessions about it you can count me in. Living in the center 
 of Belgium, Dutch is mother language but French is also OK.
 
 P_Verschueren : Twitter and OSM nickname
 
 P
 
  Op 14-okt.-2013 om 21:21 heeft Marc Gemis marc.ge...@gmail.com het 
  volgende geschreven:
  
  Seems like a good interface. Looking forward to start importing
  
  We might have to setup some sessions (google hangouts, face-to-face) for 
  people that are not familiar with JOSM.  Also for people that are familiar, 
  we might give a session with some tricks on the fastest way to combine the 
  imported data and the existing OSM data.
  
  thanks a lot for your hard work
  
  regards
  
  m
  
  
  On Mon, Oct 14, 2013 at 8:26 PM, Ben Abelshausen 
  ben.abelshau...@gmail.com wrote:
  Hi,
  
  What does everybody think of this tool to use a reference and to keep 
  track of what has been imported and what not for CRAB:
  
  http://addr.openstreetmap.fr/vlaanderen/
  
  It contains only data from one village (Lille) in de kempen but it should 
  be clear how this would work. We can also translate the UI into dutch.
  
  Workflow:
  
  - Open JOSM.
  - Make sure remote control is enabled.
  - Click one of the roads that can be imported/conflated.
  - Mark as done when done.
  
  I also converted the entire dataset to readable csv files and the 
  coordinates to lat/lon:
  
  https://github.com/xivk/crab-tools/tree/master/crab_csv
  
  Please don't import anything before we have sent the import plan to the 
  imports list.
  
  Met vriendelijke groeten,
  Best regards,
  
  Ben Abelshausen
  
  
  ___
  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] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 14, 2013 at 08:26:43PM +0200, Ben Abelshausen wrote:
 Hi,
 
 What does everybody think of this tool to use a reference and to keep track
 of what has been imported and what not for CRAB:
 
 http://addr.openstreetmap.fr/vlaanderen/

So looking at the data, I've already found several places where I
think the place of the node isn't really where the building is,
and that maybe some numbers are missing.  Is AGIV interested in
feedback about this?  And if so, how are we going to do that?

If we move the node to an other place, I guess it make sense
to remove the source tag for that node?


Kurt


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

Re: [OSM-talk-be] CRAB Import Tool

[Kurt Roeckx]

On Mon, Oct 14, 2013 at 09:59:29PM +0200, Ben Abelshausen wrote:
 
 The source is wrong obviously and I guess we should also add postalcode and
 commune name??

Adding postal code and commune name doesn't make sense to me in
most cases.  At least not for how it works in Belgium.  That
information belongs on the administrative relations.  Adding
it would be duplication of information we already have, or
should have.  And they ussualy end up conflicting after some
time.

The only case this makes sense to me are in cases where it's
unclear.  For instance when an administrative relation runs
through a building the official address will be on one side
of it and you need to add extra data to make clear where it
is.


Kurt


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

Re: [OSM-talk-be] OSM Belgian chapter as a Belgian asbl/vzw

[Kurt Roeckx]

On Fri, Oct 11, 2013 at 09:16:59PM +0200, Nicolas Pettiaux wrote:
 2013/10/11 Kurt Roeckx k...@roeckx.be
 
 
  So basicly there will be no OSM-be, only OKFN?

 that is the idea
 
  We are already a de facto association,
 
 indeed
 
  so nothing will change?
 
 as we will have also a formal association backing osm-be, with a legal
 status, a bank account, accoutant ... we will be able to receive money, be
 represented at official meetings, organize official activities, print
 stickers, have business cards ...

There really is nothing that stops you from doing that now.  A de
facto association can do things like opening a back account and
receive money, go to official meetings and so on.  I actually do
that as part of a de facto association, we get money from the
government and so on.  However, for legal reasons you usually
want to become a legal entity.  It might also make some things
easier.

  Or will be somehow be able to represent OKFN-BE?

 this is another question to ask to okfn board members in cc.

When reading their statutes, either individuals or legal entities
can join them, so as a de facto association we can't join them.

There statutes would make it possible for them to delegate
specific tasks to individuals.

I'm really still of the opinion that we should create our
own legal entity.


Kurt


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

Re: [OSM-talk-be] OSM Belgian chapter as a Belgian asbl/vzw

[Kurt Roeckx]

On Sun, Oct 06, 2013 at 07:06:24PM +0200, Ben Abelshausen wrote:
 On Sun, Oct 6, 2013 at 11:43 AM, Glenn Plas gl...@byte-consult.be wrote:
 
  I've said it before in the past here :  my company is ready to donate
  resources, we use OSM data every second of the day.   A VZW/ASBL would make
  that donation a tad easier to do (and receive a decent paper trail for our
  friends at the tax office)
 
 
 Another very important reason to have these things in place!
 
 I would very much like to be a local chapter to the OSMF. I'm not sure we
 would be able to do that when our activities would be done through OKFN BE?

I think we need to create our own vzw/asbl in any case.  The
question is wether we also want OKFN BE to be an umbrella
organisation for us if they want to do that, and what conditions
they have for that.

See:
https://en.wikipedia.org/wiki/Umbrella_organization


Kurt


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

Re: [OSM-talk-be] OSM Belgian chapter as a Belgian asbl/vzw

[Kurt Roeckx]

On Fri, Oct 04, 2013 at 07:12:40PM +0200, Pierre Parmentier wrote:
 I order to progress with the registration of OSM-BE as an asbl/vzw, I have:
 
- updated the draft for the statutes. (As the fr version is more
detailed than the nl version, I have been working on the first one.)
- prepared a Draft for agreement of OSM-BE as local chapter with OSMF
 
 Please have a look at
 http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Chapter and comment.
 
 For the asbl/vzw we need :
 
- at least three stichtende leden/membres fondateurs
- an address in Belgium
 
 Please confirm your interest to be included as a member. If you agree, I am
 ready to go ahead with the procedures.

This has been talked about for years, it's time we actually do it.


Kurt


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

Re: [OSM-talk-be] Verbodsbord C3

[Kurt Roeckx]

On Tue, Oct 01, 2013 at 11:37:22PM +0200, Ben Laenen wrote:
 On Tuesday 01 October 2013 22:56:33 André Pirard wrote:
  vehicle=no alone is wrong because it allows access to horses.
  access=destination is wrong because it does not allow access to
  pedestrians and to horses, and delivery and emergency vehicles must be
  added.
 
 Here's the flaw in this: no-one will do this, no editor will do this, no 
 person will do this. Almost everyone in Belgium who encountered an 
 uitgezonderd plaatselijk verkeer sign has tagged it with access= 
 destination. No-one will systematically add all the tags needed to translate 
 that to their own vehicle tree. Some that try will forget one or more vehicle 
 type etc.
 
 And you're an example yourself, because if you say that the vehicle class 
 doesn't include horse drivers, well, it also doesn't include cattle, pack 
 animals etc. They also have drivers, which is what the C3 sign prohibits. 
 Drive a camel or an elephant and you're not allowed. Not very likely maybe, 
 but nevertheless, walk next to a cow to move it between two fields and you 
 have become a driver. Tagging a simple C3 sign will be a lot of fun.
 
 Hence, in Belgium, vehicle will include all things that have a driver, 
 because that suits our traffic code best. I've always held the belief that 
 tagging should be as straight forward as possible and that one traffic sign 
 (or more specifically: one element of information on a traffic sign) should 
 preferably translate to one tag in OSM.

Has there been any discussion on this on other lists?  Some
proposal on where we can define that vehicle=no implies
bicylce=no for Belgium?

Do you know of any software that then properly uses that
information if there is such information?


Kurt


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

Re: [OSM-talk-be] Verbodsbord C3

[Kurt Roeckx]

On Mon, Sep 30, 2013 at 02:52:38PM +0200, Ben Laenen wrote:
 Als er geen verkeersbord apart voor fietsers bij staat moet je ook geen 
 bicycle-tag toevoegen. Als een fietsroute over zo'n weg loopt kan je het wel 
 in de route steken, fietsers kunnen altijd afstappen...

Fietser die afstappen zijn nog altijd bestuurders.

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

Re: [OSM-talk-be] Deelgemeentes en AGIV/CRAB

[Kurt Roeckx]

On Thu, Sep 26, 2013 at 05:31:36AM +0200, Marc Gemis wrote:
 On Wed, Sep 25, 2013 at 10:23 PM, Kurt Roeckx k...@roeckx.be wrote:
 
  On Wed, Sep 25, 2013 at 07:01:00PM +0200, Marc Gemis wrote:
   This is triggered by the note on OSM http://osm.org/go/0EpKQJ4xd-
   It requests that Muizen (part of Mechelen) is indicated.
   Muizen is already on the map, a few kilometers to the east.
  
   I see two solutions
   a) the administrative border is taken from some source
   b) each individual street gets an is_in or associatedStreet relation
  
   I typically do b, but as far as I can see in the generieke viewer of
  AGIV
   they do not care about deelgemeentes. Is this data available in the
   database ?
  
   Or should we just ignore the Deelgemeentes for our addresses ?
 
  I've used old maps to get that information. For instance the Atlas
  de Buurtwegen and the Popp maps ussually have enough information
  to be able to map it.
 
 
  Kurt
 
 
 where can I find these ?

http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources
says that for Antwerpen you need:
http://www.provant.be/bestuur/grondgebied/gis/atlas_buurtwegen/Raadplegen.jsp

But that doesn't seem to exist anymore, it seems to have moved to:
http://gisgeoloket.provant.be/SilverlightViewer_1_9/Viewer.html?Viewer=AtlasBuurtwegen

It seems to required silverlight.

I don't know if they provide WMS or not, but I have to guess not.


AGIV used have Popp via WMS, but it doesn't seem to exist anymore.

 
Kurt


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

Re: [OSM-talk-be] Deelgemeentes en AGIV/CRAB

[Kurt Roeckx]

On Wed, Sep 25, 2013 at 07:01:00PM +0200, Marc Gemis wrote:
 This is triggered by the note on OSM http://osm.org/go/0EpKQJ4xd-
 It requests that Muizen (part of Mechelen) is indicated.
 Muizen is already on the map, a few kilometers to the east.
 
 I see two solutions
 a) the administrative border is taken from some source
 b) each individual street gets an is_in or associatedStreet relation
 
 I typically do b, but as far as I can see in the generieke viewer of AGIV
 they do not care about deelgemeentes. Is this data available in the
 database ?
 
 Or should we just ignore the Deelgemeentes for our addresses ?

I've used old maps to get that information. For instance the Atlas
de Buurtwegen and the Popp maps ussually have enough information
to be able to map it.


Kurt


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

Re: [OSM-talk-be] House number problem

[Kurt Roeckx]

The wiki at lesat mentions 1;2

There seem to be several proposal around, and I'm not sure what
the best way is.

In any case, level/floor 0 is ground floor.


Kurt

On Thu, Sep 19, 2013 at 09:42:19PM +0200, Marc Gemis wrote:
 This evening I stumbled upon some buildings in Willebroek, where the
 housenumbers on the ground floor are different from the ones on the first
 floor. In general, we put the number on the complete building, but that's
 impossible in this case. So I will add different nodes which will also get
 a addr:floor. I assume this starts with 0 for the ground floor. Correct ?
 
 regards
 
 m


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

Re: [OSM-talk-be] mailing list good practice

[Kurt Roeckx]

On Mon, Sep 16, 2013 at 11:52:51AM +0200, Glenn Plas wrote:
 EN:
 
 If you want to be serious about this then a new topic should be
 initiated by sending a new mail instead of a reply with a new
 subject.  Every decent mailclient out there -usually- does not use
 the subject to 'thread' mails. instead it uses certain fields in the
 mail headers.  I noticed that mail-man (the mailing list handler of
 THIS list) does not seem to add those headers (in fact, they seem to
 be removed from outgoing mails, I cannot find those fields like
 below).
 
 example of those are :
 
 References: 20130914070031.83C7A1561AD6@server21
 CANHB50fV+JQ_DYnu91QYaURcRyAKk-pqbHGFMQmYzQZAeC=x...@mail.gmail.com
 5236af60.2050...@byte-consult.be
 In-Reply-To: 5236af60.2050...@byte-consult.be
 
 This is what the (E)mailers usually use when exchanging mail
 correspondence (non mailing list) when hitting 'Reply'

Those headers are there.  They're not there on mail you replied
to because he actually started a new thread, and your mail client
should have shown that.


Kurt


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

Re: [OSM-talk-be] AGIV

[Kurt Roeckx]

On Thu, Sep 12, 2013 at 06:03:00PM +0200, Ben Abelshausen wrote:
 And a translate into english:
 
 http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import/Free_open_data_licence_Flanders

Maybe we should add (a pointer to) the Ducth version, and say it's
a translation?


Kurt


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

Re: [OSM-talk-be] AGIV

[Kurt Roeckx]

On Fri, Sep 13, 2013 at 06:43:03PM +0200, Kurt Roeckx wrote:
 On Thu, Sep 12, 2013 at 06:03:00PM +0200, Ben Abelshausen wrote:
  And a translate into english:
  
  http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import/Free_open_data_licence_Flanders
 
 Maybe we should add (a pointer to) the Ducth version, and say it's
 a translation?

I made some changes in the wordings.


Kurt


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

Re: [OSM-talk-be] AGIV

[Kurt Roeckx]

On Fri, Aug 30, 2013 at 07:46:18PM +0200, Ben Abelshausen wrote:
 Hi,
 
 Maybe we should wait until Pieter has some kind of response for us. I would
 like to send something to the DWG that can be verified and is backed by
 some facts. Otherwise there will a be discussion about technicalities that
 might not matter at all.
 
 We will have less difficulty if we have all the details before we ask the
 DWG or send something to the imports-list.
 
 Also a translation of the license can still be useful.

So do you have any news on that?


Kurt


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

Re: [OSM-talk-be] AGIV

[Kurt Roeckx]

On Fri, Aug 30, 2013 at 04:11:04PM +0200, Ben Abelshausen wrote:
 Hello,
 
 There is a new episode in the AGIV-CRAB-OSM story.
 
 Today they released the CRAB database using the new flanders open data
 licence [1]. This means that now we can start the process of verification
 with the Imports-list and the DWG that the licence is ok and we can start
 using AGIV as a source when mapping.
 
 I will take care of this but help is always welcome. If there is someone
 dutch-speaking here with a verifiable legal experitse that could help me
 translate the licence into english and discuss with the DWG that would be
 nice.
 
 What I understand from reading the licence [2] using this data in the
 context of OSM should not be a problem anymore except for the need to
 mention the source when distributing the data. This should not be a problem
 because I have confirmation from someone at AGIV that a source-mention on
 the wiki is enough for them. This means they will consider themselves one
 of the © OpenStreetMap contributors :-) !

Reading the license, I can see no problem at all.

I'm not sure what you mean with verifiable legal experitse.  I'm
not a lawyer, but I did read many license to check that they are
free or not.  If that is good enough I'm willing to help with
getting this officially approved.


Kurt


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

Re: [OSM-talk-be] Namen arrondissementen

[Kurt Roeckx]

Ik heb lang geleden een bug geopened voor de reverse lookup:
https://trac.openstreetmap.org/ticket/3430

Misschien moeten we ook vragen om bij de lookup ook
alleen naar bepaalde levels te kijken?


Kurt

On Mon, Aug 12, 2013 at 04:52:58PM +0200, Bart Van Lancker wrote:
 Op dit moment zijn de namen van de arrondissementen aangegeven met louter de
 naam, bvb. Gent. Nu is dit zeer verwarrend voor de gebruiker, want Gent
 is uiteraard ook een deelgemeente en een gemeente. 
 Als je bijvoorbeeld zoekt op Veldstraat Gent krijg je de klassieke
 Veldstraat, maar ook de Veldstraat in Lochristi, die aangegeven wordt met
 
 Veldstraat, Lochristi, Gent, Oost-Vlaanderen, Vlaanderen, 9041, België.
 
 Die 9041 tussen Vlaanderen en België vind ik ook hoogst bizar (postnummer
 zou aan deelgemeente toegekend moeten worden), maar sowieso zou 
 
 Veldstraat, Lochristi, Arrondissement Gent, Provincie Oost-Vlaanderen,
 Vlaams Gewest,  België
 
 veel duidelijker en correcter zijn, en zeker als je kijkt naar grenzen
 tussen gemeenten : Eeklo-Zomergem-Eeklo-Gent bijvoorbeeld. Dit wordt dan
 Eeklo - Zomergem - Arrondissement Eeklo - Arrondissement Gent
 
 Mijn voorstel is dus de namen van de administratieve arrondissementen (en
 eventueel zelfs de provincies) te wijzigen. 
 
 Groeten
 
 Bart
 
 
 ___
 Talk-be mailing list
 Talk-be@openstreetmap.org
 http://lists.openstreetmap.org/listinfo/talk-be
 

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

Re: [OSM-talk-be] Firefighters and OSM + fire_hydrant

[Kurt Roeckx]

On Thu, Jul 25, 2013 at 10:16:14AM +0200, Teddy wrote:
 2013/7/24 Kurt Roeckx k...@roeckx.be
 
  fire_hydrant
 
 
 
 Hello Kurt,
 No, there are 3 numbers for the offset, in the tag fire_hydrant:position

On the signs there are only ever 2 of those numbers.  Either you
one to the left or one to the right.  Never both.

Anyway, I see no point in mapping that a sign says the hydrant
that much away from the sign.  Those numbers are their for people
who are looking for the hydrant to find by saying about where they
should look.  In my expieriences they're also not very accurate.

I think that we want to map where the hydrant it, not map the sign
and say the hydrant has an offset relative to that sign.  I assume
you also don't map road signs pointing to a city and then saying
that that sign says that the city is that many km away.  I really
see no value whatsover in mapping what the sign says about the
position.

 ** fire_hydrant:position= lane/parking_lot/sidewalk/green; left
 offset;front offset;right offset

None of the the various wiki's mention anything about the offsets.
I also see no point in using 3 numbers for it while the sign will
only ever have 2 on them.

 Rem : on fire signaling panels (Belgium, France, Deutchland) :
 B is for Borne - above ground
 H is for Hydrant - below ground

Yes, I already said that in my mail.


Kurt


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

Re: [OSM-talk-be] Firefighters and OSM + fire_hydrant

[Kurt Roeckx]

On Wed, Jul 24, 2013 at 10:13:53AM +0200, Teddy wrote:
 Bonjour,
 
 The numbers are meabe for the position of the Hydrant (under the sidewalk)
 from the signpost.
 On the official fire signaling panels (for Hydrants) see :
 https://docs.google.com/file/d/0B72s2PiIFkrZNVBFOVRTYmRURlE/edit?usp=sharing
 
 You have 3 numbers :
 at left : the distance between the base of the signpost at left and the
 Hydrant
 in the middle : the distance between the base of the signpost (in
 front) and the Hydrant   ex:1.2m
 at right : the distance between the base of the signpost at right and the
 Hydrant ex:0.8m
 (if the number is negative the position of the Hydrant is behind the
 signpost)
 
 For this tag :
 *fire_hydrant:position = sidewalk;0.0;1.2;0.0*
 left : 0m
 front : 1,2m
 right : 0m

That sign should indicate where the hydrant really is, so it's
easier to locate.  I see no point in mapping where the sign is
and we should just map where the hydrant is instead.

For a proper meaning of the sign, in Dutch, see:
http://blog.seniorennet.be/westendseblik/archief.php?catID=1637

In short:
It has 2 numbers, indicating an x and y offset in meters
There is a letter, B for below ground, H for above ground
The B or H might be followed by a number indicting the
diameter



Kurt


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

Re: [OSM-talk-be] Geocoding met foute postcode's

[Kurt Roeckx]

On Mon, Jul 22, 2013 at 05:20:07PM +0200, Glenn Plas wrote:
 Vandaag volgende tegengekomen:
 
 http://nominatim.openstreetmaps.org/reverse.php?format=jsonlat=50.9420900lon=4.7305583zoom=18addressdetails=1email=gl...@byte-consult.beaccept-language=nl,en;q=0.8,fr;q=0.5
 
 resultaat:
 
 {place_id:12246533,licence:Data \u00a9 OpenStreetMap
 contributors, ODbL 1.0. 
 http:\/\/www.openstreetmap.org\/copyright,osm_type:node,osm_id:1156867059,lat:50.9424155,lon:4.7310233,display_name:Station,
 Stationsstraat, Rotselaar, Leuven, Vlaams-Brabant, Vlaanderen,
 3012KA, Belgi\u00eb, European 
 Union,address:{bus_stop:Station,road:Stationsstraat,city:Rotselaar,county:Leuven,state:Vlaanderen,postcode:3012KA,country:Belgi\u00eb,country_code:be,continent:European
 Union}}
 
 Daar komt als postcode uit: 3012KA

Looking at postal codes, it seems most of them are wrong and not
tagged?  You probably now get whatever is closest by?

The only information I can find now is the place= nodes,
which ussually have openGeoDB:postalcode, and sometimes
also postalcode.

Does it make sense to move that information to relations
instead?  I guess they ussually fall together with
administrative boundaries.  But I'm not sure about
cities that have multiple postcal codes.


Kurt


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

Re: [OSM-talk-be] Geocoding met foute postcode's

[Kurt Roeckx]

On Mon, Jul 22, 2013 at 09:22:47PM +0200, Marc Gemis wrote:
 The only good solution is to create post code polygons. This is stated e.g.
 on the nominatim FAQ page:
 http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#postal_codes
 I don't know hpw we can do this.

So basicly most administrative boundaries (relations) should also
be turned into a polygon? 



Kurt


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

Re: [OSM-talk-be] Geocoding met foute postcode's

[Kurt Roeckx]

On Mon, Jul 22, 2013 at 10:44:51PM +0200, Ben Laenen wrote:
 On Monday 22 July 2013 22:24:09 Kurt Roeckx wrote:
  On Mon, Jul 22, 2013 at 09:22:47PM +0200, Marc Gemis wrote:
   The only good solution is to create post code polygons. This is stated
   e.g. on the nominatim FAQ page:
   http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#postal_codes
   I don't know hpw we can do this.
  
  So basicly most administrative boundaries (relations) should also
  be turned into a polygon?
 
 Boundary relations are polygons, the same kind as a multipolygon relations. 
 So 
 no need to change anything

I tried adding it to the boundary relation 1 hour ago, but it's still showing
a wrong result here.  My expierence is that nominatim updates
after like a few minutes already.


Kurt


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

Re: [OSM-talk-be] Fix my street

[Kurt Roeckx]

On Sun, Jul 07, 2013 at 10:27:07AM +0200, André Pirard wrote:
 On 2013-07-06 19:55, A.Pirard.Papou wrote :
  On 2013-07-06 15:06, Kurt Roeckx wrote :
  I've known about the fix my street project for some time, but I
  just found this:
  http://fixmystreet.irisnet.be/
 
  This is apparently something that's orginaised by Brussel itself,
  and currently 14 of the 19 municipalities use.
 
  Has anybody tries to contact the Flemisch or Walloon government
  to try and do the same thing?  I think this could be useful to
  have.
 
  Good idea indeed, especially if an application were written using OSM.
  ...
 
 Afterthought:  that application already exists. It's called OpenStreeBugs.
 (Even the name is appropriate for reporting holes in the streets ;-))

I think they have a totally different purpose.  OpenStreetBugs and
Notes are about problems with the map.  Those things need to be
fixed in openstreetmap.   FixMyStreet are problems that aren't
related to the map but with the street and other things that
someone needs to fix in the real world.

That doesn't mean that that the software for FixMyStreet can't
be improved.  It's open source.


Kurt


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

[OSM-talk-be] Fix my street

[Kurt Roeckx]

I've known about the fix my street project for some time, but I
just found this:
http://fixmystreet.irisnet.be/

This is apparently something that's orginaised by Brussel itself,
and currently 14 of the 19 municipalities use.

Has anybody tries to contact the Flemisch or Walloon government
to try and do the same thing?  I think this could be useful to
have.


Kurt


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

Re: [OSM-talk-be] historic=battlefield

[Kurt Roeckx]

On Mon, Jun 24, 2013 at 09:37:46PM +0200, Marc Gemis wrote:
 I'm interested in the usage of historic=battlefield.
 
 I saw that someone added this to e.g. to a cemetery in Eppegem (Zemst)
 http://www.openstreetmap.org/browse/node/2308368137
 
 There are also a lot of those tags around Bonheiden - Rijmenam - Keerbergen:
 http://geschichtskarten.openstreetmap.de/historische_objekte/?zoom=13lat=51.00577lon=4.56379layers=BFT
 
 Are these really battlefields or are they bunkers, cemeteries (something
 else) ?

They're ussually bunkers.  I always fix them when I see them.


Kurt


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

Re: [OSM-talk-be] Nominatim administrative boundaries

[Kurt Roeckx]

On Mon, Jun 17, 2013 at 10:35:22PM +0200, Kurt Roeckx wrote:
 
 The only thing I can think of as a source of this information is
 the atlas der buurtwegen / atlas des chemins vicinaux.  At least
 it should cover all old borders, and is probably want we want to
 use to mark the old borders.
 
 The question is about under what license those are available.
 It's my understanding that copyright for the original maps
 has expired.  I guess the same applies to scanned versions
 of those.  But I would guess that the georeferenced versions
 do have a copyright, or could at least be problematic.
 
 Assuming we can use the old cards, it has all the parcels
 on them.  They could help in trying to find the border based
 on pictures of them, but this doesn't always seem to be easy
 to do.  But as far as I know, this is currently the only
 available way to do it without license problems.

So I contacted the province Vlaams Brabant about this, and
they said we can use the atlas der buurtwegen for this.

They currently don't offer WMS, but they planned this for 2014.


Kurt


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

Re: [OSM-talk-be] Nominatim administrative boundaries

[Kurt Roeckx]

On Tue, Jun 18, 2013 at 02:11:33PM +0200, Glenn Plas wrote:
 The only thing I can think of as a source of this information is
 the atlas der buurtwegen / atlas des chemins vicinaux.  At least
 it should cover all old borders, and is probably want we want to
 use to mark the old borders.
 Yes, I noticed they are reviving those too.  Over here in Zemst they
 recently put up name signs on the 'kerkwegen'.   And references to
 that Atlas have been made in the past, just can't find it directly.
 But that's a good suggestion.

Every Flemisch province has it's own gis system where you can view
them.  See:
http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Mapping_resources


Kurt


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

Re: [OSM-talk-be] Nominatim administrative boundaries

[Kurt Roeckx]

On Sun, Jun 16, 2013 at 07:02:01PM +0200, Glenn Plas wrote:
 Kurt (a.o),
 
 I checked the Rotselaar/Werchter setup and I made a single change to
 the Rotselaar relation:
 
 http://www.openstreetmap.org/browse/relation/214462
 
 The only thing I think was missing is adding the Werchter boundary
 relation as a 'subarea' to the Rotselaar one.

Thanks for fixing that.

 Did the same setup for Rijmenam/Bonheiden.  There aren't many
 'fusiegemeentes' being mapped -unfortunately- although it would be
 highly interesting to have them, not only from a nominatim (search)
 point of view, but also for addressing in general.

The problem is ussually finding the right data, and making sure
that there is no license problem with adding that data.

 The change I made will probably trigger some changes in the
 nominatim search result in a few days , I now expect that Leuven
 will be replaced by Rotselaar in the search result set when looking
 up Werchter in a few days.

Nominatim shows all the levels, including those I think it
shouldn't.  It currently shows:
Werchter, Rotselaar, Leuven, Flemish Brabant, Flanders, 3118,
Belgium, European Union

I just noticed that if you look up 3118 Rotselaar in google
maps, that it properly shows what Werchter looks like, because
it has it's own postal code.  It's more correct than what I
added.


Kurt


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

Re: [OSM-talk-be] Nominatim administrative boundaries

[Kurt Roeckx]

On Fri, Jun 14, 2013 at 05:04:56PM +0200, Glenn Plas wrote:
 http://www.vlaamsbrabant.be/binaries/kaart-vlaamsbrabant-fusiegemeenten-deelgemeenten_tcm5-11555.pdf

That's not even complete.  For instance Haacht exists of Haacht,
Wespelaar, Tildonk, Wakkerzeel en Kelfs.  You can find signs on
the streets for all 5 of them.  There exists statistics about
people living in all 5 of them, birthrates, ...  So there clearly
is some definition of what those 5 are.  But I've never seen a
map clearly saying where the borders are like they are now.

If you look at the map as produced by province, Wakkerzeel and
Kelfs seem to be part of Tildonk now.

Historically, Kelfs used to be part of Herent and Wakkerzeel
used to be part of Werchter.  If you combine old and new borders
you might be able to define where those are.  I have some old
maps, but I'm not sure they are detailed enough to put the borders
like they really are.


Kurt


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

Re: [OSM-talk-be] Nominatim administrative boundaries

[Kurt Roeckx]

On Fri, Jun 14, 2013 at 07:49:55PM +0200, Kurt Roeckx wrote:
 On Fri, Jun 14, 2013 at 05:04:56PM +0200, Glenn Plas wrote:
  http://www.vlaamsbrabant.be/binaries/kaart-vlaamsbrabant-fusiegemeenten-deelgemeenten_tcm5-11555.pdf
 
 That's not even complete.  For instance Haacht exists of Haacht,
 Wespelaar, Tildonk, Wakkerzeel en Kelfs.  You can find signs on
 the streets for all 5 of them.  There exists statistics about
 people living in all 5 of them, birthrates, ...  So there clearly
 is some definition of what those 5 are.  But I've never seen a
 map clearly saying where the borders are like they are now.
 
 If you look at the map as produced by province, Wakkerzeel and
 Kelfs seem to be part of Tildonk now.
 
 Historically, Kelfs used to be part of Herent and Wakkerzeel
 used to be part of Werchter.  If you combine old and new borders
 you might be able to define where those are.  I have some old
 maps, but I'm not sure they are detailed enough to put the borders
 like they really are.

Anyway, I added Werchter based on what I know about it.  It might
not be really correct, but I think it's good enough.


Kurt


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

Re: [OSM-talk-be] FW: AGIV

[Kurt Roeckx]

Ben,

Ik denk dat als er een contract gesloten word dat er dan licentie
voorwaarden aan gekoppeld gaan zijn.  De vraagis natuurlijk of
deze compatible zijn met osm.

Misschien zou het ook voor hun gemakkelijker zijn als we een vzw
of zo waren.


Kurt

On Mon, Mar 11, 2013 at 10:26:34AM -0700, Ben Abelshausen wrote:
 Het is meer om het gebruik van de database in kaart te brengen dat er
 iemand van/voor OSM moet tekenen.
 
 Ik denk dat er zeer weinig echte verantwoordelijkheden aan verbonden
 zijn... Ik zal dat ook nogeens navragen!
 --
 From: Jo
 Sent: 11/03/2013 18:12
 To: OpenStreetMap Belgium
 Subject: Re: [OSM-talk-be] FW: AGIV
 
 Moet ieder van ons die de adresgegevens wil gebruiken dan individueel zo'n
 contract ondertekenen?
 
 Het is al heel mooi dat we de luchtfoto's mogen gebruiken!
 
 Jo
 
 Op 11 maart 2013 18:03 schreef Ben Abelshausen
 ben.abelshau...@gmail.comhet volgende:
 
  Heb de vraag doorgemaild naar iemand van AGIV... Hieronder de reactie!
 
  Ik stel voor dat we zo snel mogelijk ervoor zorgen dat dit in orde komt!
  Ik heb vandaag geen toegang tot mijn laptop maar ik wil dit de volgende
  dagen gerust uitzoeken...
  --
  From: Tom Van Herck
  Sent: 11/03/2013 15:50
  To: Ben Abelshausen
  Subject: RE: [OSM-talk-be] AGIV
 
   Ben,
 
 
 
  Die foto's kunnen jullie vrij gebruiken als achtergrond. Technische en
  andere info vind je op http://www.agiv.be/gis/nieuws/?artid=2000
 
  Om ook nog eens de huizen en huisnrs te kunnen gebruiken moet eerst een
  contract ondertekend worden waarover ik vorige keer al sprak.
 
 
 
  Groeten,
 
 
 
  Tom
 
 
 
  *Van:* Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
  *Verzonden:* maandag 11 maart 2013 15:25
  *Aan:* Tom Van Herck
  *Onderwerp:* FW: [OSM-talk-be] AGIV
 
 
 
  Best Tom,
 
  Een vraagje vanuit OSM dat vandaag op de mailinglijst verscheen. Weet jij
  of gebruik mogelijk is? Als achtergrond en als hulp om mapping te doen in
  OSM welteverstaan...
 
  De luchtfotos alleen zouden ook al een grote help zijn...
 
  Groeten,
 
  Ben
--
 
  *From: *Guy Vanvuchelen
  *Sent: *11/03/2013 15:07
  *To: *talk-be@openstreetmap.org
  *Subject: *[OSM-talk-be] AGIV
 
  Zojuist stoot ik op een website van AGIV Agentschap van Geografische
  Informatie Vlaanderen.
 
  http://ogc.beta.agiv.be/gdiviewer/?simple=true
 
  Hier zie je luchtfoto's  (Orthofoto) die scherper zijn dan Google of Bing,
  maar ook de huizen (met huisnummer!) en percelen staan getekend.
 
  Ik zie nergens iets staan van enige bescherming van die gegevens maar het
  is waarschijnlijk te mooi om waar te zijn, dat we die zouden mogen gebruiken
 
 
 
  Guy Vanvuchelen
 
 
 
  --
 
  AGIV e-mail disclaimer: http://www.agiv.be/gis/organisatie/?artid=355
 
  ___
  Talk-be mailing list
  Talk-be@openstreetmap.org
  http://lists.openstreetmap.org/listinfo/talk-be
 
 

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


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

Re: [OSM-talk-be] Initial stuck to the name

[Kurt Roeckx]

On Mon, Jan 07, 2013 at 05:20:47PM +0100, Guy Vanvuchelen wrote:
 Bij een controle via osmose krijg ik 'Initial stuck to the name' als
 foutmelding.  Het zou om een spellingfout gaan.
 
 Wat is er fout aan bijvoorbeeld O.L.Vrouw ten Steenkapel of L. Claeslaan
 ? Moet de naam voluit geschreven worden (moeilijk in het geval van L.
 Claeslaan!) of moeten de puntjes weggelaten worden.  

Het is O.L. Vrouw ten Steenkapel of O.L.V. ten Steenkapel
en L. Claeslaan

L.Claeslaan is fout.


Kurt


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

Re: [OSM-talk-be] Addresses in Belgium

[Kurt Roeckx]

On Mon, Jan 07, 2013 at 08:17:11AM +0100, Jo wrote:
 The associatedStreet relation has the streetname in 'name', not in
 addr:street. I also found some relations where this was done incorrectly.
 
 It is possible to fix all of them in one go. Advise me if you want me to do
 so.

As far as I understand it, there is no reason to give the relation
a name other than being useful to find it.  The street name itself
should come from the member that is marked as street.  It something
displays the name of the relation as addr:street information, I think
that's just wrong and should get fixed.


Kurt


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

Re: [OSM-talk-be] Addresses in Belgium

[Kurt Roeckx]

On Sat, Dec 22, 2012 at 03:23:15PM +0100, Sander Deryckere wrote:
 
 The first thing you notice is that there are a lot of features with
 housenumber information, but without street information. While other
 information (such as city) can be determined from closed boundaries. It's
 often ambiguous and hard to determine the street from other OSM features.

Osmose counts alot of errors in Belgium because of that.  See:
http://osmose.openstreetmap.fr/errors/graph.png?country=belgium

About 50% of those are because of missing addr:street or
associatedStreet relation.

It would in general be a good thing that we try and fix all those
errors.


Kurt


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

Re: [OSM-talk-be] opendata.antwerpen.be

[Kurt Roeckx]

On Thu, Nov 08, 2012 at 11:38:18PM +0100, Jan-willem De Bleser wrote:
 Another relevant point in the license:
 
 De toegekende rechten hebben betrekking op: ... De samenstelling van
 collaboratieve databases - Het maken van tijdelijke of permanente, en
 geheel of gedeeltelijke reproducties met om het even welk middel en in
 om het even welke vorm, met inbegrip van afgeleide databases of als
 geheel van collaboratieve databases - Het geheel of gedeeltelijk
 verspreiden, mededelen, bekendmaken, verhuren, ter beschikking stellen
 of publiek verspreiden van de informatie, met om het even welk middel
 en in om het even welke vorm, met inbegrip van afgeleide databases of
 als deel aan een collaboratieve database
 
 They're talking to us here, I believe. They've obviously foreseen that
 groups like OSM and companies like, say, Foursquare, will want to use
 this data.
 
 I have only one issue. The license says they retain all their IP
 rights, so is this compatible with the contributor terms of OSM? Or,
 are we maybe creating a derivative work when we map based on their
 data?

It also says:
De gebruiker mag deze licentie alleen overdragen aan een derde
partij met de schriftelijke toestemming van de licentiegever

It think that basicly prevents us from using it, it basicly says
we can't distribute it to other people without their written
permission.  So if we ask them something, we should have it
in writing.  And I guess it would make sense to them if we
were an organisation like a vzm/asbl.

Also note that the license of osm doesn't have the same
requirements as theirs, and users of osm would not be
aware of that.  I think this might also create a legal
problem.


Kurt


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

Re: [OSM-talk-be] Vergadering/Réunion OSM-Service Public de Wallonie yesterday

[Kurt Roeckx]

On Thu, Oct 04, 2012 at 08:14:46AM +0200, Nicolas Pettiaux wrote:
 2012/10/4 Kurt Roeckx k...@roeckx.be:
  In Vlaanderen is er ook AGIV.
 wat is AGIV ? Een URL ?

http://www.agiv.be and http://www.geo-vlaanderen.be/

It's the Flemisch agency for geografical information.  They have
things like position information, address information, land use
information, aereal pictures, ...


Kurt


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

Re: [OSM-talk-be] Vergadering/Réunion OSM-Service Public de Wallonie yesterday

[Kurt Roeckx]

On Thu, Oct 04, 2012 at 09:45:41AM +0200, Nicolas Pettiaux wrote:
 2012/10/4 Kurt Roeckx k...@roeckx.be:
 
  http://www.agiv.be and http://www.geo-vlaanderen.be/
 
  It's the Flemisch agency for geografical information.  They have
  things like position information, address information, land use
  information, aereal pictures, ...
 
 has any of you already asked them if they would release some of these
 information in a way that is compatible with OSM ?

Yes, but it's been years ago.


Kurt


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

Re: [OSM-talk-be] Vergadering/Réunion OSM-Service Public de Wallonie yesterday

[Kurt Roeckx]

On Wed, Oct 03, 2012 at 02:08:46PM +0200, Sander Deryckere wrote:
 De taal is enkel van belang voor bevoegdheden van de gemeenschappen. De
 gewesten zijn in feite niet linguistiek maar economisch gesplitst.
 
 De vraag is dus van wie we hulp zouden kunnen krijgen, en volgens mij is
 dit van de nationale organisaties (waaronder het NGI/IGN valt), en van
 regionale organisaties (zoals het PICC, correct?), niet van organisaties
 die onder de gemeenschappen vallen (zoals wel het geval is bij sportieve en
 culturele verenigingen).

In Vlaanderen is er ook AGIV.  Ik denk dat Brussel en Wallonie hun
eigen tegenhanger daarvan hebben.  Het valt volgens mij ook onder
de bevoegdheid van de gewesten.


Kurt


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

Re: [OSM-talk-be] Names of Arrondissements

[Kurt Roeckx]

On Wed, Aug 29, 2012 at 01:54:32PM +0200, Sander Deryckere wrote:
 I would like to discuss the naming of the arrondissements in Belgium.

My problem with adding them to osm is that we have 3 kinds:
- administrative;
- judicial;
- electoral.

Which of them do you want to map, and how will you tell them apart
if you want to map more than 1 of them?


Kurt


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

Re: [OSM-talk-be] Missing Maxspeed in Brussels

[Kurt Roeckx]

On Thu, Aug 02, 2012 at 11:37:45PM +0200, eMerzh wrote:
 Hello everybody ..
 
 i was playing a bit with the OSM routing machine at
 http://map.project-osrm.org/ ,
 one of the best router based on osm.
 
 I discovered that a lot of routing decisions where not optimal and i
 found that the lack of maxspeed was often the cause of it.
 When a way is tagged as primary it assume that you can do 120 km/h  or
 smth... if you can only do 50, you can imagine the difference :)

A primary should default to 90 / 50, not 120.

See:
https://wiki.openstreetmap.org/wiki/OSM_tags_for_routing/Maxspeed

(I don't agree with trunk being 90, I think it should be 120)


Kurt


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

Re: [OSM-talk-be] Navteq de lijn en google maps!

[Kurt Roeckx]

On Thu, Nov 03, 2011 at 10:22:41PM +0100, Jo wrote:
 PS: ik ben op jacht naar foto's van bushaltes van De Lijn over heel
 Vlaanderen. Wie er heeft, of wie anderen kan motiveren om er te maken
 mag ze naar mij (laten) doorsturen op dit adres. Want ik zou op die
 manier alle haltes erin willen krijgen, aangezien De Lijn hun data aan
 ons niet wil vrijgeven, zullen we het zelf moeten doen. Als de haltes
 er eenmaal instaan, kunnen de routes volgen, op termijn. Ook zou ik
 willen vragen aan mensen die zelf bushaltes ingeven, om tenminste de
 ref=xx erbij te zetten en als je wat meer tijd hebt ook een
 route_ref=315;316;317;410. De positie van de haltes is vrij
 gemakkelijk te bepalen voor zowat de helft ervan, aangezien er in
 grote letters B U S staat, wat zeer goed zichtbaar is op Bing. Als er
 geen wegmarkering voor de halte is en ook geen hokje, zou het leuk
 zijn om ook foto's van de aanliggende huisnummers te maken en door te
 sturen.

Als ik aan het rond gaan ben, en ik zie bushaltes, neem ik altijd
een foto van het bord.  Ik zou die er allemaal al moeten hebben
ingezet, samen met alle routes die op het bord vermeld staan,
samen met de naam en het referentie nummer van de halte.


Kurt


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

Re: [OSM-talk-be] Fietsnet using OSM

[Kurt Roeckx]

On Sun, Aug 28, 2011 at 05:37:11PM +0200, Jan Herrygers wrote:
   In principle you can not combine licenses. Because they are all not
   compatible, even if they are also some kind of 'open', except for
   Public Domain, were you can do what you want.
  
  Licenses can be compatible, there are alot of cases of it.  [...]
 
 Sadly the contributor terms require an unlimited license (like I said above). 
 And it is that [profanity removed] unlimited license that is incompatible 
 with 
 the ODbL and about any other existing license except public domain.

So they require that if you contribute to OSM that they can put
any license they want on it, which basicly makes it very hard
to add new data that's copyright by someone else.

But that doesn't mean that as user of the OSM data you could
combine the OSM data with other data under a different but
compatible license.


Kurt


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

Re: [OSM-talk-be] Fixing administrative borders

[Kurt Roeckx]

On Wed, Jun 08, 2011 at 11:04:56AM +0200, Ben Laenen wrote:
 Ralf Hermanns wrote:
  I think there is conflicting information here:
  http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dadministrative and here:
  http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
  
  On the Tag:boundary=administrative page (first link) it says
  communities/provinces go on level 5 and arrondisments on 6 - while on the
  subproject page it only list the language communites on level 5 and puts
  provinces onto 6 (thereby moving arrondisments and towns further down)
 
 Don't have much time to reply, so a short one:
 
 Always look at the country specific page to get the answers. The 
 international 
 page is just there for some guiding, but the countries have to make their 
 own rules. As is the case for Belgium.
 
 country: level 2
 regions: level 4
 communities: level 5
 provinces: level 6
 arrondissements: level 7
 municipalities: level 8
 district/deelgemeentes/sections: level 9

This is atleast how it used to be, and what I've always used.

I have some comments about this.

I think we should not map level 5, because it's more about people
than it is about land.  Brussels is part of both the Dutch and the
French community, and last time I looked at it, it was also
properly mapped like that.

Brussels is also special in that it doesn't belong to any
province.  So it ends up with no level 6 and 2 level 5s,
and a whole level 4 for itself.

But my biggest problem with level 5 is that it's not actually
a sublevel of 4, if mapped it would make more sense to be at
the same level as the regions.

And maybe we should map the 4 language regions too, if you
really want to go and map everything.

I also have a problem with level 7.  We have 3 tpes of 
arrondissements:
- Administrative (43 of them)
- Judicial (27 of them)
- Voting (depends)


I would also like to point out that the name of the tag implies
administration levels, so if you would want to map the
arrondissements, it should be the administrative level.  But
I'm not sure adding them to the map adds any value when using
the administrative level, as there isn't any real administration
at that level.

When only considering to map administrative levels, it would also
mean that you can't map any sub-municipalities at level 9 because
they don't have any administration, at least most don't.  But I do
think that mapping at level 9 where possible is useful.

Maybe some of those things shouldn't be mapped as an
administrative, but could be on the map with some other tag.


Kurt


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

Re: [OSM-talk] Nominatim US places

[Kurt Roeckx]

On Sat, Jan 01, 2011 at 05:50:16PM +, Shaun McDonald wrote:
 
  so should we be
  
  1) adding explicit info to ways about town/county
 
 No, that causes huge amounts of duplicate info that is difficult to update.
 
  
  or
  
  2) fixing county  town boundary relations
 
 This is much better. Once the boundary has been fixed, then the point that 
 may be there for the place should be removed too.

Having a node to indicate the center of a town/city/... can be
useful too, even if you already have a boundary for it.


Kurt


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

Re: [OSM-talk] Nominatim US places

[Kurt Roeckx]

On Mon, Jan 03, 2011 at 03:24:34PM -0600, Toby Murray wrote:
 On Mon, Jan 3, 2011 at 3:12 PM, Kurt Roeckx k...@roeckx.be wrote:
  Having a node to indicate the center of a town/city/... can be
  useful too, even if you already have a boundary for it.
 
 It seems like duplicate information to me. Like mapping a walmart with
 both a building outline tagged as a shop and a point in the middle
 tagged the same way. What do you define as the center of a town? If
 it is just the centroid of the border polygon then this can be
 determined from the boundary. If you mean the central business
 district or town hall, then that should be mapped appropriately with
 landuse and building polygons.

The center is ussually a market place or the church or something
like that.  It's ussually where the oldest building are and the
rest was build around it.  It has nothing to do with the centre
of the admin level boundary, but might be the center of one
of the various landuses.  It's the place where I expect the
name of the place to be on the map.  It's not always a very
specific place, but ussually a rather small area.

The lowest mapped admin level might have several places in it
which each their own name, and the lowest admin level is
one of those.  And it's not always possible to map lower
admin levels.


Kurt


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

Re: [OSM-talk] Explicit tagging of name language

[Kurt Roeckx]

On Mon, Dec 06, 2010 at 10:00:57AM +, Ed Avis wrote:
 
 In an attempt to fix this I have asked the maintainer of
 http://keepright.ipax.at/ to add a data check.  Where a choice of languages
 exists for a name, then there should be one that corresponds to the main
 'name' tag.  In other words for the example above there was name=Scotland but
 not any name:XX=Scotland.  One should be added indicating the language of this
 name, so that user interfaces can choose among the name:XX.  Of course if an
 object has just a single name tag to be used for all languages, that's fine.

This will atleast give bogus warnings with places like Brussels that
are bilingual, where name actually contains the name in both languages
(Dutch and French), and also has the language specific name for both
languages.


Kurt


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

Re: [OSM-talk-be] Volunteer needed regarding an academic project in relation to the OSM Foundation

[Kurt Roeckx]

On Fri, Sep 17, 2010 at 12:05:29PM +0100, Emilie Laffray wrote:
 Hello,
 
 We are currently looking at setting up a collaboration with the university
 of Leuven/Louvain in Belgium with legal researcher for the OpenStreetMap
 Foundation. If you are interested in legal topics and that you live in
 Belgium, please contact me. I can answer in English and in French if needed.
 I am afraid my flemmish is not good enough to reply to.
 Those topics are covering issues with licenses (not the most interesting
 topic for them) but also liabilities, reuse within INSPIRE and PSI
 directives, etc... There are many interesting legal topics to be
 investigated and it would be great if someone could step up.

I'm not really sure what you're expecting of us.  Personally I
would like to have more information about all of this, but I
probably don't have time to go the university to talk to people.
But if that's one of the things you need, maybe someone here
can.


Kurt


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

[OSM-talk] Zonal restrictions.

[Kurt Roeckx]

Hi,

I'm looking for a way to map restrictions for a zone.  This
includes things like maxspeed, maxweight and parking restriction.
I want to avoid having to place those tags on all the roads inside
the zone, specially for large zones, since it's very easy to forget
one.

What currently comes closest to what I want is an area with a
place= tag, but the meaning of that is not clearly defined,
and you can't do everything with that.

So I want to have a way to mark all roads inside the zone to
have the restriction for that zone.  It should probably also
have a way to indicate that you're inside the built-up area.
If the same type of restriction (for instance maxspeed) is
placed both on the zone and the highway itself, the one for
the highway should be used.

For a previous discussion about this, see:
http://wiki.openstreetmap.org/wiki/Talk:OSM_tags_for_routing/Maxspeed#Inside_.2F_outside_built-up_area


Kurt


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