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

2013-12-05 Thread 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

2013-12-05 Thread Glenn Plas

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


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

2013-12-05 Thread Marc Gemis
On Thu, Dec 5, 2013 at 9:25 AM, Kurt Roeckx  wrote:

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


I used the place= node as admin_centre. That's also the one that I moved.
Should there be a difference between the two ?
As for the two relations: I'm still fighting nominatim. I want all the
street(segments) within the Muizen area to return 2812 as post code. In
Germany they use the dedicated boundary=postal_code. This is also what was
recommended by someone on a similar question on help.openstreetmap.org.
So I tried that.

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

2013-12-05 Thread Marc Gemis
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  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


[OSM-talk-be] Fwd: [OSM-talk] SotM-EU 2014 in Karlsruhe, Germany

2013-12-05 Thread Ben Abelshausen
FYI: SOTM-EU!

Not that far for most of us... :-)
-- Forwarded message --
From: Frederik Ramm 
Date: Thu, Dec 5, 2013 at 3:33 PM
Subject: [OSM-talk] SotM-EU 2014 in Karlsruhe, Germany
To: Talk Openstreetmap , "d...@openstreetmap.org" <
d...@openstreetmap.org>


Hi,

   today I have the pleasure to announce that we'll be holding SotM-EU
2014 in Karlsruhe, on 13-15 June. We've set up the web page at
www.sotm-eu.org and we'll be posting news there and on @sotmeu on Twitter.

We'll be trying to emulate the success of the 2011 Vienna conference,
bringing together everyone who does anything interesting in & with
OpenStreetMap in Europe.

The call for papers will be out soon, with registration to open early
2014. We already have a good international programme committee preparing
that but if you'd like to join the programme committee or otherwise help
organising the conference (or aspects of it), don't be shy and write to
i...@sotm-eu.org. Same if you have any ideas that you'd like the
organisers to consider.

We'll be distributing this announcement to the dev and talk lists
as well as to talk-fr and talk-de. If you are on one of the other
regional European lists, we would be grateful if you could forward
the announcement.

I'm looking forward to seeing you in Karlsruhe next year!

Bye
Frederik

PS: "we" = "the local Karlsruhe team & everyone involved"

--
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

___
talk mailing list
t...@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk
___
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

2013-12-05 Thread 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=10&title=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  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

2013-12-05 Thread Ben Abelshausen
When I read the licence file it's the same conditions as the CRAB dataset.
There is an obligation to mention the source, just add it to the list of
sources on the wiki and specify that it's about borders.

Met vriendelijke groeten,
Best regards,

Ben Abelshausen


On Thu, Dec 5, 2013 at 4:36 PM, Kurt Roeckx  wrote:

> 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=10&title=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 
> 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
>
___
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

2013-12-05 Thread Bart Van Lancker
 

 

http://www.openstreetmap.org/search?query=waterkluiskaai#map=17/51.04681/3.7
5473

 

Sint-Amandsberg has 9040, which is correct :

 

http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.
75473

 

9040 is NOT hardcoded in Nominatim :

 

 http://www.openstreetmap.org/search?query=9040#map=17/51.04681/3.75473

 

9050 is :

 

http://www.openstreetmap.org/search?query=9050#map=17/51.04681/3.75473

 

So everything near the 9050 "node" will get the postal code 9050, regardless
of boundaries :

 

http://www.openstreetmap.org/search?query=tarbotstraat#map=17/51.04557/3.746
83

 

while Tarbotstraat is within the 9000 boundary, but close to the "9050
virtual node"

 

The only solution is to add the postal_code on street level.

 

___
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

2013-12-05 Thread André Pirard

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

On 2013-12-05 16:36, Kurt Roeckx wrote
  :


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


I wrote several times without reaction that the law states that the
law (e.g. the Moniteur) cannot be copyrighted, that the boundaries
are part of the law (normally in the Moniteur) and hence that the
boundaries cannot be copyrighted. The same applies to road signs.

Don't you agree?

Cheers,


  

  André.

  


  


___
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

2013-12-05 Thread 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

2013-12-05 Thread André Pirard

  
  
On 2013-12-05 03:43, Glenn Plas wrote :


  
  Exactly what I feared, that point in
Muizen has probably never been of any importance,  in that sense
the real historic centre of Muizen is the area at the new church
(and old tower) , about 1Km to the northwest of the current
coordinate used as centre.  Thats the reason I asked,  it is so
way off anything important (ever) and the location is
insignificant even now.  Muizen (was) a village that is divided
by de Dijle and de Leuvense Steenweg.  Mechelen is currently
consuming it at an evergrowing rate.
  

Oh, I see, that's another matter.
The problem with Dolembreux is that, according to OSM, the center of
Province Liège is 3 km away from it.
That must be an error ;-)
In a village nearby, they had two centers!
Seriously, the town center is a debatable matter. Some will say the
church, others the town hall, etc.
I prefer where activity takes place, where people love to go, where
to invite tourists.
Think of "You have arrived at your destination."
But all that relates to a place center and has nothing to do with
boundaries

Cheers,


  

  André.

  


  


___
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

2013-12-05 Thread Glenn Plas



http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.75473

9040 is NOT hardcoded in Nominatim :



Not sure what defines 'hardcoded in Nominatim' to you.  But since it 
uses OSM data.  I tried a little overpass search, and I sure find 
instances of that postal code.  See:


http://overpass-turbo.eu/s/1Ho


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

2013-12-05 Thread Marc Gemis
Nominatim also uses data that is not in OSM. They did some "imports" into
their database. That's why there was a postcode 12 in Reet last year. They
removed that one. So it is possible to have postal code nodes that are not
in OSM, and which cannot be deleted in the "normal" way of course.

as a side note, someone on the import mailing list proposed to import the
AGIV CRAB data in Nominatim and not in OSM. So even addresses can be in
Nominatim and not in OSM. They already did this for some US-addresses I
believe.

regards

m


On Thu, Dec 5, 2013 at 5:41 PM, Glenn Plas  wrote:

>
>
> http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.75473
>
>
>
> 9040 is NOT hardcoded in Nominatim :
>
>
> Not sure what defines 'hardcoded in Nominatim' to you.  But since it uses
> OSM data.  I tried a little overpass search, and I sure find instances of
> that postal code.  See:
>
> http://overpass-turbo.eu/s/1Ho
>
>
> 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


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

2013-12-05 Thread Marc Gemis
I think the boundary=postal_code makes a difference after all

compare

http://nominatim.openstreetmap.org/details.php?place_id=52527679(Waterkluiskaai)
which uses the postal code point
with
http://nominatim.openstreetmap.org/details.php?place_id=64725723(Bonheidensteenweg)
which uses the postal_code boundary, which is an extra
relation in this case. It does not extract the postal code from the admin
level 9 boundary.

 I'll admit that for another part of that street (
http://nominatim.openstreetmap.org/details.php?place_id=83522405) it still
uses the (wrong) postal code point from Bonheiden. Maybe something was not
updated ? Althought the dates do not reflect that

regards

m


On Thu, Dec 5, 2013 at 5:19 PM, Bart Van Lancker  wrote:

>
>
>
>
>  moved. Should there be a difference between the two ?
>
>  street(segments) within the Muizen area to return 2812 as post code. In
> Germany they use the dedicated boundary=postal_code. This is also what  recommended by someone on a similar question on help.openstreetmap.org.
>
> 
>
>
>
>
> 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.
>
> Examples :
>
>
>
> Waterkluiskaai in Sint-Amandsberg still has postal code 9050, although in
> reality it has 9040 :
>
>
>
>
> http://www.openstreetmap.org/search?query=waterkluiskaai#map=17/51.04681/3.75473
>
>
>
> Sint-Amandsberg has 9040, which is correct :
>
>
>
>
> http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.75473
>
>
>
> 9040 is NOT hardcoded in Nominatim :
>
>
>
>  http://www.openstreetmap.org/search?query=9040#map=17/51.04681/3.75473
>
>
>
> 9050 is :
>
>
>
> http://www.openstreetmap.org/search?query=9050#map=17/51.04681/3.75473
>
>
>
> So everything near the 9050 “node” will get the postal code 9050,
> regardless of boundaries :
>
>
>
>
> http://www.openstreetmap.org/search?query=tarbotstraat#map=17/51.04557/3.74683
>
>
>
> while Tarbotstraat is within the 9000 boundary, but close to the “9050
> virtual node”
>
>
>
> The only solution is to add the postal_code on street level…
>
>
>
> ___
> 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

2013-12-05 Thread Bart Van Lancker
Of course there are references to 9040. But this what I mean :

 

http://nominatim.openstreetmap.org/details.php?place_id=98380890

 

There is no such thing for 9040.

Problem is : you can't edit or remove this.

 

Van: Glenn Plas [mailto:gl...@byte-consult.be] 
Verzonden: donderdag 5 december 2013 17:41
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] My first attempt at a boundary

 





http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.
75473

 

9040 is NOT hardcoded in Nominatim :


Not sure what defines 'hardcoded in Nominatim' to you.  But since it uses
OSM data.  I tried a little overpass search, and I sure find instances of
that postal code.  See:

http://overpass-turbo.eu/s/1Ho


Glenn

___
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

2013-12-05 Thread André Pirard

  
  
On 2013-12-05 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. 
  

Yes, from an imprecise map I have, the boundary follows Boeimeerbeek
and it's most of the time the case when it looks like following
something, but you may have some sudden excursions.
What to do then, is draw the boundary very near to the road/river,
but not to use them as the boundary. If you do so, I can assure you
that, sooner or later, someone will want to change the road/river
and destroy your boundary.
Near enough so that the map show them at the same place, but far
enough to be able to select one at OSM.org zoom level.
Destruction has begun already ;-)  Some joker attached the boundary
to one end of the bridge. I'm used to that!

  

  
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.
  

Bridges are a long, strange, OSM story.
Bridges are pieces of concrete put under the road when there is no
ground.
Hence, OSM should draw an additional way segment under the road at
layer -1, that's all.
The road (tarmac foil) continues uninterrupted, without any routing
or naming concern.
But instead, OSM puts the bridge sort of ON TOP of the road AND
splits the road.
Then people wonder what is the name of the bridge and routing
programs wonder why the road changes.

OSM are very complicated people. A bridge normally has no name, the
street name continues as if there were no bridge.  In your case, in
the normal world, the street, and not the bridge, changes name
simply because it crosses a boundary.
But there are, of course, big bridges in big cities that stand on
their own and don't "inherit" a street name, whose road is called "Bridge
XXX" as well as bridges in smaller towns on which and beside which
the street is called "rue du Pont".

Cheers,


  

  André.

  


  


___
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

2013-12-05 Thread Marc Gemis
Bart,

I just added a postal_code boundary for 2840 Rumst. And  yes, both the
Hondstraat and Steenweg op Waarloos now get the correct postal code: 2840.
They had 2550 (from Kontich) before. So postal_code boundaries are the
solution for my nominatim problems.

regards

m


On Thu, Dec 5, 2013 at 5:19 PM, Bart Van Lancker  wrote:

>
>
>
>
>  moved. Should there be a difference between the two ?
>
>  street(segments) within the Muizen area to return 2812 as post code. In
> Germany they use the dedicated boundary=postal_code. This is also what  recommended by someone on a similar question on help.openstreetmap.org.
>
> 
>
>
>
>
> 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.
>
> Examples :
>
>
>
> Waterkluiskaai in Sint-Amandsberg still has postal code 9050, although in
> reality it has 9040 :
>
>
>
>
> http://www.openstreetmap.org/search?query=waterkluiskaai#map=17/51.04681/3.75473
>
>
>
> Sint-Amandsberg has 9040, which is correct :
>
>
>
>
> http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.75473
>
>
>
> 9040 is NOT hardcoded in Nominatim :
>
>
>
>  http://www.openstreetmap.org/search?query=9040#map=17/51.04681/3.75473
>
>
>
> 9050 is :
>
>
>
> http://www.openstreetmap.org/search?query=9050#map=17/51.04681/3.75473
>
>
>
> So everything near the 9050 “node” will get the postal code 9050,
> regardless of boundaries :
>
>
>
>
> http://www.openstreetmap.org/search?query=tarbotstraat#map=17/51.04557/3.74683
>
>
>
> while Tarbotstraat is within the 9000 boundary, but close to the “9050
> virtual node”
>
>
>
> The only solution is to add the postal_code on street level…
>
>
>
> ___
> 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

2013-12-05 Thread Marc Gemis
Did the same (duplicate the admin relation, change into a postal-code
relation) for Bornem and there it works as well. Sas & Nattenhaasdonkstraat
now show the correct 2880 postal code. It took several minutes though
before all street segments were updated.

Since in Belgium the postal code areas coincide with village borders, we
have to double them. This 1-to-1 mapping might not be the case in other
countries. When we use those postal code boundaries, we do not have to put
the postal code on streets or admin relations anymore. At least not for
applications that understand those boundaries.

regards

m


On Thu, Dec 5, 2013 at 9:25 PM, Marc Gemis  wrote:

> Bart,
>
> I just added a postal_code boundary for 2840 Rumst. And  yes, both the
> Hondstraat and Steenweg op Waarloos now get the correct postal code: 2840.
> They had 2550 (from Kontich) before. So postal_code boundaries are the
> solution for my nominatim problems.
>
> regards
>
> m
>
>
> On Thu, Dec 5, 2013 at 5:19 PM, Bart Van Lancker  wrote:
>
>>
>>
>>
>>
>> > moved. Should there be a difference between the two ?
>>
>> > street(segments) within the Muizen area to return 2812 as post code. In
>> Germany they use the dedicated boundary=postal_code. This is also what > recommended by someone on a similar question on help.openstreetmap.org.
>>
>> >
>>
>>
>>
>>
>> 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.
>>
>> Examples :
>>
>>
>>
>> Waterkluiskaai in Sint-Amandsberg still has postal code 9050, although in
>> reality it has 9040 :
>>
>>
>>
>>
>> http://www.openstreetmap.org/search?query=waterkluiskaai#map=17/51.04681/3.75473
>>
>>
>>
>> Sint-Amandsberg has 9040, which is correct :
>>
>>
>>
>>
>> http://www.openstreetmap.org/search?query=sint-amandsberg#map=17/51.04681/3.75473
>>
>>
>>
>> 9040 is NOT hardcoded in Nominatim :
>>
>>
>>
>>  http://www.openstreetmap.org/search?query=9040#map=17/51.04681/3.75473
>>
>>
>>
>> 9050 is :
>>
>>
>>
>> http://www.openstreetmap.org/search?query=9050#map=17/51.04681/3.75473
>>
>>
>>
>> So everything near the 9050 “node” will get the postal code 9050,
>> regardless of boundaries :
>>
>>
>>
>>
>> http://www.openstreetmap.org/search?query=tarbotstraat#map=17/51.04557/3.74683
>>
>>
>>
>> while Tarbotstraat is within the 9000 boundary, but close to the “9050
>> virtual node”
>>
>>
>>
>> The only solution is to add the postal_code on street level…
>>
>>
>>
>> ___
>> 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

2013-12-05 Thread 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

2013-12-05 Thread Bart Van Lancker
Okay, thanks. But there's one more problem.

 

Both the deelgemeenten Ledeberg and Gentbrugge have the postal code 9050.
The same counts for Afsnee and Sint-Denijs Westrem. So, should I draw a new
boundary over the administrative boundaries of both Ledeberg and Gentbrugge
and make this one a postal_code type boundary,

Or should I change both the boundaries of Ledeberg and Gentbrugge to a
postal_code type, and assign these both the same postal code ?

 

Van: Marc Gemis [mailto:marc.ge...@gmail.com] 
Verzonden: donderdag 5 december 2013 21:26
Aan: OpenStreetMap Belgium
Onderwerp: Re: [OSM-talk-be] My first attempt at a boundary

 

Bart,

 

I just added a postal_code boundary for 2840 Rumst. And  yes, both the
Hondstraat and Steenweg op Waarloos now get the correct postal code: 2840.
They had 2550 (from Kontich) before. So postal_code boundaries are the
solution for my nominatim problems.

 

regards

 

m

 

___
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

2013-12-05 Thread André Pirard

  
  
On Thu, Dec 5, 2013 at 9:25 PM, Marc
  Gemis  wrote:
  
Bart,


I just added a postal_code boundary for 2840 Rumst. And
   yes, both the Hondstraat and Steenweg op Waarloos now get the
  correct postal code: 2840. They had 2550 (from Kontich)
  before. So postal_code boundaries are the solution for my
  nominatim problems.


regards



  
  On 2013-12-05 22:52, Marc Gemis wrote :


  Did the same (duplicate the admin relation, change
into a postal-code relation) for Bornem and there it works as
well. Sas & Nattenhaasdonkstraat now show the correct 2880
postal code. It took several minutes though before all street
segments were updated.

  

Since in Belgium the postal code areas coincide with
  village borders, we have to double them. This 1-to-1 mapping
  might not be the case in other countries. When we use those
  postal code boundaries, we do not have to put the postal code
  on streets or admin relations anymore. At least not for
  applications that understand those boundaries.
  


I find bizarre to have to add such additional relations to villages
to get a correct postcode and to have to do it by guessing, without
a written specification explaining how to do. I'd say the proof that
it's not necessary is Dolembreux below and that if it doesn't work
in other cases the reason should be found rather than finding a
workaround and concluding that it's what has to be done.
Village Boundary Dolembreux,
  Sprimont, Liège, French Community, Wallonia, 4140, Belgium

This said, I returned to Минск (Minsk, a big city) where I once saw
things like that.

They of course
  use boundary relations, but with no subarea and a single name
on some ways (interesting to know that the borderline or Minsk is
called Minsk), they have
  address type relations that look a bit like the German
associatedStreet but they are different,  they also have
  postal_code relations but look at what they contain,  Автобусы г.
  Минска (buses of City Minsk) that seems done differently from
elsewhere and a strange route to me, etc.

I compare with Moscow where I see no address nor postal_code
relations, but a strange
  street relation, ..

No wonder that Nominatim does not work if everybody is doing it
their own way.

I think OSM is going crazy.  Is all that really necessary?  Why
don't we first try to have it work correctly as a routing (GPS)
database?  According to my tests, it is unreliable, and Guy even
added "they laugh at us".

Cheers,


  

  André.

  



  


___
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

2013-12-05 Thread Glenn Plas

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.

Rest assured, things like VRT and NATO own their own postal codes. I'm 
-almost- sure noone thinks they are a village ;-)


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.


Glenn

___
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

2013-12-05 Thread Marc Gemis
On Fri, Dec 6, 2013 at 12:58 AM, 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.
>>
>>  Rest assured, things like VRT and NATO own their own postal codes. I'm
> -almost- sure noone thinks they are a village ;-)
>
> 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.
>
>
So it really makes sense to add those boundaries

m.
___
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

2013-12-05 Thread Marc Gemis
André, your example is the postal code of the centre of a village. I'm
talking about streets, especially streets at the border of the postal code
area, close to the postal code node of the next village.

The Germans have those postal code area's. it's also mentioned on the
Nominatim FAQ page [1]. So it is documented. Of course feel free to keep
adding them to all individual address nodes or street segments.

Wouldn't they laugh at us when we display the wrong postal_code at a SatNav
? :-)

regards

m




[1] http://wiki.openstreetmap.org/wiki/Nominatim/FAQ#postal_codes


On Fri, Dec 6, 2013 at 12:57 AM, André Pirard wrote:

>  On Thu, Dec 5, 2013 at 9:25 PM, Marc Gemis  wrote:
>
> Bart,
>
>  I just added a postal_code boundary for 2840 Rumst. And  yes, both the
> Hondstraat and Steenweg op Waarloos now get the correct postal code: 2840.
> They had 2550 (from Kontich) before. So postal_code boundaries are the
> solution for my nominatim problems.
>
>  regards
>
>  On 2013-12-05 22:52, Marc Gemis wrote :
>
> Did the same (duplicate the admin relation, change into a postal-code
> relation) for Bornem and there it works as well. Sas & Nattenhaasdonkstraat
> now show the correct 2880 postal code. It took several minutes though
> before all street segments were updated.
>
>  Since in Belgium the postal code areas coincide with village borders, we
> have to double them. This 1-to-1 mapping might not be the case in other
> countries. When we use those postal code boundaries, we do not have to put
> the postal code on streets or admin relations anymore. At least not for
> applications that understand those boundaries.
>
>
> I find bizarre to have to add such additional relations to villages to get
> a correct postcode and to have to do it by guessing, without a written
> specification explaining how to do. I'd say the proof that it's not
> necessary is Dolembreux below and that if it doesn't work in other cases
> the reason should be found rather than finding a workaround and concluding
> that it's what has to be done.
> Village Boundary Dolembreux, Sprimont, Liège, French Community, Wallonia,
> 4140, Belgium 
>
> This said, I returned to Минск (Minsk, a big city) where I once saw things
> like that.
>
> They of course use boundary 
> relations,
> but with no subarea and a single name on some ways (interesting to know
> that the borderline or Minsk is called Minsk), they have address type
> relations  that look a bit
> like the German associatedStreet but they are different,  they also have
> postal_code relations  but
> look at what they contain,  Автобусы г. 
> Минска(buses of City Minsk) 
> that seems done differently from elsewhere and a
> strange route to me, etc.
>
> I compare with Moscow where I see no address nor postal_code relations,
> but a strange street relation,
> ..
>
> No wonder that Nominatim does not work if everybody is doing it their own
> way.
>
> I think OSM is going crazy.  Is all that really necessary?  Why don't we
> first try to have it work correctly as a routing (GPS) database?  According
> to my tests, it is unreliable, and Guy even added "they laugh at us".
>
> Cheers,
>
>   André.
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be


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

2013-12-05 Thread Marc Gemis
On Thu, Dec 5, 2013 at 11:15 PM, Bart Van Lancker  wrote:

> Okay, thanks. But there’s one more problem.
>
>
>
> Both the deelgemeenten Ledeberg and Gentbrugge have the postal code 9050.
> The same counts for Afsnee and Sint-Denijs Westrem. So, should I draw a new
> boundary over the administrative boundaries of both Ledeberg and Gentbrugge
> and make this one a postal_code type boundary,
>
> Or should I change both the boundaries of Ledeberg and Gentbrugge to a
> postal_code type, and assign these both the same postal code ?
>
>
>
>
>
I would create 1 relation postal_code boundary, using parts of the
administrative boundaries of Ledeberg and Gentbrugge. By "using parts", I
mean that the boundary line is placed in both relations (the adminstrative
and postal_code). No need to draw another boundary line.

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