Re: [OSM-talk-be] Dutch street names Mouscron

[Sander Deryckere]

Hi Maarten,

As with any OSM feature, the best source is the ground truth. I believe
language facility municipalities also put their facility language on the
streetname sign. So you should be able to gather that while surveying.

There are different ways to do surveys.

You could set up a mapillary <https://wiki.openstreetmap.org/wiki/Mapillary>
account, and walk or cycle around in Mouscron while taking pictures. That
may require a bit more setup, but it's easier in the long run.
You can also use an app like OsmTracker
<https://wiki.openstreetmap.org/wiki/OSMTracker_(Android)> to take geocoded
pictures, and later process them in your editor. This requires almost no
setup, and it's easy to go surveying if you have a little bit of time off.
Just remember to leave enough context in the picture. That way you know
where exactly the picture is taken (in case the GPS position isn't that
precise).
Or you can print out OSM on a paper, and note the streetnames next to it.
You can use something like fieldpapers <http://fieldpapers.org/> for that
purpose. Writing on paper is handier than writing on a mobile device. But I
usually prefer taking pictures.

Kind regards,
Sander Deryckere

Op za 31 okt. 2020 om 09:03 schreef rodeo .be :

> Hey all,
>
> Mouscron / Moeskroen is a municipality with language facilities.
> I am looking for the Dutch names of the streets and other locations. I
> would like to add them as name:nl.
>
> Google Maps has the correct names in Dutch, but I cannot use that source.
> Can anyone help me to find a usable source with the translations in Dutch?
>
> Kind Regards
> Maarten
> ___
> 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] waymarked or not?

[Sander Deryckere]

If the virtual routes are available under a strict copyright, there's
nothing we can map. And if they are available under a free copyright, we
add very little value by adding them to OSM.

So I believe they don't belong in the main OSM db, but rather in a side
project (a project made for routes, prrhaps something umap like?).

Op ma 19 okt. 2020 21:38 schreef Stijn Rombauts via Talk-be <
talk-be@openstreetmap.org>:

>
> Hi,
>
> That's also what I would expect: virtual is the future. Installing all
> those signposts and keeping them in order takes a lot of time and money. If
> the tourism agencies see that they can virtualize them away without losing
> tourists, they will. We will indeed lose relevance if we don't go along.
> By the way, if we stick to ground truth, we'll also have to remove most of
> the cycle highways because a lot of them haven't been waymarked yet and are
> still virtual. We just copied the information available on
> https://fietssnelwegen.be/ (and went even a lot further with those so
> called 'alternatives' which are still just somebody's fantasy in my
> opinion). So, in fact we already did decide that there is a place for
> virtual routes in OSM...
> But indeed: we will have to make a thorough choice in the official
> operators AND their choices.
>
> Some further comments on other reactions:
>
> No, it's not harder to keep the virtual routes up to date. It's even
> easier. You don't have to go out to check if there are still signposts or
> you don't have to buy a map or check if it's still for sale. If the route
> is available on the 'source-website', it exists, otherwise not. We only
> need to know which is the 'source-website', so we don't rely on a
> (outdated) copy. For routes like the Randonnées en Boucle which are only
> available in a book, it's as dubious as a map: is the book still in print
> or not?
>
> Adding virtual routes won't make it more 'messy' than it already is. Who
> checks regularly (every few years) whether the hiking/cycle/... routes in
> OSM haven't changed in the meantime or still exist? E.g. how long did it
> take before the outdated LF-routes got removed?
>
> To Pierre and company: adding waymarked routes to OSM by using only
> gpx-tracks (if that is what you're doing) is even worse than adding virtual
> routes, because you have no guarantee that those gpx-tracks correspond to
> the ground truth. I know from experience. Also maps which correspond to the
> ground truth are rare. (But go ahead, I don't mind what you're doing.)
> And indeed, we can't even keep up with the waymarked routes, but we could
> as well use that as an argument to give up mapping routes completely.
>
> "A route, right now, is something you can expect to see waymarked." I feel
> we'll have to let go of this. "If someone starts mapping virtual routes,
> they should definitely be put in their own data model." They're still
> local/regional/... hiking/cycle/... routes. Adding some tag like
> 'virtual=yes" on the route relations and nodes should suffice. (It will be
> a bit more complicated because a node can be both a virtual hiking node and
> a real cycle node.)
>
> Regards,
>
> StijnRR
>
> On Monday, October 19, 2020, 07:34:48 PM GMT+2, Steven Clays <
> steven.cl...@gmail.com> wrote:
>
>
> Tendency in Toerisme Vlaanderen > ALL hiking nodes will go virtual within
> 10 years or so. (At least, that is their vision) So if you do not follow
> this tendency, you make OSM irrelevant for routes. I'd make a thorough
> choice in the official operators AND their choices. Eg. Natuurpunt DOES
> stick to signposting AFAIK.
>
> Op ma 19 okt. 2020 om 14:47 schreef Matthieu Gaillet  >:
>
>
> Wether they are following another route is not relevant since it’s a
> separate relation.
>
> Matthieu Gaillet
>
> On 19 Oct 2020, at 14:33, Wouter Hamelinck 
> wrote:
>
> Are there any EV routes in Belgium that are not also LF or RV?
>
> Wouter
>
> On Mon, 19 Oct 2020, 12:29 Matthieu Gaillet,  wrote:
>
> Things are actually much less obvious and deserve a real second thought
> before taking position : it just came up to my mind that much of the
> Eurovelo network is still currently completely virtual (work in progress),
> yet deleting in from our map would be totally irrelevant since this routes
> are actually existing by the simple fact that thousands of users are using
> it.
>
> Matthieu Gaillet
>
> On 13 Oct 2020, at 19:21, joost schouppe  wrote:
>
> I think we shouldn't actively map purely virtual routes. But there's a lot
> of info that only lives on paper and still is relevant to OSM. So I find it
> hard to give it a hard no. What is essential though, is that we don't make
> a mess of the tagging. A route, right now, is something you can expect to
> see waymarked. If someone starts mapping virtual routes, they should
> definitely be put in their own data model.
>
> Op di 13 okt. 2020 om 13:27 schreef Matthieu Gaillet  >:
>
>
> That might be true but apply as well to signposted trails on the fled… I’m
> not 

Re: [Talk-transit] bus stop name

[Sander Deryckere]

Hi,

> editor does not show the route number

Since you specifically mention the editor, perhaps it's worth to check out
JOSM as an editor. iD is just a generic editor and fine for most tasks, but
JOSM can be extended with plugins and styles that make it easy to work on
specific features (like bus routes).

Kind regards,
Sander

Op vr 17 jul. 2020 11:40 schreef Mateusz Konieczny via Talk-transit <
talk-transit@openstreetmap.org>:

>
>
>
> Jul 17, 2020, 03:15 by talk-transit@openstreetmap.org:
>
> In the USA bus stops (flag stops) are located for the most part at
> named intersections, that is at where the street
>
> sign is.
>
>so you DO know where you are. but on the OSM standard map the bus stop
> tag depending on the
>
> editor does not show the route number, can you have the route number on
> the tag ?
>
> ​​​the wiki on this seems to be written for a European standard.
>
>
>
>
> You can change layer of map (cake / paper sheets button on the right)
> and select
> https://www.openstreetmap.org/#map=18/47.60203/-122.32333=T
> or
> https://www.openstreetmap.org/#map=18/47.60203/-122.32333=O
> both showing bus lines.
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [OSM-talk-be] administrative boundaries - municipalities - gemeenten - communes

[Sander Deryckere]

Hi Pierre,

I mapped a lot of boundaries in West-Flanders, using a tips from Marc
Deridder (user mdri on OSM) who sadly passed away just months after
finishing the Flemish borders.

Marc mapped most of the Flemish borders by using out-of-copyright Ferraris
maps. These could be aligned to the road network in OSM (remember, this was
before the availability of aerial imagery). This is also why the
part-municipalities were mapped before the municipalities: the Ferraris
maps show the old borders.

The borders have actually changed very little in that time. By carefully
defining reference points, and combining maps for both sides of the border,
we could usually get an accuracy of a few meters (good enough for
geocoding, which was the first aim).

Some borders did change in that time. I remember having issues with the
border between Rumbeke and Izegem. But most changes just aligned borders to
distinct features. In the case of Rumbeke and Izegem, the border was
aligned to the E403 motorway.

I hopo this clears up some of the mysteries.

Regards,
Sander

Op za 4 jul. 2020 17:33 schreef joost schouppe :

> Hi Pierre,
>
> When I had some questions about this, I looked deep into the history of
> the boundaries, and got a rather detailed answer from QuercE. But this was
> mostly about part-municipalities in Flanders, so I don't know if it's of
> much use to you.
>
> Op vr 3 jul. 2020 om 15:33 schreef Pierre Parmentier <
> pierrecparment...@gmail.com>:
>
>> Hello,
>>
>> Is anyone still in a position to give the references of the sources
>> available at the time of the introduction into OSM of the communal
>> boundaries in Belgium?
>>
>> Pierre P.
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Renderen van addr:flats

[Sander Deryckere]

You can do things with that data besides rendering or using it as a route
location.

If the data is more or less complete, you can process it to get the number
of addresses on a street or in an area (for example, if you want to
distribute a folder to the entire street).
Or as a postal service, you can check if that address needs a flat number,
and suggest a list of flats to the users.

Like that, I always considered the values worth to be in OSM, even if it's
all on the same door/building. Though it's obviously a lot less important
than housenumbers.

Op ma 15 jun. 2020 om 14:47 schreef Marc M. :

> if one building have 2 entrance, it's useful to describe with entrance
> need to be used to reach this flats number.
> but having all flats number on the building or on one-only entrance,
> is like "to reach the inside of the building, reach the building".
> it's a bit like adding entrance=yes on the building to say that a
> building has an entrance somewhere, you don't add any real information.
>
> so at this place, I would not have added any addr:flats which would have
> solved the problem of rendering :) I will only use it in the case of a
> building with more than one entrance, and so addr:flats on the entrance
> does not disturb the display of addr:housenumber for the whole building.
>
> Le 15.06.20 à 13:55, Lionel Giard a écrit :
> > The tagging is correct, it is just not supposed to be on area from the
> > wiki perspective. But indeed I don't see why it is incorrect when a
> > building is only containing this series of flats and only one entrance ?
> > And if that's incorrect why are they rendering addr:flats on area and
> > not node ?! ^^'
> >
> > Le lun. 15 juin 2020 à 13:32, joost schouppe  > <mailto:joost.schou...@gmail.com>> a écrit :
> >
> > Most of this data comes from the GRB import, I would guess. So it
> > comes from CRAB. We use the addr:flats to map the "subaddresses".
> > It seems a little weird to not be able to add the subaddresses on
> > the same object that has the main address.
> > The CRAB import tool mentioned this as an optional tag, that is not
> > so useful for OSM:
> >
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Optional_tags.2C_provided_by_the_tool
> > I would concur that the quality of the data is not good enough to
> > import it.
> > Both examples come from endless_autumn, who did a rather
> > quick-and-dirty GRB import - a lot of which was reverted.
> > The GRB-import-validator Midgard made actually flags the flats tag
> > as "consider removing" as well.
> > That said, the wiki doesn't say much about the logic of
> > "subaddresses", maybe we shouldn't use the addr:flats tag -at all-
> > for subaddresses?
> >
> >
> > Op ma 15 jun. 2020 om 09:22 schreef Sander Deryckere
> > mailto:sander...@gmail.com>>:
> >
> > Hmm,
> >
> > it seems indeed that, according to the wiki, this should not be
> > placed on areas.
> > However, I expect that in all these cases, all flats are
> > accessible behind the same door.
> > So correcting the tag will have the same effect.
> >
> > Op ma 15 jun. 2020 om 09:12 schreef Marc M.
> > mailto:marc_marc_...@hotmail.com>>:
> >
> > Hello,
> >
> > Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > > https://www.openstreetmap.org/#map=19/50.87528/4.69102
> >
> > https://www.openstreetmap.org/way/499694374
> > this look like a mistake :
> > wiki :  marking range of numbers of flats behind a door,
> > but the object isn't a door, it's a building
> >
> > maybe osm.carto should avoid to render tagging mistake and
> > target
> > only node and maybe only with entrance or door tag
> >
> > Regards,
> > Marc
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Renderen van addr:flats

[Sander Deryckere]

Hmm,

it seems indeed that, according to the wiki, this should not be placed on
areas.
However, I expect that in all these cases, all flats are accessible behind
the same door.
So correcting the tag will have the same effect.

Op ma 15 jun. 2020 om 09:12 schreef Marc M. :

> Hello,
>
> Le 15.06.20 à 08:23, Sander Deryckere a écrit :
> > https://www.openstreetmap.org/#map=19/50.87528/4.69102
>
> https://www.openstreetmap.org/way/499694374
> this look like a mistake :
> wiki :  marking range of numbers of flats behind a door,
> but the object isn't a door, it's a building
>
> maybe osm.carto should avoid to render tagging mistake and target
> only node and maybe only with entrance or door tag
>
> Regards,
> Marc
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Renderen van addr:flats

[Sander Deryckere]

Hi,

In December last year, the default map rendering started to display the
addr:flats tag.
In Belgium, this looks rather ugly as these tags can be very long.

In some cases, it even becomes hard to see the housenumbers.

See some examples:
https://www.openstreetmap.org/#map=19/50.87528/4.69102
https://www.openstreetmap.org/#map=19/51.04571/3.73000

I asked the OSM Carto project if they could revert that change, but they
say our tagging is an outlier and we should fix our tags.

To me, this sounds like tagging for the renderer, so I'm not very willing
to do that.

What are your opinions?

The issue can be found here:
https://github.com/gravitystorm/openstreetmap-carto/issues/4160

Kind regards,
Sander Deryckere
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] privacy ed

[Sander Deryckere]

Taking a picture is usually not illegal indeed. But sharing it in many
cases is. Next to the privacy regulations already mentioned, people can ask
to take pictures of their property offline on Google Streetview.

Google certainly has a good legal team, and blurring those pictures does
cost some money. So there must be a good reason why they comply to the
request (as opposed to blurring of areal imagery of military sites, which
they refused for many years).

And in Belgium, most buildings even have copyright on them: the architect
who designed the building had complete copyright, including on any pictures
taken from the roadside. A famous example of this is that spreading
pictures of the Atomium is forbidden without paying a license fee.

Luckily, most of these laws require the "victim" to request to take it
offline. Certainly if you make no money from it, it's very unlikely this
will have legal consequences. If there are legal consequences, they're even
more likely for the platform hosting the images instead of the uploader.

So if you just use common sense and blur faces and license plates,
everything should be ok.

Op vr 15 mei 2020 20:33 schreef Jo :

> Not only their faces, also license plates. And if you're doing it manually
> maybe also stickers with recognisable information.
>
> Jo
>
> On Fri, May 15, 2020, 19:38 Marc Gemis  wrote:
>
>> Hello,
>>
>> I see no difference between contributing to OpenStreetMap via JOSM and
>> iD or StreetComplete.
>> Mapping a house, street, waste bin, etc. will not break any privacy.
>> We do not map the names of the inhabitants of a house. Mapping items
>> from someone's garden based on aerial imagery might be on the
>> borderline of what is allowed. However, I do map sheds, ponds and
>> swimming pools.
>>
>> Taking pictures of people is not a problem, it's what you do with them
>> afterwards that is important. If you use the image yourself and map
>> the things you see on them from your PC, it doesn't matter that there
>> are people.
>> If you post the image on a public website (as you do via
>> StreetComplete), you have to make sure that there are no people or
>> that their faces are blurred (e.g. uploading to Mapillary is OK I
>> think).
>>
>> Of course, you cannot enter private grounds.
>>
>> On Thu, May 14, 2020 at 3:49 PM wbrt  wrote:
>> >
>> > Hello,
>> >
>> > a question about privacy of people in general (not the mapper) (in
>> Belgium)
>> >
>> > when contributing using for example streetcomplete:
>> https://github.com/westnordost/StreetComplete
>> > answering the questions, i suppose this is ok juridical?
>> >
>> > when taking pictures to make it clear for the mappers,
>> > i guess this also ok, as long as people are not recognizable in it?
>> >
>> > or am i wrong?
>> > and can you get in trouble for contributing to openstreetmap?
>> >
>> > The info i found:
>> >
>> https://wiki.openstreetmap.org/wiki/Limitations_on_mapping_private_information
>> >
>> > kr
>> > ___
>> > 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] Weggetje verdwenen, hoe terug ?

[Sander Deryckere]

Ik vond het eigenaardig dat ik de geschiedenis van de effectieve weg niet
terug vond. Daarom wat verder gezocht.

Via deze query de geschiedenis van het gebied opgevraagd (query moet even
zoeken)
http://overpass-turbo.eu/s/TS1

Op deze manier wel de correcte weg gevonden:
https://www.openstreetmap.org/way/24520955/history

Het blijkt dus door een andere wijziging te zijn dan ik eerst dacht.

Op di 12 mei 2020 om 10:57 schreef Wannes Soenen :

> Ok, dan lijkt me het het “handigste” dat ik een GPX neem en het pad terug
> teken (want het zit onder de bomen)
> Die relaties, en GR enz toevoegen/verleggen, zal ik eerst eens moeten
> bestuderen, want dat heb ik nog nooit gedaan.
>
> Op 12 mei 2020, om 10:53 heeft Sander Deryckere  het
> volgende geschreven:
>
> Hallo,
>
> Het hangt er van af hoe lang de wijziging geleden is.
> Als het vrij recent is (enkele dagen), kan je de geschiedenis van een
> gebied opvragen (de geschiedenis knop op de hoofdpagina).
> Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk te
> bespeuren.
>
> Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd
> zijn bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).
>
> 
>
> Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je
> hier terecht: https://www.openstreetmap.org/way/24520913/history
>
> Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In
> het bijzonder zie ik een wijziging van 4 maand geleden met het commentaar 
> "cycleroute
> 03-04 update: broken (again), now due to missing segments". Wat er op
> wijst dat iemand er voor die regio heeft aangepast, zonder rekening te
> houden met de relaties.
>
> Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft, maar
> iemand heeft dat pad verwijderd, en iemand anders heeft de relatie opnieuw
> verbonden met de bestaande paden...
>
> Mvg,
> Sander
>
> Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :
>
>> Hoi,
>>
>> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
>> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat
>> diegene die de edit gedaan heeft het weer wist.
>>
>> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2)
>> rollback doen
>>
>> Het betreft een pad net ten zuiden van het Ringfietspad op
>> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
>> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt
>> wel degelijk over dat pad, niet over het fietspad.
>> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer
>> gemapt 2) GR loopt over het fietspad.
>> ___
>> 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] Weggetje verdwenen, hoe terug ?

[Sander Deryckere]

Hallo,

Het hangt er van af hoe lang de wijziging geleden is.
Als het vrij recent is (enkele dagen), kan je de geschiedenis van een
gebied opvragen (de geschiedenis knop op de hoofdpagina).
Maar deze wijziging lijkt langer geleden te zijn, dus valt dit moeilijk te
bespeuren.

Wat je wel kan is bekijken welke objecten waarschijnlijk ook gewijzigd zijn
bij die aanpassing (zoals het fietspad dat nu gebruikt wordt).

[image: afbeelding.png]

Als je dat fietspad selecteert, en de geschiedenis opvraagt, dan kom je
hier terecht: https://www.openstreetmap.org/way/24520913/history

Er is dus in de laatste maanden tamelijk wat aangepast aan het pad.  In het
bijzonder zie ik een wijziging van 4 maand geleden met het commentaar
"cycleroute
03-04 update: broken (again), now due to missing segments". Wat er op wijst
dat iemand er voor die regio heeft aangepast, zonder rekening te houden met
de relaties.

Het is dus waarschijnlijk niet 1 iemand die de relatie verlegd heeft, maar
iemand heeft dat pad verwijderd, en iemand anders heeft de relatie opnieuw
verbonden met de bestaande paden...

Mvg,
Sander

Op di 12 mei 2020 om 10:18 schreef Wannes Soenen :

> Hoi,
>
> Ik zie dat er zeer lokaal, een wegje verdwenen is op de kaart.
> Ik kan dat er zelf terug op gaan zetten, maar dan is de kans groot dat
> diegene die de edit gedaan heeft het weer wist.
>
> Hoe kan ik 1) zien wie de edit deed, of er een comment bij was? 2)
> rollback doen
>
> Het betreft een pad net ten zuiden van het Ringfietspad op
> https://www.openstreetmap.org/edit#map=18/51.20462/4.44275
> De plaatselijke merkkringen van het GR-pad (en van op de GR site) loopt
> wel degelijk over dat pad, niet over het fietspad.
> Dus, de huidige gemaakte situatie is fout, want 1) pad is niet meer gemapt
> 2) GR loopt over het fietspad.
> ___
> 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] introducing OSM

[Sander Deryckere]

Marp lijkt sterk op LaTeX Beamer. Maar dan moderner, eenvoudiger om te
installeren en eenvoudiger om de syntax aan te leren.

Bij LaTeX kan je in ieder geval kiezen wanneer puntjes in een lijst
verschijnen, en dan maakt LaTeX gewoon extra PDF pagina's aan die een
pixel-perfecte overgang geven.

Momenteel lijkt marp nog wat jong voor mij, maar er zit zeker potentieel
in. Al mag je, net zoals bij LaTeX, niet verwachten dat iedereen het zal
gaan gebruiken.

Op 20-nov.-2016 19:36 schreef "Marc Gemis" :

> I have a few slides where I first show 1 picture, then click and a
> second becomes visible. How it becomes visible varies: slide in, fade
> in,  just appears, ...
>
> I do not always want to go to a completely new page.
> Same is true for bullet list. You do not always want to show all items at
> once.
>
> m.
>
> On Sun, Nov 20, 2016 at 5:33 PM, Ruben  wrote:
> > On 20 November 2016 17:21:32 CET, Marc Gemis 
> wrote:
> >>Can you do proper slide transitions with Marp ? Or with the PDF
> >>presenter ?
> >>I often overlay images (my slides have hardly any text)
> >>
> >>if not, I doubt I will make the switch.
> >
> > Do you mean having e.g. a slide with a picture, and a second one next to
> it on the next slide? I don't think so.
> >
> > Or do you mean sliding, wiping or fading transition animations and the
> like? No, not with pdfpc AFAIK. The PDF presenter "Impressive" can do that.
> Animations on a slide are not possible in any case. (And rarely desirable
> anyway IMHO)
> >
> > Or do you mean pixel perfect image matching between slides? If you
> create two slides with images of the same dimensions, those should align
> perfectly, yes.
> >
> > ___
> > 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] Rendering of stream "Leie" broken

[Sander Deryckere]

Just some notes on waterway=river vs natural=water+water=river.

For me, a riverbank is either a line (a wall) separating the land from the
river, or a sloped land area with water-loving plants that can be inundated
when the water level rises.

When you describe the water of the river, you describe the river, not the
riverbank. And a riverbank isn't a waterway either (you navigate the river,
not the bank). It even causes some problems, like when you want to measure
the total length of waterways in an area, you have to exclude this strange
case.

So I would prefer to just rename all waterway=riverbank tags to
natural=water+water=river. But sadly, the term riverbank has also been used
for canals and streams (which sounds totally bonkers to me), so such a
conversion isn't possible when done manually.

The page describing the water=* tags also says nothing about using multi
polygons. It's just as fine to use natural=water on river segments.

So in short, I don't get why there are people who want to keep that
awkwardly named tag .

Regards,
Sander
Op 29-jul.-2016 00:09 schreef "Ruben Maes" :

> Now back on topic: we have the Leie's banks back on the render.
>
> On donderdag 28 juli 2016 17:54 Jakka wrote:
> >
> https://www.openstreetmap.org/note/646584#map=17/50.82877/3.25798=N
> >
> > Please feedback what and where was the cause
>
> There were two places where there were problems with relation
> http://osm.org/relation/2393380:
>
> * http://osm.org/relation/2393380#map=17/50.89599/3.34545
>The sluice was a complete mess. It took me some time to figure out what
> was going on exactly here.
>
> * http://osm.org/changeset/41095237#map=19/50.92122/3.42972
>There was a random tiny, excess way in the relation.
>
> The waterway=riverbank tags were non-uniformly applied. Not all ways had
> them, some had an additional random area=yes or area=no. Some had
> natural=riverbank, waterway=canalbank or some other weird derivation I had
> never heard of.
> I stripped those completely. No more waterway=riverbank on this part of
> the Leie [note 1]. But if some day consensus is reached (not that that will
> ever happen) that the multipolygon approach with {natural=water,
> water=river} isn't good after all, it wouldn't be so hard to convert it.
>
> [note 1] Sorry Glenn, I really couldn't be bothered any more. With a
> relation, I can tell JOSM to fetch all member ways, use webtools like the
> one you mentioned to check their integrity, and the JOSM validator will
> complain if I'm messing up.
>
> --
> Dit bericht is ondertekend met OpenPGP.
> ___
> 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] Grootschalige luchtfoto's

[Sander Deryckere]

Ik zie in ieder geval nergens een addertje. Het is vrijgegeven onder de
open licentie die we al gebruiken voor onze andere luchtfoto's.

Het enige probleem is idd dat de foto's waarschijnlijk snel verouderd
zullen raken (als ze niet ieder jaar vernieuwd worden). Dus gaan we geen
"beste" foto's meer hebben. Tot nu toe kon ik eenvoudig de Agiv
middenschaal foto's als "beste" aanduiden in iD, aangezien die zowel de
scherpste, meest recente, en best gealigneerde foto's waren.

Ik denk dat het beter is om de middenschaal opnames in iD nog altijd als
"beste" te markeren, om nieuwe mappers niet te laten mappen op basis van
verouderde beelden. Maar de grootschalige foto's zouden best ook
beschikbaar gemaakt worden in iD.

Voor zover ik zie is er wel enkel een WMS link voor de grootschalige
foto's, terwijl iD TMS nodig heeft (wat ook werkt via WMTS). Maar in hun
lijst met WMTS zie ik nergens grootschalige foto's. Misschien iets voor
later ...?

Mvg,
Sander

Op 24 juli 2016 23:48 schreef Ruben Maes :

> On zondag 24 juli 2016 23:39 Jakka wrote:
> > Op 24/07/2016 om 14:59 schreef Ruben Maes:
> > > Dag iedereen
> > >
> > > Iedereen weet ondertussen wel dat Agiv recente orthofotomozaïeken
> heeft die we mogen gebruiken om te mappen, en die een veel betere resolutie
> en alignering hebben dan Bing.
> > >
> > > Hebben jullie ook al de grootschalige mozaïeken gezien? [1] Tussen
> 2013 en 2015 werden er gemaakt in het kader van het Digitaal Hoogtemodel
> Vlaanderen II, en deze werden gereleaset op 23 maart 2016 [2]. Voor zover
> ik kan zien, dekken ze heel Vlaanderen. Ze zijn wat minder up-to-date, maar
> de resolutie is fenomenaal (10cm resolutie, maximale afwijking 60cm,
> meestal minder dan 30cm). De licentie is de Vlaamse Open Data licentie v1.2
> [2] dus we mogen die beelden gebruiken om van te mappen. Natuurlijk moet je
> wel opletten dat wat je op de beelden ziet nog steeds zo is. Schuilt er
> hier een addertje onder het gras? Het lijkt bijna te mooi om waar te zijn.
> > >
> > > Groeten
> > > Ruben
> > >
> > > [1]
> http://www.geopunt.be/kaart?app=Geopunt-kaart_app=Luchtfoto%20Vlaanderen,%20winter%202013-2015%20-%20kleur
> > > [2]
> https://www.agiv.be/news/2016/maart/release-orthofotomozaiek-grootschalig-winteropnamen-kleur-2013-2015-vlaanderen
> >
> > Kunnen deze ook als extra layer in josm ingeladen worden zoja hoe en
> > waar welke url ?
>
> Dat kan inderdaad. Op de site van Agiv kan je de WMS-URL vinden. Die kan
> je vervolgens copy-pasten in de JOSM-instellingen (Imagery → Imagery
> preferences → rechtsonder het plusteken met "WMS" bij geschreven).
>
> Ik heb met opzet de URL hier nog niet gepost, zodat mensen niet zonder
> nadenken zouden beginnen mappen. Als er nog antwoorden op mijn bericht
> worden gepost (bv. als iemand een addertje onder het gras vindt), is de
> kans nu groter dat die gelezen zullen worden. (Als je begrijpt wat ik
> bedoel.)
>
> --
> Dit bericht is ondertekend met OpenPGP.
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] rendering

[Sander Deryckere]

Best even kijken op http://wiki.openstreetmap.org/wiki/OSM_on_Paper , ik
zelf vind https://www.mapz.com/ wel goed, al is het niet gratis voor alle
doeleinden.

Als je tevreden bent met een screenshot, dan is umap ook heel goed.

Mvg,
Sander
Op 18-jul.-2016 20:11 schreef "Bart Vanherck" :

> Beste mappers,
>
> Weet iemand in de groep hier of er ergens een service of een programma
> bestaat waarmee ik een gpx trace op een openstreetmap layer kan plaatsen.
> Het doel is om een redelijk gedetailleerde kaart te hebben om af te printen.
>
> Ik ga namelijk de dodentocht doen, en mijn volgers zouden graag weten hoe
> de wandeling loopt. En internet access is niet mogelijk, vandaar de
> noodzaak om alles af te printen op papier.
>
> alvast bedankt,
>
> Bart
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] wegenregister now open data

[Sander Deryckere]

2016-07-01 18:53 GMT+02:00 joost schouppe :

> ...
> It should be clear that any competition between Wegenregister and OSM is a
> bit absurd.
>
...
>

In contrary, the OSM community has been formed because it was so hard to
access free geographical data. The fact that governments are now opening up
data means that we are doing very well in our quest. Thanks to the work of
every single contributor.

That said, do watch out when comparing both datasets. One of the first
differences I found shows a track in the wegenregister that definately
doesn't exist:
https://api.mapbox.com/styles/v1/joostschouppe/...#17.72/50.94482/3.07103

I have seen that track/path drawn on other topographical maps, and
explicitly searched for it, but there's nothing to be found there  apart
from a ditch (which certainly isn't suited for walking in). If there's a
place to report those things, please tell me.

There are also some obvious places where the wegenregister is a bit
outdated. If there's a place to report these things, please tell me ;)

But all in all, it's a great data source to have available (when everyone
is a bit sensible on comparing the data). So thanks for everyone who helped
making this available.

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

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

[Sander Deryckere]

Die beslissing werd genomen om uniforme data in OSM te krijgen, zo dat alle
bisnummers op dezelfde manier genoteerd worden.

Het is vergelijkbaar met een aantal straatnamen die met hoofdletters in
CRAB zitten (i.p.v. enkel de eerste letter een hoofdletter).

zie de code:
https://github.com/aptum/aptum.github.io/blob/master/loadStreets.js#L436

Op 20 juni 2016 17:17 schreef Sus Verhoeven <sus...@gmail.com>:

> Hooi Sander,
>
> Met een "/" in plaats van een  "_" zijn er geen missings meer, maar dat is
> toch niet helemaal juist. Ik ga de anderen met een "_" maar laten.
>
> Toch bedankt en groetjes.
>
> Sus
>
>
>
>
> 2016-06-20 15:24 GMT+02:00 Sander Deryckere <sander...@gmail.com>:
>
>> Met de import hebben we geprobeerd om het formaat uniform te houden. Een
>> ik denk dat enkel nummers als 10/4 aanvaard worden, en niet 10_4.
>>
>> Kan je eens met dat formaat proberen? Mogelijk werkt dit ook nog niet
>> meteen, en moet er nog iets aangepast worden aan de code.
>>
>> Mvg,
>> Sander
>> Op 20-jun.-2016 14:24 schreef "Sus Verhoeven" <sus...@gmail.com>:
>>
>>> Dag Sander,
>>>
>>> In Balen 2490 zijn er missings omdat men daar bis-numbers gebruikt in de
>>> vorm van Nr_1, Nr_2, Nr_3, enz.. in plaats van NrA, NrB, NrC enz..
>>> CRAB en OSM slikken die alsook de zoekfunctie van OSM.
>>>  Zie:
>>> http://www.openstreetmap.org/way/139379759#map=19/51.15796/5.16556
>>> In de Hoolsterberg alleen zijn er  een tiental.
>>> Is daar iets aan te doen ?
>>>
>>> Sus
>>>
>>> ___
>>> 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] municipal boundaries in Belgium

[Sander Deryckere]

Note that the GRB data mentions it's "voorlopig", and often, the data shows
an offset from parcel boundaries. At those places, I would expect the
boundaries to follow parcel boundaries (and I expect parcel boundaries to
be of better quality).

2016-06-01 19:01 GMT+02:00 joost schouppe :

> very true... 100 meters would be vast imho. A difference of 5 meters I
>> would think that is pretty much ok, although the importance of that can
>> be big when borders cross buildings.
>>
>> Exactly, I think the definition of correct is pretty narrow here.
>
>
>> More important: remember that those boundaries usually align on each
>> other, so when you make a admin level 8 smaller, you -probably- also
>> need to modify all others as well. e.g.  If you make north border of
>> Antwerp smaller, you probably need to make Belgium smaller too, AND the
>> province etc.  probably even from level 1 down to 9 if you want to do
>> this well.  At the least we will need to verify them to make sure.
>>
>> Yes, this is something to keep in mind. As long as you don't go splitting
> ways in the wrong place, that shouldn't be a problem though, right? If they
> are properly mapped, boundaries like that should reuse the same segments
> over and over again, so correct one and you correct all the others. E.g.
> http://www.openstreetmap.org/way/87806314
>
>
>
>> GRB data actually has border information if I remember correctly.  some
>> of their map layers (tiles) show the level 8 boundary (a very fine line
>> though, almost invisible).
>>
>> I think this is the one:
> https://download.agiv.be/Producten/Detail?id=1217=Voorlopig_referentiebestand_gemeentegrenzen_toestand_29_01_2016
>
>
>
> ___
> 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] municipal boundaries in Belgium

[Sander Deryckere]

Heel wat van de grenzen zijn gemapt door Marc De Ridder (die jammer genoeg
te vroeg van ons heengegaan is:
https://lists.openstreetmap.org/pipermail/talk-be/2013-January/003565.html
).

Zelf heb ik ook de grenzen leren mappen van Marc, en heb ik een groot deel
van de West-Vlaamse grenzen gemapt. De techniek was om out-of-copyright
kaarten te nemen (bijvoorbeeld Popp kaarten), die te aligneren met
weglayouts (want luchtfoto's waren nog niet beschikbaar), om zo ongeveer
correcte grenzen te bekomen.

Het belangrijkste bij die grenzen was om geocoding mogelijk te maken, en
voor het grootste deel van de straten de correcte gemeente te kunnen geven.

Er zitten natuurlijk fouten in (zoals offsets doordat we die kaarten niet
precies genoeg konden aligneren), maar het is niet zo moeilijk om die met
de huidige data te corrigeren (het moeilijkste is de fouten vinden).

Mvg,
Sander

2016-06-01 13:57 GMT+02:00 Killian De Volder :

> Personally for Flanders I wouldn't worry to much. Lets wait maybe a a year
> or 2 to get the municipals time to correct/update their borders in AGIV
> (GRB).
> But form the things I compared, I found the current borders to be are
> rather good.
>
> I'm going to assume they are rather old too. As such they have probably
> been created using: maps obtained from various sources, signposts, ...
>
> Some-one else might be able to shed more light on this.
>
> On 01-06-16 12:36, joost schouppe wrote:
> > Hi,
> >
> > I got a question about municipal boundaries in Belgium. I had a look
> here [1], but it seems to be lacking detailed information about how this
> data was added to OSM and what the source is. I do remember seeing some
> info about this, but we should probably have a bit more formal
> documentation, right? Or am I missing the right place to look for the info?
> >
> > 1: http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Boundaries
> > --
> > joost schouppe
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] mapping farm-shop

[Sander Deryckere]

I don't think that selling the products is very important.

Farm shops typically don't have a very stable range of products, but it all
depends on the time of the year (certainly for vegetables). So even if you
map what's in the shop now, it could be rather different in 3 months.

If it's more focused on selling, and will import products from other places
to avoid running out if it, it should probably be tagged as
shop=greengrocer, or shop=dairy.

Instead, it may be better to put in some link to the farm shop's website
(if there's any), and let the owners update the page.

Regards,
Sander


2016-04-21 13:01 GMT+02:00 joost schouppe :

> There might be good reason not to do this, I don't know.
>
> There is a recent proposal to tag products: sold:
> http://wiki.openstreetmap.org/wiki/Proposed_features/Sells
> Have a look at the discussion on the tagging mailing list on the subject:
>
> https://lists.openstreetmap.org/pipermail/tagging/2016-March/thread.html#28782
>
> It looks controversial.
>
>
> ___
> 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] Fietsknooppunten West-Vlaanderen Cyclisme Flandre occidentale

[Sander Deryckere]

De onderverdeling van de netwerken is ook volledig vernieuwd. Zo zijn er nu
maar 4 netwerken meer:

   - Brugs Ommeland
   - Kust
   - Leiestreek
   - Westhoek

En per netwerk is iedere route uniek beschrijfbaar door een paar van
knooppunten te geven (de route 15-20 kan dus maar 1 keer voorkomen, maar er
kunnen meerdere knooppunten met referentie 10 en 20 zijn).

Ik denk dat we best die master-relaties gewoon verwijderen.

Ondertussen heb ik de kaart van de Westhoek, en ik zal eens onderzoeken tot
hoever ik die mag gebruiken (b.v. een POI lijst met verschillen aanmaken,
en dan naar die punten gaan om ze te noteren).

Mvg,
Sander

Op 20 april 2016 10:39 schreef Jakka :

> Na updaten van een knooppunten route (zoals reeds eerder vermeld
> West-Vlaanderen volledig herwerkt door provincie vele nieuwe nummeringen)
> staan deze niet in een groepsrelatie
> Nu staan deze eigenlijk beetje op hun eigen... wezen?
>
> Waar komt de naam vandaan om de fietsknooppunten in zo'n relatie of is dat
> een superrelatie te plaatsen? Enkel voor de Leiestreek waren er, zijn, zie
> ik er 5 .
>
> http://osma.vmarc.be/nl/networks/be/rcn
> -Fietsroutenetwerk B Leiestreek Noordoost
> -Leiestreek Noordwest
> -Leiestreek West
> -Leiestreek Zuidwest
> -Leiestreek
>
> Moeten deze behouden blijven om het werkbaar te maken, waar is dan de
> grens tussen die netwerken ?
>
> Maar..
>
> Prov West-Vlaanderen vermeld er maar 4 voor gans de provincie
>
> https://shop.westtoer.be/nl/producten/kaarten-brochures?f[0]=field_recreation_type%3A16[1]=field_recreation_form%3A17
>
> Thx
>
>
>
> Op 15/12/2015 om 16:15 schreef Jakka:
>
> Fietsknooppunten West-Vlaanderen wordt volledig herzien en op veel
>> plaatsen bijgewerkt, verlegt, nieuwe verbindingen toegevoegd.
>> ...275 kilometer langer en er komen 392 knooppunten bij.
>> Hoe weten de gebruikers OSM, en afgeleide app dat de huidige bestaande
>> relaties nog niet aangepast, herzien werden.
>> Kan iemand al deze relaties globaal in één keer voorzien van een merk
>> tag welk? Een datum van de start herziening met een verklarende tekst?
>> Wie de vernieuwde route nagezien heeft, welke tag voorzien ? Gewoon
>> schrappen vorige tag geen goed idee???
>> Is er kans dat Toerisme West-Vlaanderen toelaat van hun data te delen om
>> sneller een update te hebben?
>>
>> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk
>>
>> translate plugin S3
>>
>> Fietsknooppunten West Flanders is fully revised and updated in many
>> places, shifts, new connections added.
>> ...275 kilometers longer and there and adding 392 nodes.
>> How do the users with existing app know that the current existing
>> relationships (Fietsknooppunten) have not changed, revised in OSM and app
>> Can someone provide all these relationships globally at one time from a
>> tag ? A date with the review starts date with an explanatory text?
>>
>> Who inspected the new route which tag to add? To show the difference
>> Is there a chance that Tourism West Flanders allows sharing of their
>> data in order to have an update faster?
>>
>> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk
>>
>> traduction plugin S3
>>
>> Fietsknooppunten Flandre Occidentale est entièrement révisé et mis à
>> jour dans de nombreux endroits, les changements, les nouvelles
>> connexions ajoutées.
>> ... 275 kilomètres de plus et l'ajout de 392 node (knooppunten).
>>
>> Comment les utilisateurs avec l'application existante savent que les
>> relations existantes actuelles (Fietsknooppunten) n'a pas changé, révisé
>> dans OSM et application.
>>
>> Quelqu'un peut fournir tous ces relations en une fois d'une tag? Une
>> date de commencement des changement avec un texte explicatif?
>>
>> Qui a inspecté une nouvelle route comment indiqué? Pour montrer la
>> différence.
>>
>> Y at-il une chance que l'office Tourisme Flandre occidentale permet le
>> partage de leurs données afin d'avoir une mise à jour plus rapide?
>>
>>
>> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk
>>
>>
>> ___
>> 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] MissingMaps National

[Sander Deryckere]

Joost,

Would you like to contact Belga in our name and explain that Google doesn't
allow us to use their images?

Regards,
Sander

2016-04-17 19:34 GMT+02:00 Ruben Maes <ru...@janmaes.com>:

> Sunday 17 April 2016 19:20:46, Sander Deryckere:
> > Metro also uses Belga as source, and also mentions Google Earth, though
> > this article does mention OSM too.
> >
> >
> http://nl.metrotime.be/2016/04/16/news/ruim-200-vrijwilligers-brengen-eiland-in-kivu-meer-in-kaart/
>
> The article in Metro is verbatim the press release of Belga. (I have
> access to their archives through the university.)
>
> --
> This message is OpenPGP signed.
>
> ___
> 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] MissingMaps National

[Sander Deryckere]

Metro also uses Belga as source, and also mentions Google Earth, though
this article does mention OSM too.

http://nl.metrotime.be/2016/04/16/news/ruim-200-vrijwilligers-brengen-eiland-in-kivu-meer-in-kaart/

So it looks like De Zondag abbreviated the message from Belga a bit, and
left out the lesser known name "OSM", in favour of keeping the name Google
Earth.

2016-04-17 18:48 GMT+02:00 Jo :

> Apparently this seems to be an important point to remember when talking to
> the press. Could we write a short general press communiqué stressing these
> important points? No relation whatsoever with anything Google (even
> stressing we can't use their imagery or streetview for the creation of our
> data) seems to be the most important issue.
>
> Apparently journalists seem to think immediately of Google Maps when they
> hear the term Missing Maps.
>
> Jo
>
> 2016-04-17 18:16 GMT+02:00 Marc Gemis :
>
>> De Belga text also mentions Google Earth, the universities and Missing
>> Maps. No OpenStreetMap. (see article in De Zondag)
>>
>> On Sun, Apr 17, 2016 at 6:09 PM, Ruben Maes  wrote:
>> > Sunday 17 April 2016 18:05:29, Jo:
>> >> Ruben, we're creating a press release:
>> >>
>> >> https://hackpad.com/Press-release-E4GFhbj0rKg#
>> >>
>> >> In the Dutch version I included a way for people who missed the event
>> to
>> >> get involved from home by pointing them to a fresh Swaziland project.
>> If we
>> >> decide to include this, it still needs to be translated back to the
>> French
>> >> version.
>> >>
>> >> Do you think this is a good idea? You can write a mail to VTM, but they
>> >> can't unbroadcast that footage. So maybe we should focus on getting the
>> >> information out correctly where it still is possible. On the one hand
>> it's
>> >> great that we got ad hoc coverage, but there are disadvantages to
>> >> everything.
>> >>
>> >> Jo
>> >
>> > That's better, I'll just keep quiet. They're just trying to do their
>> job. I got a bit too mad when I saw the footage.
>> >
>> > Ruben
>> >
>> >> 2016-04-17 17:56 GMT+02:00 Ruben Maes :
>> >>
>> >> > Sunday 17 April 2016 17:47:06, Marc Gemis:
>> >> > > I wished they had labeled me as "OpenStreetMap Vrijwilliger" ipv
>> enkel
>> >> > > "Vrijwilliger". :-/
>> >> >
>> >> > :(
>> >> >
>> >> > > On Sun, Apr 17, 2016 at 5:42 PM, Ruben Maes 
>> wrote:
>> >> > > > Wow, even on the 1PM "Journaal":
>> >> >
>> http://deredactie.be/cm/vrtnieuws/videozone/programmas/journaal/2.43814?video=1.2630443
>> >> > > >
>> >> > > > Technically, they violated OSM's copyright. They showed our maps
>> and
>> >> > didn't say OpenStreetMap once. I was actually hoping to hear Wim De
>> Vilder
>> >> > say "OpenStreetMap" :p
>> >> >
>> >> > VTM went further: they mentioned neither OpenStreetMap nor "missing
>> maps",
>> >> > and showed the tasking manager on Google Earth with attribution
>> (which
>> >> > oddly makes me pretty mad). People don't have a clue that they can
>> help at
>> >> > home.
>> >> >
>> >> > I'm going to contact them.
>> > --
>> > This message is OpenPGP signed.
>> >
>> > ___
>> > 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] Name of "domeinbos"

[Sander Deryckere]

Some very generic tag you can use (and I've used before for provincial
domains) is the boundary=protected_area:
http://wiki.openstreetmap.org/wiki/Tag:boundary%3Dprotected_area

I don't know what sub-tags fit for our provincial domains, but at least it
allows you to map the complete area.

I have nothing against also adding the name to the forest part though. As I
believe not many tools parse that boundary=protected_area tag (since it's
quite generic and can be used for a lot of different features).

Regards,
Sander

Op 7 april 2016 13:41 schreef Gerard Vanderveken :

> Het probleem is ook wel dat het meestal natuurgebieden zijn, waar in de
> loop van de jaren ook altijd nog wel percelen worden bijgekocht. Soms
> liggen er ook nog prive-percelen in het gebied.
> Maar het belangrijkste is toch wel dat het gemapt wordt en er een naam
> voor bestaat in OSM, ook al is de juiste omvang niet bekend of korrekt.
>
> Meestal zijn er wel kaartjes van de exacte percelen te vinden in studies
> die bvb het INBO doet of bij de vereniging die het gebied beheert, zoals
> Natuurpunt enz.
>
> Groeten,
> Gerard.
>
>
> Marc Gemis wrote:
>
> Het probleem is misschien nog wat algemener. Soms zijn die welkom
> borden voor een "gebied": bos, heide, velden, ...
> De kaartjes op die borden zijn niet altijd even duidelijk of komen
> niet overeen met de stukjes landuse in OSM.
> Ik wil me er dan gemakkelijk vanaf maken en ergens een node plaatsen
> die zegt hier ligt het gebied genaamd X.
> omdat het dan niet altijd over bos gaat, dacht ik aan place.
>
> Ik heb vast en zeker ergens een foto van zo'n bord waar het niet
> duidelijk is over welke "percelen" het gaat.
>
>
> 2016-04-07 13:15 GMT+02:00 Karel Adams  
> :
>
>
> Is dat niet een bijzonder letterlijke vertaling van het Franse "foret
> domaniale"? Als ik het goed begrijp duidt dat op een bos dat door de
> overheid wordt beheerd, of eigendom is van de overheid. Misschien eens
> vragen aan de overheid die deze naam heeft toegekend, wat er precies met de
> term bedoeld wordt?
>
> Qua tagging (waar ik niet veel benul van heb...) lijkt "landuse=forest"
> correct, met "place=" zie ik niet veel verband.
>
> Karel
>
>
> On 07-04-16 10:57, Marc Gemis wrote:
>
>
> How do you map the name of a "domeinbos" ? I know you can use the name
> tag, but typically the name applies to a different area than what is
> tagged as forest.
>
> two examples: [1] & [2]
>
> Would it be OK to add a node with landuse=forest ? Or a place=locality ?
>
>
>
>
> [1] https://xian.smugmug.com/OSM/OSM-2016/2016-03-19-Ham/i-t3W5gGT/A
> [2] https://xian.smugmug.com/OSM/OSM-2016/2016-03-19-Ham/i-TLz34gH/A
>
> m
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://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] Fwd: Toll for trucks +3,5ton

[Sander Deryckere]

As a general rule, you should map what's on the ground, and you shouldn't
map your local legislation:
http://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_your_local_legislation.2C_if_not_bound_to_objects_in_reality

I know how tempting it is to add this to all roads, so tools support it,
but legislation can change too easily.

So at most, we can tag the type of road for this case (if it's signed on
the road).

2016-03-16 19:24 GMT+01:00 Jasper Michels :

>
> Hi all,
>
> Starting from 1/04/2016 trucks will have to pay toll on the Belgian roads.
> http://www.viapass.be/en/about-viapass/viapass-for-hgvs/
>
> The amount of toll depends from these factors:
> -Type of street
> -Euro-class Engine
> -Weight
> -Kilometres travelled (GPS driven)
>
> Is there a possibility to map this? And how?
> How to make the difference of euro classes, and weight?
>
> Could be very handy for apps like Osmand with their truck navigation.
> Doesn't seem a lot of work also.
>
>
>
>
> Dit e-mailbericht is verzonden vanaf een virusvrije computer die wordt
> beschermd door Avast.
> www.avast.com
> 
> <#1010004827960638429_DDB4FAA8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> ___
> 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] background imagry in Potlatch2

[Sander Deryckere]

The imagery index for iD is handled in this github repo:
https://github.com/osmlab/editor-layer-index

And some time ago, I indeed added the AGIV orthophoto source:
https://github.com/osmlab/editor-layer-index/blob/gh-pages/sources/europe/BE_OrthoPhoto_Flanders_TMS.json

It looks like iD changed its background listing layout now. Agiv imagery
isn't displayed under the imagery anymore, but with some other resources. I
guess this is because some of the imagery in that list may be partially
transparent (like the GPX renderings), so it can be overlayed with photos.
But the AGIV imagery clearly doesn't belong in that list, but in the top
list.

I'll ask around on IRC.

Regards,
Sander


2016-03-09 9:04 GMT+01:00 joost schouppe :

> Some time ago, the list of background images became a whole lot shorter in
> Potlatch. But someone added the AGIV aerial photography during that
> operation. Now they seem to have switched back to the longer list, but
> without AGIV.
>
> Anyone know what's up, who to ask?
>
> --
> Joost @
> Openstreetmap  |
> Twitter  | LinkedIn
>  | Meetup
>  | Reddit
>  | Wordpress
> 
>
> ___
> 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] Still 296 phone booths in Belgium

[Sander Deryckere]

It's better to do it manually. It wouldn't surprise me if some emergency
phones are tagged (wrongly) with this tag. So a manual correction could
find these.

Meanwhile, it doesn't bother me too buch that these are still present.
Everyone in Belgium knows that there are no more public phones, so nobody
will search for these.

It does however show a bigger problem: it's very difficult to notice that
something is removed in real-life, and adapt OSM to reflect the reality.
Now we know these phones are removed. But the same would hold for all other
types of POI.

Regards,
SAnder

2016-02-23 17:28 GMT+01:00 Marc Gemis :

> Last year, M!dgard got some complaints on his blog entry when he
> proposed such a mechanical edit.
>
>
> regards
>
> m
>
> On Tue, Feb 23, 2016 at 10:49 AM, Jakka  wrote:
> > May all the public telephone cells in Belgium be cleaned up even if
> there is
> > no oparator tag proximus or belgacom ?
> >
> > I seem to remember that a other operator (English ???) try to place
> public
> > phone in railway stations and other public places, but do not find info
> on
> > the internet about this.
> > Am I wrong ?
> >
> >
> > Marc Gemis schreef op 23/02/2016 om 7:29:
> >>
> >> Seems like we didn't manage the clean up of public telephone cells in
> >> Belgium.
> >> There are still 296 telephones left.
> >>
> >>
> >> Het lijkt erop dat we er nog niet in geslaagd zijn om de
> >> telefooncellen in België te verwijderen.
> >> Er zijn er nog 296 gemapped.
> >>
> >> [out:xml]
> >> [timeout:600];
> >> {{geocodeArea:Belgium}}->.searchArea;
> >> (
> >>node[amenity=telephone](area.searchArea);
> >> );
> >> out meta;
> >>>
> >>> ;
> >>
> >> out meta qt;
> >>
> >>
> >> m
> >>
> >> ___
> >> Talk-be mailing list
> >> Talk-be@openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/talk-be
> >>
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] SOTM 2016 social events ?

[Sander Deryckere]

Brouwerijen zijn wel een goed idee, typisch Belgisch.

De Rodenbach brouwerij in Roeselare kan feesten aan tot 750 man. Dat is dan
tussen de foeders, maar zonder rondleiding. Misschien zijn er ook
dergelijke brouwerijen in Brussel.

Een ander idee is misschien het Europees parlement. Da's wel uniek voor
Brussel, en volgens mij ideaal voor een internationaal publiek. Standaard
voorzien ze groepen tot 45 personen, maar grotere groepen kunnen ook op
aanvraag.

http://www.europarl.europa.eu/visiting/nl/visits/chamber-tour-for-groups.html
Op 9-feb.-2016 19:57 schreef "Philippe Casteleyn" <
philippecastel...@hotmail.com>:

> http://www.atomium.be/rent.aspx
> 1 bol is echter te klein.
>
> Brouwerijbezoek
> http://www.cantillon.be/br/2_2
>
> http://www.beercapital.be/index.php?mact=Products,cntnt01,details,0=brouwerij_20min=bbcw_lijst_cat=breweries-detail_origpage=323=30=339
> 600 man in een brouwerij lijkt ook niet gemakkelijk
>
> Terroristen-Wandeling in Molenbeek.
>
> Heeft al iemand de toeristische dienst gecontacteerd ?  Die kunnen
> natuurlijk niets origineels voorstellen.
>
> Het SOTM reglement van inwendige orde is er alvast al.
> Misschien het gillen nog verbieden.  Dat is tegenwoordig een probleem bij
> Amerikaanse vrouwen.
>
>
> Ctrl+v
>
> ___
> 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] Agiv import

[Sander Deryckere]

2016-01-25 15:37 GMT+01:00 Glenn Plas :

> On 25-01-16 14:06, Marc Gemis wrote:
> > * We pass this somehow through the import mailing list ( I fear we
> > cannot avoid this). Sander, you have some experience with this. What
> > do you think ?
>
> This needs to pass indeed, but let's not call it an import from now on.
>  I prefer a "semi-automated, human reviewed, merge operation" :)
> It is a bit like the news calling it a "tactical bombardment" when
> blowing up bombs, the first almost sounds like there aren't any
> casualties at all.
>
> I'm confident we'll get through it even when calling it an import. The
data quality is good, we're with a limited set of active mappers (who
worked on OSM long before trying an import), and we care about our region.

The only thing I'd have to defend is the usage of the GRB. They'd need some
guarantee that the key is valid (won't change without a reason, and won't
be reused on another building). I guess the AGIV gives some guarantee for
it in their documentation, but we should make the clear.


> > * We have a face-to-face meeting / hangout to explain the procedure to
> > interested people.  Face-to-face is better I think, but might not be
> > feasible for everyone. Perhaps a combination ?
>
> I believe face-2-face is better, and I'm willing to spend time on this,
> there are many questions you will have and the interactive approach will
> be easier to answer/demonstrate instead of describing it.
>

Face-2-face sounds good.

>
> > * We start "the import". Somehow we need an overview for this to see
> > who is working on a certain town. (a shared document/spreadsheet)
>
> I don't think you really need that in order to be able to work (it
> wouldn't hurt though).  Version management will take care of people
> working on different areas, in case of conflicts (I had a few where
> buildings where updated after my data retrieval from OSM and before
> uploading changesets) it's not fun resolving those in JOSM (even hard
> sometimes).
>
> So I would suggest doing it in small fractions. I tried 'finding'
> building hotspots and just work square per square.  You can also to the
> 'bijgebouwen' first and then later the main buildings, after that
> garages and so on...  So it doesn't have to be segregated into area's ,
> you could just do subsets.
>

Yes, it should be organised in a way you can do an hour or two work on it,
upload it, and return later on with fresh OSM data to avoid conflicts.

>
> The only thing you need to keep track of is the work you've done
> yourself.  I deleted the buildings from the source file once I moved
> them to the target layer, to avoid duplicate validation work.
>
> We could set up a map for this. You can overlay mapbox vector tile
buildings with a GRB background, and see where any GRB buildings stick out,
or the other way around.

We can also use overpass to do some counting in squares or boundaries. F.e.
in Overpass, it would be easy to extract a list of all GRB ids of buildings
in a certain municipality, and compare that with the official data.


> The area size was not always as large, it depends on the concentration
> of buildings.  We should discuss this at the meeting, because I'm just a
> one man show and would love some peer input and feedback.
>
> I was thinking about using HOT osm task manager, it's code is available.
>  That would be awesome to
>
> https://github.com/hotosm/osm-tasking-manager2
>
> Then there is also the matter of downloading (Aka `Ordering`) the data.
> We should do this 'at once' preferably to make sure adjacent areas match
> up. Not doing so might give some problem at the borders of the area.
> But that should be minimal.
>
> There are 307 'gemeentes' / general area's in the selection list.  You
> can combine some, but I haven't tried to combine all for a full download.
>

I ran into the problem of not being able to download it all. My internet
connection isn't stable enough, and when the connection drops, the download
can't be resumed.

But even when you're able to download everything, you should still be able
to split the shapefile. Not all shapefile splitters will work, as some just
run in your memory (and I guess you don't have more than 15 GB RAM).

OSM tasking manager indeed seems like a good idea (it's also used by other
countries to organise imports), and the tasking manager can even provide
links to external files in some way (I've used it when doing an import of
names in Sierra Leone once).

>
> Glenn
>
>
Regards,
Sander
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Bicycle highways

[Sander Deryckere]

Bicycle highways are more like bicycle routes than different highway types.

They are a route specifically made for commuting, connecting residential
area with some work center in a rather straight line.

As such, I think those could get tagged as a cycle route with some specific
sub tags (like a special network).

The question is though: are they verifiable on the ground. Or is it just
that European list naming them. It should only be tagged when you see
something on the ground that you can relate to bicycle highways.

Regards,
Sander

2016-01-24 15:00 GMT+01:00 Glenn Plas :

> Nothing really special about them,  highway=cycleway should be appropriate.
>
> Glenn
>
> On 24-01-16 13:12, Matthieu Gaillet wrote:
> > Hi,
> >
> > Below you will find some information about the developing bicycle
> > highways (or fast cycling routes) a bit everywhere in the world.
> >
> > I was wondering if anything was foreseen to tag such highways ? If not,
> > what's the best place to discuss this, since I guess this should be
> > uniform at world level ?
> >
> > Thanks for your answer,
> >
> > Matthieu (sur iMobile)
> >
> > Début du message transféré :
> >>
> >> Une recherche, évidemment loin d’être exhaustive, m’a fourni une
> >> première liste de ce que l’ECF (European Cyclists’ Federation) dénomme
> >> les  */Fast Cycling Routes/** :*
> >> •  CH: Velobahn (Schaffhouse), TransAgglo (Fribourg), .
> >> •  DE: Radschnellwege  (Ruhr, Berlin, Frankfurt, Heidelberg, München, …)
> >> •  DK: Supercykelstier (Kobenhavn)
> >> •  FR: REV, Réseau Express Vélo, Autoroute à vélos (Toulouse),
> >> Vélostras (Strasbourg), Grenoble, Paris,
> >> •  NL: SnelleFietsroutes, Snelbinder
> >> Image en ligne
> >> •  SV: Supercykelväg (Malmoe)
> >> •  UK: Cycle Superhighways (London)
> >> •  US: California Cycleway(1896)
> >> •  VL: Fietsostrades (réalisations ; projets dans les 5 provinces)
> >
> >
> > ___
> > 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] Agiv import

[Sander Deryckere]

Ruben,

The import is a lot more complicated than the CRAB import, but also less
monkey work, so there will only be a few people doing that import. Normally
those will also be careful about what they import, but they should also be
easy to contact, so you can warn them on beforehand.

However, now it's just in some sort of testing phase, so it's not yet known
who will occupy himself with the import.

Regards,
Sander

2016-01-24 17:48 GMT+01:00 Ruben Maes :

> Thursday 21 January 2016 05:35:11, Marc Gemis:
> > At this moment someone is working on converting the GRB data into
> something
> > that can be "easily" imported.
> > (...)
>
> Great that we'll have a more or less complete map of the buildings in
> Flanders.
>
> I know some places where OSM already has much better building information
> than Agiv, mapped with love and local knowledge. Can I make sure those
> don't get overridden by inferior data with a note in the data or something?
>
> --
> This message is OpenPGP signed.
> ___
> 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] Bicycle highways

[Sander Deryckere]

I think we should get away from those rcn, lcn and ncn networks. And be
freer in the allowed networks.

Even now there are problems with rcn networks used for cycle nodes, as
those are getting introduced in France and Germany, while those countries
already use those networks for other route types.

Regards,
Sander.
Op 24-jan.-2016 22:33 schreef "Erik B" <ebe...@gmail.com>:

> There is a problem with the 'network' tag for those Fietsostrades.
> The change of the network tag of the HST-Route Leuven-Brussel by the
> creator 3 years ago from 'network=rcn' to 'network=lcn' is justified "to
> solve a color conflict with the cycle node network". This looks like
> tagging for the renderer?
> The Fietsostrade (Antwerpen-Mechelen' doesn't have a network tag yet, what
> makes it less visible on maps.
> Shouldn't they get tag 'network=ncn' because Fietsostrades can be
> considered as a national network equal to RAVel?
> It would make those Fietsostrades better visible.
>
> Erik
>
> Op 24-01-16 om 21:13 schreef Marc Gemis:
>
>> The Fiets-o-Strade between Antwerpen en Mechelen is a relation [1]. I
>> don't know who created it.
>> As far as I remember there are "maps" along the route. I think the
>> blue sign [2] is indicating it.
>> For the rest you will only see destination signs for cyclist [3]
>>
>> [1] http://www.openstreetmap.org/relation/1948657
>> [2] https://www.mapillary.com/map/im/YW7xYSxMsa0173CATpNI9g/photo
>> [3] https://www.mapillary.com/map/im/npqKaMq-nByoT1qf4TYi4Q/photo
>>
>> On Sun, Jan 24, 2016 at 5:36 PM, Jo <winfi...@gmail.com> wrote:
>>
>>> Between Leuven and Brussels they are marked in a way that is verifiable
>>> on
>>> the ground.
>>>
>>> We need a separate 'network' tag for them though, and it would be nice to
>>> see they get rendered on the specialised bicycle maps.
>>>
>>> Jo
>>>
>>> 2016-01-24 15:31 GMT+01:00 Sander Deryckere <sander...@gmail.com>:
>>>
>>>> Bicycle highways are more like bicycle routes than different highway
>>>> types.
>>>>
>>>> They are a route specifically made for commuting, connecting residential
>>>> area with some work center in a rather straight line.
>>>>
>>>> As such, I think those could get tagged as a cycle route with some
>>>> specific sub tags (like a special network).
>>>>
>>>> The question is though: are they verifiable on the ground. Or is it just
>>>> that European list naming them. It should only be tagged when you see
>>>> something on the ground that you can relate to bicycle highways.
>>>>
>>>> Regards,
>>>> Sander
>>>>
>>>> 2016-01-24 15:00 GMT+01:00 Glenn Plas <gl...@byte-consult.be>:
>>>>
>>>>> Nothing really special about them,  highway=cycleway should be
>>>>> appropriate.
>>>>>
>>>>> Glenn
>>>>>
>>>>> On 24-01-16 13:12, Matthieu Gaillet wrote:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Below you will find some information about the developing bicycle
>>>>>> highways (or fast cycling routes) a bit everywhere in the world.
>>>>>>
>>>>>> I was wondering if anything was foreseen to tag such highways ? If
>>>>>> not,
>>>>>> what's the best place to discuss this, since I guess this should be
>>>>>> uniform at world level ?
>>>>>>
>>>>>> Thanks for your answer,
>>>>>>
>>>>>> Matthieu (sur iMobile)
>>>>>>
>>>>>> Début du message transféré :
>>>>>>
>>>>>>> Une recherche, évidemment loin d’être exhaustive, m’a fourni une
>>>>>>> première liste de ce que l’ECF (European Cyclists’ Federation)
>>>>>>> dénomme
>>>>>>> les  */Fast Cycling Routes/** :*
>>>>>>> •  CH: Velobahn (Schaffhouse), TransAgglo (Fribourg), .
>>>>>>> •  DE: Radschnellwege  (Ruhr, Berlin, Frankfurt, Heidelberg, München,
>>>>>>> …)
>>>>>>> •  DK: Supercykelstier (Kobenhavn)
>>>>>>> •  FR: REV, Réseau Express Vélo, Autoroute à vélos (Toulouse),
>>>>>>> Vélostras (Strasbourg), Grenoble, Paris,
>>>>>>> •  NL: SnelleFietsroutes, Snelbinder
>>>>>>>  Image en ligne
>>>>>>&g

Re: [OSM-talk-be] Nieuwe Agiv-beelden!

[Sander Deryckere]

Voor de volledigheid, enkel Vlaams-Brabant, Oost-Vlaanderen en
West-Vlaanderen zijn momenteel geupdated.

Antwerpen en Limburg moeten nog even wachten denk ik.

Op 16 januari 2016 15:23 schreef Ruben Maes :

> [en] Agiv released new aerial imagery of Flanders.
>
> [nl] Ik heb net (toevallig tijdens het mappen) gemerkt dat Agiv gisteren
> de nieuwe winterorthomozaïek van 2015 heeft uitgegeven. Ga dus maar
> allemaal in je editor naar die plaatsen waar je dacht 'allez, wanneer gaan
> ze hier nieuwe fotootjes van tonen'! ;)
>
>
> https://www.agiv.be/news/2016/januari/update-middenschalige-orthofotomozaiek-winteropnamen
>
> --
> Dit bericht is ondertekend met OpenPGP.
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Sander Deryckere]

I heard that it would happen this year, not that it already happened.

See this note: http://www.openstreetmap.org/note/275464

2016-01-04 20:29 GMT+01:00 Marc Gemis :

> Hallo,
>
> I heard on the radio today that the Belgian-Dutch border was adapted.
> Belgium became a bit smaller. Anyone knows whether this change is
> already reflected in OSM ? I can't find an online article.
>
>
> regards
>
> m
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] strange boundaries in belgium

[Sander Deryckere]

Wijnendale is geen deelgemeente, dus verdient geen grens (tenzij we er hier
anders over beslissen, er was een eindje geleden een discussie over
kleinere grenzen).

Daarnaast valt wijnegem onder grondgebied Torhout, en niet Ichtegem (en ik
vraag me ook af hoe hij de grens bepaald heeft).

Mvg,
Sander



2015-12-22 5:28 GMT+01:00 Marc Gemis :

> Take e.g. a look at
> http://www.openstreetmap.org/relation/1376903/history, where
> braadworst123 added Wijnendale to Itchtegem admin_level=9.
>
> I left a comment at http://www.openstreetmap.org/changeset/36066185
>
> regards
>
> m
>
> On Tue, Dec 22, 2015 at 5:17 AM, Marc Gemis  wrote:
> > boundary specialist, please take a look at this forum post: strange
> > boundaries in belgium [1]
> >
> > Wambacher runs the website where you can download all boundaries. He
> > also runs a script to detect problems with them.
> >
> >
> >
> > regards
> >
> > m
> >
> > [1] http://forum.openstreetmap.org/viewtopic.php?id=53050
>
> ___
> 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] strange boundaries in belgium

[Sander Deryckere]

Marc,

Ja, ik was er nog mee bezig.

Zoals gezegd op de changeset (
http://www.openstreetmap.org/changeset/36066185), de oude relaties heb ik
hersteld, maar zijn nieuwe wegen heb ik niet verwijderd omdat ik niet weet
wat hij juist getekend had.

Is die grens ergens gedefinieerd of niet?

Hier zijn de desbetreffende grensdelen:

http://osm.org/way/386821195
http://osm.org/way/386798754
http://osm.org/way/386827244
http://osm.org/way/386795768
http://osm.org/way/386835878
http://osm.org/way/386822671


Op 22 december 2015 09:52 schreef Marc Gemis <marc.ge...@gmail.com>:

> Sander, ik zie dat je die wijziging al ongedaan hebt gemaakt,
> braadworst123
> http://www.openstreetmap.org/user/Braadworst123/history#map=11/51.0412/3.3543
> heeft er nog wel een paar aangepast de voorbije dagen, bv. Koekelare
> http://www.openstreetmap.org/relation/1269847 , Houthulst
> http://www.openstreetmap.org/relation/2237451
> enz.
>
> m.
>
> 2015-12-22 9:37 GMT+01:00 Sander Deryckere <sander...@gmail.com>:
> > Wijnendale is geen deelgemeente, dus verdient geen grens (tenzij we er
> hier
> > anders over beslissen, er was een eindje geleden een discussie over
> kleinere
> > grenzen).
> >
> > Daarnaast valt wijnegem onder grondgebied Torhout, en niet Ichtegem (en
> ik
> > vraag me ook af hoe hij de grens bepaald heeft).
> >
> > Mvg,
> > Sander
> >
> >
> >
> > 2015-12-22 5:28 GMT+01:00 Marc Gemis <marc.ge...@gmail.com>:
> >>
> >> Take e.g. a look at
> >> http://www.openstreetmap.org/relation/1376903/history, where
> >> braadworst123 added Wijnendale to Itchtegem admin_level=9.
> >>
> >> I left a comment at http://www.openstreetmap.org/changeset/36066185
> >>
> >> regards
> >>
> >> m
> >>
> >> On Tue, Dec 22, 2015 at 5:17 AM, Marc Gemis <marc.ge...@gmail.com>
> wrote:
> >> > boundary specialist, please take a look at this forum post: strange
> >> > boundaries in belgium [1]
> >> >
> >> > Wambacher runs the website where you can download all boundaries. He
> >> > also runs a script to detect problems with them.
> >> >
> >> >
> >> >
> >> > regards
> >> >
> >> > m
> >> >
> >> > [1] http://forum.openstreetmap.org/viewtopic.php?id=53050
> >>
> >> ___
> >> 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: [OSRM-talk] polyline usage?

[Sander Deryckere]

The algorithm is the same, but the precision in OSRM is higher, you should
call the polyline function with a precision of 6 digits instead of 5.

Regards,
Sander

2015-12-17 18:14 GMT+01:00 Bjorn Madsen :

> Hi - I'm wondering what the better option is to get the polyline out as
> list of latlons
>
> As example I'm using:
>
> waypoints = [(51.460982, -2.588994), (53.348429, -6.255323)]
>
>
> which gives this long polyline http://pastebin.com/dhMZ2Nqb
>
> However, when I decode it, I get (the first 5 records only)
>
>  = {tuple} (514.60953, -25.88957)
> 0001 = {tuple} (514.61061, -25.88728)
> 0002 = {tuple} (514.60382, -25.88428)
> 0003 = {tuple} (514.59867, -25.88208)
> 0004 = {tuple} (514.59651, -25.88124)
>
>
> Any idea to what I'm doing wrong? Has the encoding changed from:
> http://code.google.com/apis/maps/documentation/polylinealgorithm.html
>
>
>
>
>
>
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osrm-talk
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-be] Fietsknooppunten West-Vlaanderen Cyclisme Flandre occidentale

[Sander Deryckere]

Het up-to-date houden van data is een probleem bij meer dan enkel de
fietsknooppunten. Het probleem is zeker even groot bij winkels, cafés en
andere POI.

Dingen checken en dubbel checken is de enige mogelijkheid om de OSM data
up-to-date te houden zonder gebruik te maken van externe data.

In het verleden is het knooppuntennetwerk trouwens al meerdere keren
geupdated. Maar dan op kleinere schaal, en zonder grote aankondigingen. Ook
dit hebben we moeten oplossen door alles nog eens dubbel te checken.

Groeten,
Sander

Op 16 december 2015 11:27 schreef Marc Gemis <marc.ge...@gmail.com>:

> In Duitsland gebruiken ze bij post bussen "collection_times:lastcheck"
> , zie bv. de node http://www.openstreetmap.org/node/1569410933 . Deze
> informatie is dan weer zichtbaar op
> http://www.briefkastenkarte.de/index.html
>
> Misschien kunnen we iets gelijkaardigs invoeren.
>
> Bij Westtoer werken ze ook met Peters en Meters die jaarlijks alle
> netwerken afgaan. In de bespreking van April (of was het mei), was er
> het idee om hen te leren mappen (meerdaagse cursus), niet enkel voor
> netwerken, maar voor "alle" topics. Op deze manier zou een groot deel
> van West-Vlaanderen up-to-date kunnen gehouden worden. Heb daar
> sindsdien niets meer van gehoord.
>
> m
>
> 2015-12-16 11:15 GMT+01:00 Jakka <vdmfrank...@gmail.com>:
> >> Dus denk ik niet dat het zin heeft om alle knooppunten automatisch te
> >> gaan taggen.
> >
> > Vroeg me af, hoe gaan we dat weten dat dit knooppunt en of deze
> verbinding
> > nagezien en geactualiseerd werd.
> > Ook voor eventueel niet osm mappers, maar deze die af en toe een
> verbinding
> > willen checken en doorgeven. Dit om dubbel werk, tijd, fiets km te
> > vermijden.
> > Onderaan link naar een prog. die relaties test op onregelmatigheden.
> > Misschien door nu algemene toevoeging van een "note:check=check node and
> > relation" (of iets anders maar moet duidelijk zijn voor iemand, toerist
> die
> > geen weet heeft dat alles herzien moet worden) op de huidige "rcn_ref"
> node
> > te plaatsen en bij nazicht, update deze verwijderen. Oppassen tag
> > "note=4-91" wordt gebruikt om relaties te melden.
> > Moeten natuurlijk nog mogelijk zijn om dat uit te kunnen lezen met het
> dit
> > prog. Zo kan iedereen mee volgen wat nog niet gedaan is, of waar
> > onregelmatigheden zijn. En zo moet er geen wiki, site lijst opgestart en
> > onderhouden worden. Heb mijn best gedaan om mijn betrokkenheid,
> bezorgdheid
> > te verwoorden.
> > Heb reeds een osm berichtje gestuurd van dit gesprek naar vmarc die nu
> loopt
> > op talk.be
> >
> > http://osma.vmarc.be/nl/networks/be/rcn
> >
> > Sander Deryckere schreef op 15/12/2015 om 16:25:
> >>
> >>
> >>
> >> Op 15 december 2015 16:15 schreef Jakka
> >> <vdmfrank...@gmail.com
> >> <mailto:vdmfrank...@gmail.com>>:
> >>
> >> Fietsknooppunten West-Vlaanderen wordt volledig herzien en op veel
> >> plaatsen bijgewerkt, verlegt, nieuwe verbindingen toegevoegd.
> >> ...275 kilometer langer en er komen 392 knooppunten bij.
> >> Hoe weten de gebruikers OSM, en afgeleide app dat de huidige
> >> bestaande relaties nog niet aangepast, herzien werden.
> >> Kan iemand al deze relaties globaal in één keer voorzien van een
> >> merk tag welk? Een datum van de start herziening met een verklarende
> >> tekst?
> >> Wie de vernieuwde route nagezien heeft, welke tag voorzien ? Gewoon
> >> schrappen vorige tag geen goed idee???
> >> Is er kans dat Toerisme West-Vlaanderen toelaat van hun data te
> >> delen om sneller een update te hebben?
> >>
> >>
> >>
> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk
> >>
> >>
> >> Het aantal knooppunten dat verwijderd wordt is tamelijk klein. Er worden
> >> vooral veel routes en knooppunten bijgemaakt (voor zover ik kon zien,
> >> heb al even vluchtig de kaart kunnen bekijken). Dat maakt natuurlijk de
> >> routes ongeldig, maar op knooppuntniveau valt het werk dan nog wel mee.
> >> Dus denk ik niet dat het zin heeft om alle knooppunten automatisch te
> >> gaan taggen.
> >>
> >> Zelf heb ik een nieuw knooppunt ontdekt  in mijn straat.
> >>
> >> Ik weet niet hoe de contacten met westtoer nu zijn, maar tot op heden
> >> komt alle knooppunt data van surveys.
> >>
> >> Mvg,
> >> Sander
> >>
> >>
> >>
> >> ___
> >> 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] Fietsknooppunten West-Vlaanderen Cyclisme Flandre occidentale

[Sander Deryckere]

Op 16 december 2015 15:27 schreef Marc Portier :

> Sorry voor de falende list-etiquette van het niet inpikken op de lopende
> thread
> (ben pas heraangemeld, en heb dus de vorige mails niet om op te replyen)
> Dus enkel de subject komt overeen :)
>
> Bedankt voor het uitgebreide antwoord, en je mail is goed terechtgekomen
hier ;)


>
> Sta eigenlijk op punt om 3w op verlof te gaan, maar wou toch paar
> opmerkingen/misvattingen wegnemen. Veel dialoog zit er _nu_ dus bij mij
> niet in, ik pik graag weer op na 11/1/2016
>
>
> Alvast wat ik uit de thread haalde en wou rechtzetten/verduidelijken:
>
>
> 1- de print-beperking op de route-data van TVL
>
> >> Die is eigenlijk de facto al van de baan.  Formeel zullen de licenties
> met de data jaargang 2016 ook als dusdanig worden aangepast.  ToerismeVla
> is druk bezig, ook met een open data platform, geef die mannen wat tijd :)
>
> Ja we blijven vanuit de provincie ook kaarten maken en verkopen, en dat
> dient ook echt om een deel van de investering terugbetaald te krijgen.  We
> blijven er hard werk in stoppen om daar een nuttig navigatie-instrument en
> een prachtig geschenk van te maken.
>
> Ondanks open data en electronische navigatie hopen we dat er een markt
> voor blijft. Ouwbollig voorbijgestreefd of klassiek tijdloos is een dunne
> lijn :)
>
> Er is zeker nog plaats voor papieren kaarten wat mij betreft. Zeker als ze
goed gemaakt zijn. Het probleem is momenteel een puur licentietechnisch
probleem. Het is wettelijk mogelijk om OSM data af te printen, en die
prints te verkopen. Dus data die dat verbied kunnen we er niet invoegen. Ik
denk niet dat er iemand momenteel van plan is om die kaarten van OSM data
te verkopen, zeker als jullie kaarten een degelijke prijs/kwaliteit
verhouding hebben.


> Op een gelijkaaridg filosofisch plan: Trouwens de
> innovatie-adapt-disrupt-stress draait zich nu msch om naar de techneueten?
> Is alles hermappen in OSM niet een onnodig werkje als de bron al in open
> data aanlevert?  Zou men vanuit OSM niet beter nadenken over het inplugbaar
> maken van externe open bronnen zonder alles te moeten overtekenen in de
> eigen database?
>
> OSM heeft (zoals wikipedia), twee filosofieën. De eerste is open data
(waar de overheden nu ook veel meer in meestappen), de tweede is
direct-bewerkbare data. Als iemand een fout ziet in OSM moet hij die direct
kunnen bewerken, zonder eerst een administrative procedure te doorlopen.
Die filosofie is natuurlijk niet bruikbaar bij een bedrijf zoals dat van
jullie, of bij eender welke overheid. Het enige dat we kunnen doen is de
data op een min-of-meer automatische manier vergelijken, en zo fouten in
één van de databronnen vinden.


> 2- er zijn niet veel knopen in WestVlaanderen die verwijderd worden, er
> komen er vooral bij
>
> >> klopt, maar de duivel zit in de details: bijna alle knopen veranderen
> ook van nummer.  Dus je gaat er echt wel veel moeten nakijken ben ik bang.
>
> Door de drastische schaal van ons huidig project hebben we meteen ook die
> vrijheid genomen.  Waar de nummers in het verleden vanuit de losse pols
> werden toegekend, hebben we dat nu wat mechanisch/algoritmischer
> aangepakt.  De hoofredenering is dat we maar 1-99 nummers hebben voor 1200
> knopen, en dat het eruit volgende herbruik van nummers nu aan veel meer
> voorwaarden voldoet:
>   - herbruik histogram vervlakt --> meer spreiding van alle nummers die
> even vaak in gebruik zijn (met wat algotime-vrijheid-uitzonderingen)
>   - een nummer wordt niet hergebruikt binnen een straal van X (ik dacht
> 15k)
>   - nummers worden zo toegekend dat elke verbinging tussen 2 nrs door die
> 2 nrs uniek identificeerbaar is (dus als je straks aan een knoop-bord staat
> zal minstens 1 van de andere vermelde nummers je eenduidig zeggen waar in
> west-vlaanderen je bent)
>
> Da's interessant (en lastig voor ons tergelijkertijd). Het betekend dus
dat we na de winter enkel de locaties en geometrie van de routes
grotendeels kunnen behouden. Dan zou het idd wel beter zijn om de nieuwe
punten die we nu al vinden een nieuwe tag te geven.

>
>
> 3- updates en controles
>
> ik ben geen expert in dit soort dingen, maar ik kan me inbeelden dat het
> zou handig zijn als de geometrische objecten in osm makkelijk plaats geven
> voor iets als "geverifieerd als nog steeds correct op -MM-DD" door
> gebruiker xyz --> nodes hebben nu enkel een timestamp als je echt iets
> aanpast zeker?
>
> naast die algemene opmerking kun je natuurlijk specifiek iets voorzien
> voor het werk aan de herziening van het fietsnetwerk nu
>
> Het probleem is ook dat je niet altijd alles contoleerd. Stel dat er een
winkel op een bepaalde locatie is getagd, met openingsuren. Dan passeer je
en controleer je vluchtig dat die winkel er nog is, maar kijk je niet als
de openingsuren nog kloppen. Dan kan je geen timestamp op dat object
zetten. En een timestamp per soort waarde lijkt me wat overkill. Daarnaast
zorgt de willekeurige controle ook voor het 

Re: [OSM-talk-be] Fietsknooppunten West-Vlaanderen Cyclisme Flandre occidentale

[Sander Deryckere]

Jo,

Btw, er worden ook enkele netwerken samengevoegd. Zo waren er vroeger twee
kaarten van de Leiestreek (noord en zuid), en zal er nu maar 1 kaart van de
Leiestreek zijn. Dit heeft waarschijnlijk ook invloed op je master relaties.

Mvg,
Sander

Op 15 december 2015 18:06 schreef Jo <winfi...@gmail.com>:

> Totnogtoe was de party line bij Toerisme Vlaanderen en de provincies: onze
> data mag hergebruikt worden, met een piepklein beperkingske: het mag niet
> afgedrukt (kunnen) worden.
>
> Voor ons betekent dat zoveel als 'onbruikbaar', afblijven.
>
> Als tussenoplossing dacht ik, laat ik de data eens manueel nalopen en hier
> en daar OSM Notes aanmaken, waar er duidelijk verschillen zijn, zodat
> iemand ter plaatse dat gericht kan nakijken. Die Notes geraakten eigenlijk
> niet resolved en na een tijdje stonden ze gewoon in de weg.
>
> Als ze dus niet van gedachten veranderen, dan zit er voor ons niet anders
> op dan op de fiets te springen en het hele netwerk nog eens af te fietsen.
> Ideaal zou zijn als we fervente fietsers ertoe kunnen aanzetten om een GPS
> tracker mee te zeulen en ons de resultaten door te sturen. Bonuspunten als
> zze hier en daar een fotootje willen maken. Topscore als ze de hele weg op
> Mapillary zouden zetten :-)
>
>  Jo
>
> Op 15 december 2015 16:25 schreef Sander Deryckere <sander...@gmail.com>:
>
>>
>>
>> Op 15 december 2015 16:15 schreef Jakka <vdmfrank...@gmail.com>:
>>
>>> Fietsknooppunten West-Vlaanderen wordt volledig herzien en op veel
>>> plaatsen bijgewerkt, verlegt, nieuwe verbindingen toegevoegd.
>>> ...275 kilometer langer en er komen 392 knooppunten bij.
>>> Hoe weten de gebruikers OSM, en afgeleide app dat de huidige bestaande
>>> relaties nog niet aangepast, herzien werden.
>>> Kan iemand al deze relaties globaal in één keer voorzien van een merk
>>> tag welk? Een datum van de start herziening met een verklarende tekst?
>>> Wie de vernieuwde route nagezien heeft, welke tag voorzien ? Gewoon
>>> schrappen vorige tag geen goed idee???
>>> Is er kans dat Toerisme West-Vlaanderen toelaat van hun data te delen om
>>> sneller een update te hebben?
>>>
>>> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk
>>
>>
>> Het aantal knooppunten dat verwijderd wordt is tamelijk klein. Er worden
>> vooral veel routes en knooppunten bijgemaakt (voor zover ik kon zien, heb
>> al even vluchtig de kaart kunnen bekijken). Dat maakt natuurlijk de routes
>> ongeldig, maar op knooppuntniveau valt het werk dan nog wel mee. Dus denk
>> ik niet dat het zin heeft om alle knooppunten automatisch te gaan taggen.
>>
>> Zelf heb ik een nieuw knooppunt ontdekt  in mijn straat.
>>
>> Ik weet niet hoe de contacten met westtoer nu zijn, maar tot op heden
>> komt alle knooppunt data van surveys.
>>
>> Mvg,
>> Sander
>>
>>
>> ___
>> 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] Fietsknooppunten West-Vlaanderen Cyclisme Flandre occidentale

[Sander Deryckere]

Op 15 december 2015 16:15 schreef Jakka :

> Fietsknooppunten West-Vlaanderen wordt volledig herzien en op veel
> plaatsen bijgewerkt, verlegt, nieuwe verbindingen toegevoegd.
> ...275 kilometer langer en er komen 392 knooppunten bij.
> Hoe weten de gebruikers OSM, en afgeleide app dat de huidige bestaande
> relaties nog niet aangepast, herzien werden.
> Kan iemand al deze relaties globaal in één keer voorzien van een merk tag
> welk? Een datum van de start herziening met een verklarende tekst?
> Wie de vernieuwde route nagezien heeft, welke tag voorzien ? Gewoon
> schrappen vorige tag geen goed idee???
> Is er kans dat Toerisme West-Vlaanderen toelaat van hun data te delen om
> sneller een update te hebben?
>
> http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk


Het aantal knooppunten dat verwijderd wordt is tamelijk klein. Er worden
vooral veel routes en knooppunten bijgemaakt (voor zover ik kon zien, heb
al even vluchtig de kaart kunnen bekijken). Dat maakt natuurlijk de routes
ongeldig, maar op knooppuntniveau valt het werk dan nog wel mee. Dus denk
ik niet dat het zin heeft om alle knooppunten automatisch te gaan taggen.

Zelf heb ik een nieuw knooppunt ontdekt  in mijn straat.

Ik weet niet hoe de contacten met westtoer nu zijn, maar tot op heden komt
alle knooppunt data van surveys.

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

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[Sander Deryckere]

Op 14 december 2015 11:43 schreef Ben Abelshausen <ben.abelshau...@gmail.com
>:

> Dag Sander,
>
> 2015-12-13 18:07 GMT+00:00 Sander Deryckere <sander...@gmail.com>:
>>
>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is vele
>> malen groter dan de CRAB database, dus zullen we dit niet meer kunnen
>> hosten op Github, en zullen we een aparte server moeten nemen. Ik vrees ook
>> dat ik niet genoeg computerkracht heb om een dergelijke database in te
>> lezen en te splitsen in verschillende OSM bestanden. Dus zullen we dit
>> verder moeten automatiseren op een zwaardere server.
>>
>> Wat denken jullie hier over?
>>
>
> Ik heb een tijd geleden een server gehuurd die ik samen met joost gebruik
> voor OSM-gerelateerde zaken. Daar kan jij ook toegang toe krijgen als je
> wil. Dat zou meer dan genoeg moeten zijn om dit te hosten.
>
> Het volledige GRB is 15.4GB gecomprimeerd. Natuurlijk hebben we niet alles
nodig (slechts 1 tabel), maar we hebben die wel nodig in ongecomprimeerde
vorm.


> Over de import zelf:
>
> Ik heb altijd gedacht dat we dit op termijn zouden moeten doen in de
> meeste steden omdat het gewoon heel moeilijk is om via luchtfoto's alle
> gebouwen te mappen op een fatsoenlijke manier (probeer maar eens het
> patershol in gent goed te krijgen). Ik denk ook dat de kwaliteit van de
> GRB-data waarschijnlijk beter is dan de onze waar gebouwen echt op elkaar
> gepakt staan.
>
> Waar ik niet zo zeker van ben is of dit ook klopt in meer landelijke
> gemeentes. Heb je daar ook info over? Hoe heb je kwaliteit vergeleken? Veel
> gebouwen zijn ook al in orde buiten de steden omdat het gewoon gemakkelijk
> in te tekenen is.
>
> Ook van landelijke gemeentes zijn quasi alle voorgevels opgemeten (de
meetpunten kan je trouwens zien in een aparte database, alle terristische
meetpunten zijn precies tot op 10cm). Wat de achterkanten betreft kan je
soms enkele fouten zien, maar deze zijn meestal het gevolg van moeilijk
interpreteerbare foto's (zoals kleine aanhangsels gecombineerd met bomen en
struiken). Soms kunnen wij het beter doen, omdat we b.v. ondertussen al
betere foto's hebben. Maar in OSM zullen we volgens mij net zo vaak fouten
maken.

De gevels lijken mij ook belangrijker, omdat ze dan voornamelijk in de
steden de mogelijk geven om in de toekomst met een betere precisie de
voetpaden en straatoppervlaktes te tekenen.

Het vergelijken van de precisie van de achtergevels heb ik simpelweg gedaan
door huizen waarvan ik de achterkant ken te controleren (kennissen, buren,
...), en gemerkt dat daar soms wel wat verkeerde interpretaties in zitten,
maar die niet echt duidelijk zijn op de foto's en ook niet van de straat
kunnen gezien worden.


> 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

Re: [OSM-talk-be] Voorstel import GRB gebouwen

[Sander Deryckere]

Jo,

De GRB gebouwen hebben ook enkele overbodige punten, maar deze zijn niet
nuttig in OSM. De overbodige punten uit het GRB zijn meetpunten.
Bijvoorbeeld als de achterkant van het gebouw niet opgemeten is kan het
gebeuren dat er een extra meetpunt staat op de zijgevel, om de hoek exact
te bepalen. Dit meetpunt op de zijgevel is natuurlijk totaal overbodig in
OSM, maar doordat het zo exact op een rechte lijn ligt, kan het ook
eenvoudig verwijderd worden. Ook bij enkele gebouwen met boogvormen zijn er
meer nodes dan nodig in OSM.

De simplifyAreas plugin van JOSM werkt het best om deze te verwijderen (en
je kan gerust heel strikte instellingen gebruiken), maar ik denk dat we die
functionaliteit wel kunnen kopiëren naar de preprocessor.

@jakka: het is zeker niet de bedoeling om iedereens werk zomaar te
overschrijven. Daar zijn we in België niet meteen voorstander van ;)



Op 14 december 2015 14:45 schreef Jo <winfi...@gmail.com>:

> Hallo Frank,
>
> Als wij hier een 'import' opzetten, dan komt dat eigenlijk neer op het
> klaarzetten van data die omgezet is in OSM-formaat. Het eigenlijke
> toevoegen van de gebouwen en hun adressen, is iets dat we dan met z'n allen
> aanpakken. In geval van 'conflicten' met bestaande gebouwen, is het dan de
> bedoeling dat degene die zich daarmee bezig houdt, nakijkt wat er (al)
> beter is en eventueel het beste van beide werelden overneemt.
>
> Voor 3D-gebouwen zou het dus kunnen dat het grondplan wat wijzigt en dat
> er moet worden nagekeken of dat invloed heeft op het resultaat. In de
> meeste gevallen, denk ik, dat die gebouwen gewoon worden overgeslagen, als
> we ze al in voldoende detail voor 3D hebben.
>
> In Brussel was het de bedoeling om veel 'overbodige' punten te
> verwijderen, dat is niet altijd gebeurd. Ik heb er nog niet naar gekeken,
> maar als deze gebouwcontouren ook zulke punten hebben, zijn die misschien
> wel interessant voor iemand die er verder mee wil, richting 3D. Ik zou ze
> dan dus gewoon behouden.
>
> Jo
>
> Op 14 december 2015 13:49 schreef Jakka <vdmfrank...@gmail.com>:
>
> Wat gebeurt er met de 3D taggen die op de manueel ingetekende buildings
>> verder uitgewerkt werden ?
>>
>> http://wiki.openstreetmap.org/wiki/3D
>>
>>
>> http://demo.f4map.com/#lat=50.7799026=3.1892977=16=33.827=-0.573
>>
>>
>> http://demo.f4map.com/#lat=50.7960880=3.1202353=19=70.514=77.636
>>
>>
>> http://demo.f4map.com/#lat=50.7892170=3.1404653=19=70.514=77.636
>>
>>
>> Sander Deryckere schreef op 13/12/2015 om 19:07:
>>
>>> Hallo,
>>>
>>> Na het bekijken van een hoop GRB data zou ik graag voorstellen om de
>>> gebouwen te importeren.
>>>
>>> Ik heb het hier over het "Gebouwen aan de Grond" (Gbg) bestand, en de
>>> tabel van de gebouwen met adressen (TblGbgAdr).
>>>
>>> De kwaliteit van de GRB gebouwen is goed genoeg. De voorgevels zijn veel
>>> precieser dan wat wij momenteel kunnen opmeten, en de achtergevels
>>> hebben ongeveer dezelfde kwaliteit als onze kwaliteit.
>>>
>>> In het GRB zitten dus ook adressen, maar een gebouw kan geen, één of
>>> meerdere adressen hebben, en een adres uit het GRB kan toegekend zijn
>>> aan één of meerdere gebouwen (daarnaast bevat het GRB ook niet alle
>>> adressen).
>>>
>>> Ik zou dus graag de GRB import koppelen aan de CRAB import, en de web
>>> app uitbreiden.
>>>
>>> De gebouwen van het GRB kunnen opgesplitst worden per postcode, en de
>>> gebouwen die 1-op-1 overeenkomen met een adres kunnen onderverdeeld
>>> worden per straat. De gebouwen die niet toebehoren aan een straat kunnen
>>> in een apart bestand per postcode gezet worden.
>>>
>>> Door een kolom toe te voegen aan de crab-import web app kunnen dus eerst
>>> de gebouwen per straat worden geïmporteerd, en daarna de aparte
>>> adrespunten voor welke we zelf nog moeten uitzoeken tot welk gebouw ze
>>> behoren.
>>>
>>> In theorie is dit allemaal niet zo moeilijk, maar de GRB database is
>>> vele malen groter dan de CRAB database, dus zullen we dit niet meer
>>> kunnen hosten op Github, en zullen we een aparte server moeten nemen. Ik
>>> vrees ook dat ik niet genoeg computerkracht heb om een dergelijke
>>> database in te lezen en te splitsen in verschillende OSM bestanden. Dus
>>> zullen we dit verder moeten automatiseren op een zwaardere server.
>>>
>>> Wat denken jullie hier over?
>>>
>>> Mvg,
>>> Sander
>>>
>>>
>>> ___
>>> 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

[OSM-talk-be] Voorstel import GRB gebouwen

[Sander Deryckere]

Hallo,

Na het bekijken van een hoop GRB data zou ik graag voorstellen om de
gebouwen te importeren.

Ik heb het hier over het "Gebouwen aan de Grond" (Gbg) bestand, en de tabel
van de gebouwen met adressen (TblGbgAdr).

De kwaliteit van de GRB gebouwen is goed genoeg. De voorgevels zijn veel
precieser dan wat wij momenteel kunnen opmeten, en de achtergevels hebben
ongeveer dezelfde kwaliteit als onze kwaliteit.

In het GRB zitten dus ook adressen, maar een gebouw kan geen, één of
meerdere adressen hebben, en een adres uit het GRB kan toegekend zijn aan
één of meerdere gebouwen (daarnaast bevat het GRB ook niet alle adressen).

Ik zou dus graag de GRB import koppelen aan de CRAB import, en de web app
uitbreiden.

De gebouwen van het GRB kunnen opgesplitst worden per postcode, en de
gebouwen die 1-op-1 overeenkomen met een adres kunnen onderverdeeld worden
per straat. De gebouwen die niet toebehoren aan een straat kunnen in een
apart bestand per postcode gezet worden.

Door een kolom toe te voegen aan de crab-import web app kunnen dus eerst de
gebouwen per straat worden geïmporteerd, en daarna de aparte adrespunten
voor welke we zelf nog moeten uitzoeken tot welk gebouw ze behoren.

In theorie is dit allemaal niet zo moeilijk, maar de GRB database is vele
malen groter dan de CRAB database, dus zullen we dit niet meer kunnen
hosten op Github, en zullen we een aparte server moeten nemen. Ik vrees ook
dat ik niet genoeg computerkracht heb om een dergelijke database in te
lezen en te splitsen in verschillende OSM bestanden. Dus zullen we dit
verder moeten automatiseren op een zwaardere server.

Wat denken jullie hier over?

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

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

[Sander Deryckere]

Ik dacht dat ik tamelijk duidelijk was op de wiki. Het GRB was nog niet
open, maar er zit wel data van het CRAB en die kan gebruikt worden.
Gebouwen overtekenen was echter nog niet toegestaan.

http://wiki.openstreetmap.org/wiki/NL:WikiProject_Belgium/Using_AGIV_Crab_data/AGIV_Website_as_Reference

Nu is dat dus wel mogelijk (en moet die pagina geüpdated worden), en heeft
het geen zin om eventuele overgetekende gebouwen te verwijderen. Maar ik
vraag me toch af hoe ik duidelijker kon zijn.

Mvg,
Sander
Op 10-dec.-2015 23:37 schreef "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
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Robot pour CP manquants à Bruxelles - A bot for missing postal codes [FR-EN]

[Sander Deryckere]

2015-12-06 19:25 GMT+01:00 Bruno Veyckemans :

> OK, Thanks for your answers.
>
> I understand that some of you consider postal code as redundant
> information in Belgium. Maybe it is... but I'm not 100% convinced ;-)
> When I use OSM as a database with Overpass Turbo, I like to receive postal
> code as a variable and display it without having to calculate it (maybe
> there's another way to do this ?).
>
> Overpass turbo can limit a query to an area (and thus to a postal code),
and it can also query the areas a certain position belongs to (and return
the postal code). If you want to split info by postal code (f.e. for
statistical purposes), you'll indeed need a script. But with a separate
postal_code extract, and a geographic library, it shouldn't be too hard.


> Whatever, I think I'll focus on something more useful for the community,
> like finding automatically incorrect streetnames (in Brussels, I often find
> streetnames only in french or dutch in node or ways attributes, or
> misspellings). I'll work on this and prepare a special page for these
> findings...
>
>
Yes, there are still problems in Brussels with streetnames. See
http://tools.geofabrik.de/osmi/?view=addresses=4.35285=50.84048=14=no_addr_street,street_not_found,interpolation_errors
for basic address checks (addr:street matching the name tag).

Not only with language order, but also with small words (de, du, ...) that
need to be checked locally. Also see the discussion about language
facilities, where the number of name:nl and name:fr tagged streets is
embarrassingly low.

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

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

[Sander Deryckere]

Hmm, net een poging gedaan om het volledige GRB te downloaden, maar dat is
mislukt.

Het volledige GRB is 15.4GB groot. Maar ergens rond 11GB ging mijn
connectie uit voor even. Normaal is dat geen probleem, en wordt de download
automatisch hervat.

Helaas eist Agiv dat je ingelogd bent om het GRB te downloaden, en werd
mijn request naar een inlogpagina gezonden i.p.v. naar het echte bestand.
Het resultaat is: een nutteloze html pagina in mijn downloads en die 11GB
die al gedownload was is niet meer te vinden.

Dus aan iedereen die de download probeert: doe het met een stabiele
connectie (en zonder pauzes).

Op 4 december 2015 19:23 schreef Marc Gemis <marc.ge...@gmail.com>:

> cabine : Electrical, gas or other cabine
>
> kan onder man_made=street_cabinet of misschien
> pipeline/power=substation afh. van de grootte
>
> in- of uitrit van een parking : highway=service + service=parking_aisle
>
> dacht ik ook, maar via de discussie op reddit die ik net gelezen heb
> [1] moet de toegangsweg highway=service zijn. Heb dat zelf nog nooit
> zo gemapped. Is ook maar in 2014 toegevoegd aan [2], en ik heb die
> wiki pagina al lang niet meer bekeken
>
> [1]
> https://www.reddit.com/r/openstreetmap/comments/3uutzo/service_roads_as_lanes_for_parking/
> [2] https://wiki.openstreetmap.org/wiki/Tag:service%3Dparking_aisle
>
> 2015-12-04 18:55 GMT+01:00 Sander Deryckere <sander...@gmail.com>:
> > Ik heb geprobeerd de Agiv en OSM data wat te vergelijken (onderzoeken
> welke
> > definities gebruikt worden in OSM vs Agiv). Mijn bevindingen staan hier:
> > https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB
> >
> > In het kort, zeker niet alles is bruikbaar. Deze zijn de meest bruikbare
> > bestanden voor OSM:
> >
> > * Gbg and delen van Gba: de gebouw contouren, gevels zijn van goede
> > kwaliteit (door landmeters opgemeten), in de achterstukken kunnen soms
> wat
> > fouten zitten
> > * Wvb: middellijnen van straten (met naam, type en andere data), goede
> > kwaliteit, ook niet teveel nodes
> > * Wgr en Wlas: middellijnen van grachten, beken en rivieren (met naam),
> > goede kwaliteit, zoals wegen
> > * Knw: een hoop verschillende zaken die we mappen mat man_made=* in OSM
> > * Wga: vooral de bushokjes en fietsenstallingen zijn interessant
> > * Wgo: vertaling naar de experimentele area:highway tag? Conversie niet
> zo
> > gemakkelijk
> > * Wti : verkeersplateaus
> > * Wni: muurtjes en vangrails naast de weg
> >
> > De rest komt ofwel niet overeen met OSM (hun wegbaan gebieden nemen ook
> > delen van voortuinen in, en de wateroppervlaktes nemen ook grote delen
> vaste
> > oever in), of heeft geen equivalent in OSM.
> >
> > Mvg,
> > Sander
> >
> > ___
> > 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 voor straatnamen

[Sander Deryckere]

Het GRB (als vector data) is opgedeeld in kleine segmentjes, die zeker aan
ieder officieel kruispunt stoppen, en als data bevat het altijd de linker
en rechter naam van de straat (als die overeenkomen is data dus de name tag
in OSM, anders zit je met een name:left en name:right constructie).

Maar let op: we proberen afkortingen in OSM te vermijden, terwijl het GRB
die soms wel bevat. Dan moet je dus een kleine regex toepassen om de
vergelijking te maken.


Als je wilt dat QA tools stoppen met klagen, dan is het beter om er de
noname=yes tag op te zetten.

Ik denk dat de verschillen niet zo groot zullen zijn, dus als je webkaartje
enkel de verschillen toont, dan zou dat mogelijk moeten zijn.

Mvg,
Sander


Op 5 december 2015 11:12 schreef Marc Gemis :

> 2015-12-05 10:29 GMT+01:00 joost schouppe :
> > In het begin had ik de neiging om onbenoemde wegen in OSM die ook in CRAB
> > onbenoemd zijn te herclassificeren naar iets dat geen naam nodig heeft
> > (highway=service). Maar in de buurt van Zwalm lijken er effectief veel
> wegen
> > te zijn die eenvoudig geen naam hebben. Ik vertrouw CRAB niet genoeg om
> het
> > als bron te beschouwen om te beslissen dat het effectief zo is. Maar wat
> > zouden jullie voorstellen om te doen met zulke straten? Het zou fijn
> zijn om
> > ze aan te duiden als "te controleren ter plaatse". Of zou het OK zijn ze
> als
> > unnamed te definiëren met een source-tag voor de naam uit het CRAB? Op
> die
> > manier zouden ze uit de gewone probleemgevallen verdwijnen, maar kan je
> wel
> > een lijst trekken van wegen die nog eens ter plaatse moeten gechecked
> worden
> > op ontbreken van naam. Iemand andere ideeen?
>
> Ik zou nooit een andere klassificatie gebruiken omdat een of andere QA
> tool niet overweg kan met bv. een residential road zonder naam. In
> Japan ligt het vol van zo'n straten naar het schijnt. Wel is het zo
> dat eerder unclassified straten geen naam hebben. Dus dat of track is
> een betere oplossing dan service.
> Is er geen tag voor unnamed straten ? Enkel als communicatie tussen
> mappers ?
>
> mvg
>
> m
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

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

[Sander Deryckere]

Op 4 december 2015 13:56 schreef Marc Gemis :

>
> OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
> tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.
>
> m.
>
>
Ja, maar het verschil is dat de GRB nu ook als vector-data beschikbaar is,
dus kan je het bestand downloaden (wel via aanvraag blijkbaar, ik heb net
mijn gemeente aangevraagd, geen idee hoe groot het volledig bestand is), en
dan gewoon copy-pasten (en wat tags aanpassen), of misschien zelfs een nog
meer geautomatiseerde import of QA.

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

Re: [OSM-talk-be] Robot pour CP manquants à Bruxelles - A bot for missing postal codes [FR-EN]

[Sander Deryckere]

(Sorry, my French is too bad to write in a readable way, so I'll just
answer in English).

Hi Bruno,

In Belgium, we have the advantage that postal codes are mostly geographical
(with a few exceptions, like the NATO or the VRT/RTBF buildings). This is
in contrast to f.e. the UK, where postcodes are placed on streets instead
of on areas.

Most of the Belgian postcode boundaries are already complete (there are
still some holes on villages where we lack precise boundaries). And any
decent geocoder or GIS system should be able to process areas, and query
the addresses inside an area to assign the postal codes to it. Even JOSM
can select all features in an area (thanks to a plugin), and it's not a GIS
system but merely an editor.

As with other OSM data, there are multiple ways to map postal codes:
* Mapping it on every address
* Mapping it on a street-relation
* Mapping it on a boundary

And I prefer the one with the least amount of redundancy here: the boundary.

When I worked on the tool to import Agiv addresses to OSM, I specifically
put the addr:postcode and addr:city tags as optional. So the mapper can
decide whether he wants it for a certain reason or not (f.e. easier
searching while editing).

Note that Belgium isn't the only place where postcode boundaries are used,
it's used in Germany too, so tools have to support this way of mapping.

http://taginfo.openstreetmap.org/tags/boundary=postal_code#map

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

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

[Sander Deryckere]

Op 4 december 2015 13:35 schreef Marc Gemis :

> Wat houdt de "Vlaamse Open Data licentie v1.2" feitelijk in ?
>
> Volgens:
> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/voorwaarden
>
> "De enige gebruiksvoorwaarde is dat je de naam vermeldt van de
> eigenaar van de data bij het doorgeven, bekendmaken of publiceren van
> de gegevens. (zie
>
> https://www.agiv.be/producten/data-bestellen-en-downloaden/meer-over/open-data-datasets/bronvermelding)
> ."
>
> en volgens:
>
> https://www.agiv.be/~/media/agiv/producten/data-bestellen-en-downloaden/documenten/gratis%20open%20data%20licentie%20vlaanderen%20v%2012.pdf
>
> Zij is op dergelijke wijze ontworpen dat zij compatibel is met andere
> open licenties die een naamsvermelding als voorwaarde bevatten, zoals
> de Engelse Open Government Licence, de Franse Licence Ouverte, de
> Creative Commons Attribution licentie 3.0 of de Open Data Commons
> Attribution licentie 1.0.
>
> Maar dus geen "SA". Zijn die gegevens dan wel bruikbaar om te traceren ?
>
> Vergelijken zoals Joost wil doen is geen probleem.
>
> m.
>
>
>
De licentie is compatibel met ODBL, dat is voor de CRAB import gechekt. Het
ontbreken van SA wil juist zeggen dat we het naar onze eigen licentie
kunnen brengen (dus ODBL voor OSM, of een andere licentie voor een ander
doel).

En vergelijken is altijd de basis voor importeren ;)

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

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

[Sander Deryckere]

Hier kunnen alle verschillende datatypes van het GRB bekeken worden, en kan
je ook kijken welke OSM tags er mee kunnen overeenkomen:
https://www.agiv.be/producten/grb/objectcatalogus/entiteiten

Voor een waterloop lijkt 3m breedte de grens te zijn, alles smaller dan 3m
is een gracht, en heeft dus enkel een middellijn.

Mvg,
Sander

Op 4 december 2015 14:09 schreef Marc Gemis <marc.ge...@gmail.com>:

> Ik vraag me af of dat (copy/paste/edit) wel sneller gaat dan
> overtekenen en onmiddellijk opletten dat je geen wegen snijdt, of
> dubbele beekjes tekent. Hangt ook een beetje af hoe hun representatie
> overeenstemt met die van OSM : way voor midden + polygon voor het hele
> gebied. Wat voor beekjes en grachten enkel de way is in veel gevallen.
>
> m.
>
> 2015-12-04 14:01 GMT+01:00 Sander Deryckere <sander...@gmail.com>:
> >
> >
> > Op 4 december 2015 13:56 schreef Marc Gemis <marc.ge...@gmail.com>:
> >>
> >>
> >> OK, bedankt. Dus als ik GRB als achtergrond gebruik om beekjes te
> >> tekenen (ipv of in combinatie met de luchtfoto's) zit het wel snor.
> >>
> >> m.
> >>
> >
> > Ja, maar het verschil is dat de GRB nu ook als vector-data beschikbaar
> is,
> > dus kan je het bestand downloaden (wel via aanvraag blijkbaar, ik heb net
> > mijn gemeente aangevraagd, geen idee hoe groot het volledig bestand is),
> en
> > dan gewoon copy-pasten (en wat tags aanpassen), of misschien zelfs een
> nog
> > meer geautomatiseerde import of QA.
> >
> > Mvg,
> > Sander
> >
> >
> > ___
> > 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] The Historic Places map and Vandermaelen

[Sander Deryckere]

Marc, you know that Vandermaelen is also available to the Agiv WMTS (only
for Flanders though)? But that WMTS also has Popp, Ferraris and Frickx
maps, so offers even more comparison.

Add this link in JOSM under WMTS imagery to get it: wmts:
http://tile.informatievlaanderen.be/ws/raadpleegdiensten/wmts?request=getcapabilities=wmts=1.0.0

Regards,
Sander

2015-12-04 16:09 GMT+01:00 Marc Gemis :

> The team of the historic places map incorporated the tiles from the
> Vandermaelen maps (1846-1854) in their website. I wrote a short diary
> on how you can enable those tiles:
>
> http://www.openstreetmap.org/user/escada/diary/37470
>
> Enjoy exploring Flanders, Brussels and a part of Wallonia around 1850 :-)
>
> regards
>
> m
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Taalfaciliteiten + taalgrens + straatnamen

[Sander Deryckere]

Here's the data I downloaded:
https://docs.google.com/spreadsheets/d/1itszeYQStJ3ESbnLLvfiR2ZtKAseKBjYg1DH71WdRRc/edit?usp=sharing

All highways of the different municipalities are in different sheets (at
least, everything that should have a name, so no paths, tracks, motorways,
...). It looks like Google Docs can't handle the calculation functions I
used on the first sheet. But perhaps downloading it as .ods and opening it
int libreOffice might work. The data also has the way ids of the elements,
from which you can construct a link to osm.org, or a josm remotecontrol url.


I'm not really into all that political stuff, so if you want to do that,
it's fine for me. I'm more interested in the correct tagging (which seems
to differ between the different types of municipalities).

Regards,
Sander


2015-12-02 15:06 GMT+01:00 Nicolas Pettiaux <nico...@pettiaux.be>:

> Much hanks Sander. Reading your mail, and especially the sentence
>
> "Of all streets in all those municipalities, around 91% had a name, but
> only 26% had name:fr and name:nl tags. Such a low quality is really sad to
> see."
>
> I would like us to propose the following community project : (for which I
> would be happy to organize a meeting in Brussels to celebrate the end and
> communicate to journalist whom we would meet) let us complete and make sure
> we have, at least for those bilingual municipalities 100 % coverage (=
> names in names:fr and names:nl)
>
> Could you please Sander post your lists of street names in a spreadsheet
> like framacalc.org or a text file on a share location (ie github or
> git.framasoft.org) and the URL to the elements (streets) in OSM for us
> (the community) to help translate easily and effectively (looking at the
> real names in the streets) in OSM ?
>
> We could do one commune/gemeente after the other and organize a
> celebration in each commune with the elected representatives and the
> associations, claiming "You have won, your commune is now fully translated
> in OSM".
>
> We could also celebrate the fact that every street of the commune are in
> OSM.
>
> Thereafter, with the communes and their offices, we could organize that
> they internally use and invest into OSM : eg register in OSM all their
> public buildings, post offices ,shops ... And then that they use OSM and
> the related services to build the topic maps of the communes
>
> What do you think ?
>
> Regards,
>
> Nicoals
>
> Le 2015-12-02 14:24, Sander Deryckere a écrit :
>
>
>
> 2015-12-01 19:46 GMT+01:00 Nicolas Pettiaux <nico...@pettiaux.be>:
>
>> I also tend to think that we should find a solution the let any user find
>> the street with any name in Nominatim, especially in this bilingual region.
>> I think that our united and peaceful Belgian OSM community can lead the way
>> here again.
>>
>> The problem with Nominatim isn't one of languages, it's one of
> boundaries. Nominatim is very hierarchical, and requires that one street
> only belongs to one municipality, and one house to one street. So when the
> streets are on the boundary, the houses are on different municipalities,
> which means Nominatim can't find half of them.
>
>
>> For example, I find particularly irritating to note that some commercial
>> car guidance (often called "car gps") with included commercial maps or
>> commercial mapping systems on the web, do offer the region of Brussels
>> (which is bilingual but to a much larger extend French rather than Flemish)
>> in Dutch / Flemish by default. And not a bilingual version which would be
>> at least normal (for me)
>>
>> Thanks for the work
>>
>
> Yes, that's not good. The language of Brussels should either be bilingual,
> or depend on the language settings of the user (which is possible when
> using vector data). So the situation for OSM in Brussels is good IMO (the
> name tag is bilingual, and there's data present to make a French or Dutch
> map when wanted).
>
> But I wonder what to do with municipalities that have language facilities.
> Having language facilities doesn't mean they are completely bilingual, but
> that inhabitants have the option to use the other language. IMO, that's
> represented best by having only one language in the name tag, with
> translations in the name:lg tags (so search in that language works, and the
> map can be rendered in that language).
>
> Meanwhile I did some statistical research on the different municipalities
> with language facilities (only the nl-fr ones, not the ones with German
> facilities or German ones with French facilities).
>
> Of all streets in all those municipalities, around 91% had a name, but
> only 26% had name:fr and name:nl tags. Such

Re: [OSM-talk-be] Taalfaciliteiten + taalgrens + straatnamen

[Sander Deryckere]

2015-12-01 19:46 GMT+01:00 Nicolas Pettiaux :

> I also tend to think that we should find a solution the let any user find
> the street with any name in Nominatim, especially in this bilingual region.
> I think that our united and peaceful Belgian OSM community can lead the way
> here again.
>
> The problem with Nominatim isn't one of languages, it's one of boundaries.
Nominatim is very hierarchical, and requires that one street only belongs
to one municipality, and one house to one street. So when the streets are
on the boundary, the houses are on different municipalities, which means
Nominatim can't find half of them.


> For example, I find particularly irritating to note that some commercial
> car guidance (often called "car gps") with included commercial maps or
> commercial mapping systems on the web, do offer the region of Brussels
> (which is bilingual but to a much larger extend French rather than Flemish)
> in Dutch / Flemish by default. And not a bilingual version which would be
> at least normal (for me)
>
> Thanks for the work
>

Yes, that's not good. The language of Brussels should either be bilingual,
or depend on the language settings of the user (which is possible when
using vector data). So the situation for OSM in Brussels is good IMO (the
name tag is bilingual, and there's data present to make a French or Dutch
map when wanted).

But I wonder what to do with municipalities that have language facilities.
Having language facilities doesn't mean they are completely bilingual, but
that inhabitants have the option to use the other language. IMO, that's
represented best by having only one language in the name tag, with
translations in the name:lg tags (so search in that language works, and the
map can be rendered in that language).

Meanwhile I did some statistical research on the different municipalities
with language facilities (only the nl-fr ones, not the ones with German
facilities or German ones with French facilities).

Of all streets in all those municipalities, around 91% had a name, but only
26% had name:fr and name:nl tags. Such a low quality is really sad to see.

In 46% of the streetnames, I could recognise a typical French element
(tested on Rue, Chemin, Boulevard, Fausée and Avenue), and in 40% of the
streets, I could recognise a typical Dutch element (tested on straat, weg,
laan, dreef and baan). While only in 17% of the cases, I could recognise
both a French and Dutch element (so use a combined name).

Now, I split the list up in categories: 6 Flemish language-border
municipalities, 6 Flemish municipalities around Brussels and 4 Walloon
municipalities. The situation differs a lot between those cases. I could
recognise Dutch and French elements in 50% of the streets around Brussels,
while only 3% in the other Flemish municipalities (vs 53% Dutch elements
only), and 6% in the Walloon municipalities (vs 60% French elements only).
The municipalities around Brussels also have a lot more name:nl and name:fr
tags (70% vs 3% and 12%).

So it looks like the municipalities around Brussels are almost completely
bilingual, while the municipalities around the language border have a
strong preference for their own language (and often even don't mention the
other language). That's probably also the reason why I'm more fond of
single-language naming convention: I'm a lot closer to municipalities like
Mesen and Comines-Warneton, and I notice that the language facilities
aren't used by most inhabitants.

But I do think we should unify both situations. It doesn't really make
sense to have yet another kind of municipality.

Perhaps we should vote on it?

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

[OSM-talk-be] Taalfaciliteiten + taalgrens + straatnamen

[Sander Deryckere]

How should this way be tagged? http://www.openstreetmap.org/way/30126046

The right side is in Heuvelland (Flanders), and has only a Flemish name:
Komenweg

The left side is in Comines-Warneton (Wallonia), which is a French-speaking
municipality with Dutch language facilities, so has a name in both
languages: Chemin des Quatre Rois - Vierkoningenweg.

Now, for names that differ by language, we usually write them as name:nl
and name:fr. For streetnames that differ by side of the street, we usually
write them as name:left and name:right. But how should this be combined
(note that two municipalities with language facilities might also border
each other).

What do you think about the following tags?

name=Komenweg - Chemin des Quatre Rois

name:right=Komenweg
>
name:left=Chemin des Quatre Rois
>
name:left:fr=Chemin des Quatre Rois
>
name:left:nl=Vierkoningenweg
>

Also note that the street continues towards the boundary between Heuvelland
and Mesen (which is a Flemish municipality with French language
facilities). There if could be tagged



> name=Komenweg - Vierkoningenstraat
>
name:right=Komenweg
>
name:left=Vierkoningenstraat
>
name:left:fr=Rue des Quatre Rois
>
name:left:nl=Vierkoningenstraat


You might wonder why I use name:left:fr instead of name:fr:left. Well, I
figured I couldn't make a name:fr tag as there's no translation of
Komenweg. So name:left:fr looks as a conceptual subtag of the existing
name:left.

What do you think of it? Someone has other opinions?

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

Re: [OSM-talk-be] Taalfaciliteiten + taalgrens + straatnamen

[Sander Deryckere]

2015-12-01 12:35 GMT+01:00 Jo :

> That is indeed a hard nut to crack. It's also an edge case (fortunately
> not too many of them)
>
> To make the name tag more complete we could add the translation between
> parentheses. I realise it's not the standard way of working that we use for
> the 'easier' cases.
>
> Jo
>
>
How are municipalities with language facilities normally mapped? I see two
different approaches. In Comines-Warneton, all streets are named FR-NL,
while in Mesen, the streets are only named with the Dutch name.

I think we should just put one language in the name tag, and the other in
the name:lg tag. The existence of such a name:lg tag represents the
facilities given to speakers of other language (they are able to see a
localised map, use search tools in their language, ...), while it
differentiates the language-facilities case from the completely bilingual
region of Brussels. Giving only one name also matches the current naming of
the municipality (it sais "Comines-Warneton", not "Comines-Warneton -
Komen-Waasten").

 @Marc: Nominatim is hardly a reference for this. It already has problems
when a way is only on the boundary between two municipalities, even when
both municipalities use the same name.

I think, if tools are able to search all name:* tags, they would be able to
find all streets. And if they allow binding addr:street to a name:left or
name:right of a street, they would also be able to bind the above addresses
to streets.

It's true that current tools can't display the French name of the above
situations. But that's because Komenweg has no translation to French
translation. More complicated tools could gain the capability to render
names as GRB does (on the right side of the road if the name is different
on both sides, similar to current boundary tags). And in that case, they
could display the French name on the right side. But that won't happen in
the next 5 years I suppose.

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

Re: [OSM-talk-be] Sub-municipal admin boundary relations

[Sander Deryckere]

IMO, admin levels should nest nicely. That's also why the "gemeenschappen"
are no administrative boundaries, but political ones. They don't match with
the other structures like provinces and arrondissements.

So for Oombergen, there are two possibilities: Split Oombergen in two A9
relations and add them to both municipalities (if the split-off part is
big), or keep only one Oombergen relation in one municipality, and add the
split-off part to a different part-municipality.

Part-municipalities are still used in administration (mostly as part of
addresses, though bPost doesn't prefer them), and they're verifiable (from
historic data). So they fit into OSM.

I can also see where you're going with NIS-INS statistical sectors. They're
verifiable (from a central authority), well-defined, and used in
administration. So if they match the existing boundary definitions, they
could be used for an A10 level. Though I wonder where you'll get the data
from. AFAIK, NIS-INS data is still closed? Also note that not all
boundaries should be administrative. I think adding a boundary=statistical
is not an issue in case the statistical boundaries don't match our current
administrative ones.

And, for all other levels, I fear that it's not really verifiable, which is
a key-requirement for inclusion in OSM.

Regards,
Sander



2015-11-30 13:34 GMT+01:00 Vincent Van Eyken :

> Hi to all
>
> Following a question on the forum [1], pointed out to me by escada, I
> think it might be useful to ask the mailing list for a general opinion as
> well… It’s about how to map part-municipality relations [2], something I
> tend to do from time to time so…
>
> I think this issue has probably been discussed a few times already on the
> mailing list and wiki (but without reaching a clear consensus on solid
> guidelines for the smallest admin_levels?)
>
> So here is a summary of how I think the matter stands and how I try to map
> accordingly: (for Dutch, see the forum post)
>
> Admin_level=8: municipality
> admin_level=9: “part-municipality”; areas that were a separate
> municipality up until 1950-1960
> admin_level=10: a distinct, major part of a (part-)municipality, with a
> distinctive ‘core’ (village/hamlet/…) and a well-defined boundary; major
> splits from the original municipality, or suburbs/large neighbourhoods
> (“wijk”) of the ‘new’ municipality
> admin_level=11: smaller split parts of ex-municipalities, smaller
> neighbourhoods (“buurt”), statistical sectors (NIS-INS)?
> or admin_level=12 for statistical sectors (IF they are to be mapped in OSM
> at all)?
>
> Of course admin_level>=9 has no clear legal basis anymore (except for the
> districts in Antwerp, and maybe the statistical sectors), only a
> historical-sociological-mental-… one, so they are hard to define and
> classify hierarchically, both in OSM and in ‘real life’…
>
> Open questions:
> should the whole territory in the end be divided in admin_level=9
> relations? (what with split ex-municipalities? And never-merged ones?)
> is one admin_level relation ‘allowed’ to have direct subareas of different
> levels? (e.g. both AL9 and AL10 as subareas of an AL8) or is the hierarchy
> to be strictly followed (an AL10 always has to be in an AL9, and basically
> follow the letter codes of the NIS-INS for AL9s)?
>
> ---
> [1] http://forum.openstreetmap.org/viewtopic.php?id=30946
> [2] specifically Oombergen: http://www.openstreetmap.org/relation/3395550
>
>
>
> ___
> 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: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return

[Sander Deryckere]

2015-11-30 13:17 GMT+01:00 Bjorn Madsen :

> Hi - We're setting up a server to support the project with a modest 128 Gb
> RAM.
>
> Q1: What is the "right way" to get map updates for .pbf files? Any best
> practices out there? Nightly/Weekly builds? Do you get the data from
> http://download.geofabrik.de/ and are they okay with the traffic?
>
> In any case (not related to OSRM), geofabrik also offers .osc files, thes
only contain the changes and can be applied with the Osmosis tool. This
seriously reduces the traffic to geofabrik. I don't know to what extend
OSRM also supports updating from .osc files, or if you need to clean and
re-fill the complete database.


> Q2: What is the "right way" to prevent import of criminal map updates? I
> read on the OSM forum that somebody got banned after moving industry
> addresses around in updates, with a plausible suspicion on attempting to
> redirect deliveries (without payment).
>
> If there would be an easy way to notice such vandalism, the community
would use it. But in general, vandalism can only be discovered by humans
looking at the data, sometimes it even requires local knowledge to discover
vandalism. So there's not a lot you can do automatically. On the positive
side, I must say we have a lot less vandalism than text projects (like
wikipedia), OSM is technically more difficult to vandalise, and doesn't
give as much gain (f.e. no SEO). The real problem are accidental mistakes
(like typos). These happen a lot more often, and sometimes by trusted
mappers.

If the vandalism is clear (like highway-grafity in a populated area), it's
quickly discovered and removed. If the vandalism is hard to notice (like in
the middle of the pacific, or some name changes of small features), it will
stay around longer, but also shouldn't influence your working a lot (if the
OSM community doesn't notice it, the chance your data users will notice it
is also small). See the wiki for additional info:
http://wiki.openstreetmap.org/wiki/Vandalism


> Q3: Any other best practices to keep in mind?
>
> Kind regards
> Bjorn
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

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

[Sander Deryckere]

Do we really need these old URBIS urls? What use are they for regular
mappers (in contrast to people interested in recent history of a region)?
IMO they would clutter the list.


Meanwhile, I also opened an issue to add the TMS layer to iD:
https://github.com/openstreetmap/iD/issues/2846

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

Re: [OSRM-talk] Project-OSRM: In need of advice; can offer some commercial support to you/ your projects in return

[Sander Deryckere]

2015-11-24 16:07 GMT+01:00 Bjorn Madsen :

> Hi Sander & Emil,
> Thanks for the quick responses. The usage of the lua script is
> particularly useful.
>
> I completely respect the limitations of the demo server and can offer to
> set up another server to support the project. 20Tb of traffic should help?
>
> OSRM is open source, so you're completely free to install your own server,
to fit your own needs or anything you want. If you want to support the
community with an extra server, that would be great too.


> I've been following the discussions on the OSM forum and they've discussed
> the quality of the map to a great extend.
> For planning purposes I appreciate that the main source of error is delay
> in updates. To counter that we are planning to use our commercial help-desk
> to collect information from drivers about detours and unrecorded obstacles
> so that OSM can get the updates with less than a days delay. We can also
> track some vehicles, and capture information such as slowdown caused by
> traffic jams, etc. on major roads. Hopefully this can become a valued
> source of information?
>
> OSM only gathers permanent and verifiable information. And permanent means
that you can expect it to last at least one year after you mapped it. Now,
you can do some more temporary mapping (like setting a highway state to
"construction" if they're doing long works on it). But in general, traffic
jams, temporary obstacles etc don't belong in OSM.

However, OSM is free to mix with other open data, so if anyone takes up the
job to create a database of temporary data, it can be combined with OSM.
Mapbox might indeed be interested in it, but I haven't seen any successful
and open databases like this so far.


> If somebody has a burning interest in accelerating this, then please feel
> free to get in touch for a sponsorship.
> That's the least I can do.
>
> Kind regards
> Bjorn
>
> 
>
>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

[OSM-talk-be] Nieuwe URLs voor Agiv luchtfoto's

[Sander Deryckere]

Hallo,

Blijkbaar zijn er nieuwe URLs voor de agiv luchtfoto's:
https://www.agiv.be/news/2015/november/webdiensten-grb-orthofotos-historische-kaarten-vernieuwd

De oude worden uitgefaseerd.

Het positieve nieuws is dat de URLs nu duidelijker zijn, en er is ook een
TMS URL met de meest recente luchtfoto's, dus kan die gebruikt worden in
iD:

http://tile.informatievlaanderen.be/ws/raadpleegdiensten/wmts?SERVICE=WMTS=GetTile=1.0.0=omwrgbmrvl==image/png=GoogleMapsVL={z}={y}={x}

T.t.z., ik hoop dat de bovenstaande URL werkt, want momenteel zijn hun
servers tamelijk traag (met veel timeouts). maar het is dankzij die trage
servers dat ik nog eens naar de Agiv site gekeken heb, zoals een bekend
filosoof zei: "Ieder nadeel heb zijn voordeel".

PS. De TMS lagen zijn ook gemakkelijker in JOSM. TMS can beter gecached
worden, waardoor zoomen en pannen vlotter gaat.

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

Re: [OSM-talk-be] strange looping tracks

[Sander Deryckere]

2015-11-18 11:41 GMT+01:00 Karel Adams :

>
> PS waarom spreken jullie over "meadows"? "A meadow" wordt gedefinieerd als
> hooiland...  ik vind het al een beetje
> belachelijk dat een handjevol Nederlandstaligen zich van een andere taal
> bedient voor onderlinge discussie; maar als het dan toch moet, doe het dan
> aub goed
>

Omdat Engels een neutrale taal is in België (Vlamingen zijn niet de enige
gebruikers van de lijst), en omdat het makkelijker is om meteen termen te
gebruiken die overeenkomen met OSM tags. Hierbij is meadow dus ook land dat
gebruikt wordt om te grazen (zie
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dmeadow#Tags_in_combination
), als dit fout is, dan ga je daarmee beter naar de tagging mailing list,
maar er zijn al andere proposals geweest daar rond:
http://wiki.openstreetmap.org/wiki/Proposed_features/pasture

Het is niet aan de Belgische community om tags die zo veel gebruikt worden
te wijzigen.

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

Re: [OSM-talk-be] Adressen

[Sander Deryckere]

I'm checking with Roeselare (27000 addresses, of which 2/3 is mapped), and
it loads fine, including the overpass query (
http://crab-import.osm.be/import.html?pcode=8800=true ).

If you have problems, it might be specific to your postalcode and/or
settings. Please share the link you're using.

Regards,
Sander

Op 7 november 2015 16:39 schreef Louis van Boeckel :

> OSM date word niet meer geladen, is dit te verhelpen!!
>
>
> ---
> Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
> https://www.avast.com/antivirus
>
>
> ___
> 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] Adressen

[Sander Deryckere]

Daarnet schreef je "straatnamen en aantal adressen word geladen en dan
blijft het bij loading hangen." , dus vroeg ik als altijd dezelfde straten
geladen worden van een gemeente, of als dit verschilt per keer dat de
pagina geladen wordt.



Op 7 november 2015 17:35 schreef Louis van Boeckel <lodd...@telenet.be>:

> Op alle straten.
>
> Op 7/11/2015 om 17:33 schreef Sander Deryckere:
>
> Altijd op dezelfde straat van een gemeente (zo ja, dewelke)? Of is het
> willekeurig?
>
>
>
> ___
> Talk-be mailing 
> listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-be
>
>
>
>
> --
> [image: Avast logo] <https://www.avast.com/antivirus>
>
> Dit e-mailbericht is gecontroleerd op virussen met Avast
> antivirussoftware.
> www.avast.com <https://www.avast.com/antivirus>
>
>
> ___
> 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] Adressen

[Sander Deryckere]

Tot waar wordt de pagina geladen? Zie je de data tabel met straatnamen?
Krijgen die straatnamen huisnummer totalen?

Als enkel de Overpass data niet geladen wordt, dan kan het misschien zijn
omdat je op een gedeeld netwerk zit (b.v. binnen een school, bedrijf etc.),
en dat iemand op dat netwerk ook een Overpass query aan het runnen is (zie
de één-query-per-ip regel).
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Adressen

[Sander Deryckere]

Altijd op dezelfde straat van een gemeente (zo ja, dewelke)? Of is het
willekeurig?
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Adressen

[Sander Deryckere]

Op 7 november 2015 18:21 schreef Louis van Boeckel :

> hij zegt dat er nog een query is???
>

Ga eens naar http://www.overpass-api.de/api/kill_my_queries , en probeer
daarna opnieuw, maar wel lang genoeg wachten.

@Sus Agiv kaart komt rechtstreeks van de Agiv servers, dus daar kunnen wij
niets aan veranderen (het zou mooi zijn moest MapBox - of een ander bedrijf
met snelle servers - die willen hosten, maar dat is nog niet het geval).
Als je rode pointers krijgt, dan heb je waarschijnlijk de "load data" niet
aangevinkt. Kan je de url even delen?
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Adressen

[Sander Deryckere]

As one IP can only execute one query at a time, and it takes a while before
Overpass decides to start a query (they are queued), it's not possible to
have one query per street (it would take very long to load the page).
That's why all streets of a village are combined into one request.

If someone is willing to experiment, it might be fixable by enlarging the
timeout too (see
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#timeout ),
though it will probably ask a bit of trial-and-error to get a decent
timeout.

Regards,
Sander

2015-11-03 12:55 GMT+01:00 Glenn Plas :

> I forgot to add the reason:
>
> http://overpass-api.de/command_line.html
>
> "504 Gateway Timeout is sent if the server has already so much load that
> the request cannot be executed. In most cases, it is best to try again
> later. Please note that the server decides this based on the timeout and
> maxsize parameters of the request, so smaller values for them may also
> make the request acceptable."
>
> If you try it with 1 street (small request) instead of all the streets
> of a post code, it actually works for me now.  But any street wildcard
> request are to big it seems as they are executed in a single request.
>
> Glenn
>
>
> On 03-11-15 11:50, Glenn Plas wrote:
> > Hi Louis,
> >
> > I assume you are talking about the problem with street analysis,
> > Overpass API has been timing out since a few days when using Sander's
> > toolset:
> >
> > Remote Address:46.4.41.83:80
> > Request
> > URL:
> http://overpass-api.de/api/interpreter?data=%5Bout%3Ajson%5D%3Barea%5B%22boundary%22%3D%22postal_code%22%5D%5B%22postal_code%22%3D%222800%22%5D-%3E.area%3B(node%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%24%22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22!~%22.%22%5D(area.area)%3Bway%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%24%22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22!~%22.%22%5D(area.area)%3Brelation%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%24%22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22!~%22.%22%5D(area.area)%3Bnode%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%24%22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22%3D%222800%22%5D(area.area)%3Bway%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%24%22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22%3D%222800%22%5D(area.area)%3Brelation%5B~%22%5Eaddr%3A(official_)%3Fhousenumber%
>  2
> 4%
> >
> 22~%22.*%22%5D%5B%22addr%3Astreet%22~%22%5EM.*%24%22%5D%5B%22addr%3Apostcode%22%3D%222800%22%5D(area.area)%3B)%3Bout%20center%3B
> > Request Method:GET
> > Status Code:504 Gateway Timeout
> >
> > It started on sunday evening, still not working.
> >
> > Glenn
> >
> >
> >
> > On 03-11-15 08:24, Louis van Boeckel wrote:
> >> wat is er mis met de  adressen inport , update niet meer?
> >>
> >> ---
> >> Dit e-mailbericht is gecontroleerd op virussen met Avast
> antivirussoftware.
> >> https://www.avast.com/antivirus
> >>
> >>
> >> ___
> >> 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] kilometer palen

[Sander Deryckere]

Er is deze:
http://www.geopunt.be/catalogus/datasetfolder/fa453d09-d577-4f5a-ad6c-04f938b757c4

Maar helaas niet downloadbaar.

Op 2 november 2015 18:24 schreef Ben Abelshausen 
:

> Weet er toevallig iemand hier waar ik een dataset kan vinden met de
> locaties van de kilometer palen?
>
> Is er een dataset van AGIV ergens die ik nog niet gezien heb?
>
> Cheers,
>
> Ben
>
> ___
> 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

[OSRM-talk] OSRM demo server down

[Sander Deryckere]

Hi,

I just noticed that the demo site, and routes on http://osm.org through
ORSM are down.

As I didn't see an announcement or mail about it, I thought I should
mention it.

Regards,
Sander

>
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [OSM-talk-be] Wandelknooppunten in Osmand.

[Sander Deryckere]

Als ik me dit probleem correct herinner had het te maken met de
eigenaardige structuur van de tags op de knooppunten. Normaal is er een
vaste tag die aanduidt dat er een icoontje moet komen (zoals
amenity=restaurant) en een tag om aan te duiden welke tekst er bij moet
komen (zoals name="De Posthoorn"). Bij de wandel- en fietsknooppunten moet
bepaald worden a.d.h.v. een enkele key als er een icoontje komt, en moet
die value ook meteen gebruikt worden als de tekst.

Natuurlijk zijn er hier oplossingen voor, maar als je die oplossingen samen
gaat prutsen, dan gaat er binnen het jaar iets mee mis. Er zijn immers niet
veel landen die een dergelijk knooppuntensysteem gebruiken. Een degelijke
oplossing is moeilijker met de huidige architectuur.

Groeten,
Sander

Op 9 oktober 2015 16:28 schreef joost schouppe :

> Klopt, Osmand cached alles wat je gezien hebt.
> Maar lijkt mij toch de moeite om na te vragen bij de mensen van Osmand
> waarom het niet gewoon werkt als POI
> Op 7-okt.-2015 17:33 schreef "Marc Gemis" :
>
> Ik dacht dat OsmAnd de tiles op je smartphone zet. Dus als je thuis kijkt
>> en daarna het veld ingaat, zou het kunnen dat je geen verbinding meer nodig
>> hebt.
>>
>>
>>
>> 2015-10-07 16:30 GMT+02:00 Guy Vanvuchelen :
>>
>>> Hallo Gerard,
>>>
>>>
>>>
>>> Ik had helemaal niets gedownload. Ik veronderstelde dat de
>>> wandelknooppunten gewoon op de offline-kaart zouden verschijnen, ze zijn
>>> immers opgenomen als POI.
>>>
>>> Het voorstel van Marc is al een grote hulp al zou het nog aangenamer
>>> zijn om ter plaatse te kunnen zien of een knooppunt reeds gemapt is, in dit
>>> zonder internetverbinding.
>>>
>>>
>>>
>>>
>>>
>>> Guy Vanvuchelen
>>>
>>>
>>>
>>> *Van:* Gerard Vanderveken [mailto:g...@ghia.eu]
>>> *Verzonden:* woensdag 7 oktober 2015 16:20
>>>
>>> *Aan:* OpenStreetMap Belgium
>>> *Onderwerp:* Re: [OSM-talk-be] Wandelknooppunten in Osmand.
>>>
>>>
>>>
>>> Was dat een .map bestand dat je gedownload had voor een offline kaart?
>>> Daar hoort ook een .xml konfiguratie / style bestand bij voor de
>>> voetwegen.
>>> Dit moet in dezelfde folder staan en hernoemd worden naar dezelfde naam
>>> van de .map
>>>
>>> Gerard.
>>>
>>> Guy Vanvuchelen wrote:
>>>
>>> Bedankt Marc, zo kan ik thuis (met wifi) tenminste zien wat al gemapt is.
>>>
>>>
>>>
>>> Guy Vanvuchelen
>>>
>>>
>>>
>>> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com ]
>>> *Verzonden:* woensdag 7 oktober 2015 13:15
>>> *Aan:* OpenStreetMap Belgium
>>> *Onderwerp:* Re: [OSM-talk-be] Wandelknooppunten in Osmand.
>>>
>>>
>>>
>>> Geen ervaring mee, je kan eventueel ook de on-line kaart
>>> "OpenWandelkaart (BE,NL)" activeren.
>>>
>>> Bij voorkeur als "kaartbron" en de gewone kaart dan als "Underlay-kaart"
>>>
>>>
>>>
>>> Je moet er dan wel rekening mee houden dat je data-abonnement gebruikt
>>> wordt.
>>>
>>>
>>>
>>> mvg
>>>
>>>
>>>
>>> m
>>>
>>>
>>>
>>> 2015-10-07 13:04 GMT+02:00 Guy Vanvuchelen :
>>>
>>> Op de vraag van mapper ‘Schakkebroek’ om rwn knooppunten zichtbaar te
>>> maken kreeg hij volgend antwoord:
>>>
>>>
>>> *wn_ref already supported as POI. I made some corrections and next
>>> nightly version will have icons for them. Search POI for "International
>>> hiking network node".
>>>
>>> 02.10.2015 16:25, Victor Shcherb пишет:
>>>
>>>
>>>
>>> Ik heb de nightly versie gedownload maar het lukt me niet om knooppunten
>>> te zien.  Wel kon ik een eigen filter maken Vervoer –> International hiking
>>> network node maar als ik die activeer vind ik niets. Heeft iemand daar
>>> ervaring mee?
>>>
>>>
>>>
>>> Guy Vanvuchelen
>>>
>>>
>>>
>>>
>>> ___
>>> 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
>>
>>
> ___
> 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] GRB Flanders

[Sander Deryckere]

I'll answer in Dutch, it's about AGIV anyway.

Dus zullen we alle data die nu zichtbaar is op de publiek toegankelijke GRB
WMS ook als vector formaat krijgen?

De mogelijkheden zijn groot. Naast de erg gegeerde gebouwcontouren bevat
het GRB veel andere data die nu, of op termijn, in OSM past. Ik denk aan
stoepranden, 2D wegoppervlakken en voetpaden, en zelfs riooldeksels,
bluswater kranen, lantarenpalen, ...

Maar er zullen ook problemen zijn, en die zijn tamelijk
structureel/technisch van aard. OSM heeft typisch gefocust op een groot
aantal mappers die goed technisch onderlegd zijn maar ook geen specialisten
op vlak van geografie of IT. De typische amateur cartograaf. Vooral in
België, waar open data tot enkele jaren gelden heel schaars was, en er geen
behoefte was om moeilijke technische problemen op te lossen.

Gewoon door de hoeveelheid data die nu zal vrijgegeven worden, zal dat
allemaal moeilijker worden. De typische mappers (die ter plaatse de
situatie gaan bekijken) zullen moeten focussen op zaken die niet in het GRB
aanwezig zijn (voornamelijk winkels en horeca verwacht ik). Terwijl een
kleinere groep zal moeten proberen verschillende imports te realiseren, en
de data up-to-date te houden.

Zelfs bij de CRAB adressenlijst hadden we al problemen met de grootte. We
moesten bijvoorbeeld veel rekening houden met welke datatypes het minste
geheugen gebruiken, om het conversieprogramma draaibaar te houden op een
gewone computer.

Het GRB is zo veel groter dan het CRAB, dat het moeilijk wordt om in te
schatten welke problemen we gaan hebben. Maar het is zeker dat we problemen
gaan hebben.

Als het blijkt dat de technische problemen bij het gebruik van vector data
te groot zijn, dan kunnen we ook nog altijd beslissen om geen import te
doen, maar gewoon de GRB WMS als een bron gebruiken (zoals de huidige
luchtfoto's).

Dus zal het openstellen van de data in ieder geval heel interessant zijn
voor OSM. Maar hoe interessant, dat bepalen we zelf.

Als de open data licentie Flanders gebruikt wordt, dan zie ik geen probleem
op legaal vlak.

Mvg,
Sander
Op 29-sep.-2015 20:27 schreef "Pieter Colpaert" :

> Hi all,
>
> The GRB (https://www.agiv.be/producten/grb) will become open data
> starting January, probably under the free open data license Flanders.
>
> What are the obstructions/possibilities to start using this in OSM?
>
> Kind regards,
>
> Pieter
>
> --
> +32 486 74 71 22
>
> Board of directors
> Open Knowledge Belgium
> http://openknowledge.be
>
> International Open Transport community
> http://transport.okfn.org
>
> Belgian Open Transport community
> http://transport.openknowledge.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] adressen

[Sander Deryckere]

Hmm, nu lijkt het alsof overpass API plat ligt. Ofwel volledig, ofwel
gedeeltelijk (b.v. gebroken ondersteuning voor area zoekopdrachten).

Ik kan momenteel niet uitzoeken waar het probleem juist ligt, zal morgen
eens kijken. Maar hoogst waarschijnlijk zal ik er niets aan kunnen doen, en
zullen we moeten wachten tot overpass zelf hersteld is.

Groeten,
Sander
Op 11-sep.-2015 16:39 schreef "Louis van Boeckel" :
>
> wat is er toch met de adressen,alles blijft op o staan,geeft niet meer
aan wat gedaan?
>
>
> ---
> Dit e-mailbericht is gecontroleerd op virussen met Avast
antivirussoftware.
> https://www.avast.com/antivirus
>
>
> ___
> 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] adressen

[Sander Deryckere]

Ah, hier een anouncement gevonden:
http://wiki.openstreetmap.org/wiki/Overpass_API/status

Blijkbaar is het idd een probleem met areas (gemeentegrenzen in ons geval).
Alle areas zijn uit de DB verwijderd, en worden momenteel opnieuw
aangemaakt.

We moeten dus even geduld hebben, en dan komt alles in orde.
Op 11-sep.-2015 18:19 schreef "Sander Deryckere" <sander...@gmail.com>:

> Hmm, nu lijkt het alsof overpass API plat ligt. Ofwel volledig, ofwel
> gedeeltelijk (b.v. gebroken ondersteuning voor area zoekopdrachten).
>
> Ik kan momenteel niet uitzoeken waar het probleem juist ligt, zal morgen
> eens kijken. Maar hoogst waarschijnlijk zal ik er niets aan kunnen doen, en
> zullen we moeten wachten tot overpass zelf hersteld is.
>
> Groeten,
> Sander
> Op 11-sep.-2015 16:39 schreef "Louis van Boeckel" <lodd...@telenet.be>:
> >
> > wat is er toch met de adressen,alles blijft op o staan,geeft niet meer
> aan wat gedaan?
> >
> >
> > ---
> > Dit e-mailbericht is gecontroleerd op virussen met Avast
> antivirussoftware.
> > https://www.avast.com/antivirus
> >
> >
> > ___
> > 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] adressen

[Sander Deryckere]

Hmm, blijkbaar was ik een "git add" vergeten, waardoor nieuwe straten niet
toegevoegd waren (en ze een error gaven bij het lezen).

Dit moet nu opgelost zijn.

Op 8 september 2015 11:56 schreef Louis van Boeckel :

> wat is er misgegaan met de adressen 2950,2040,2030,2930,2940 enz openen
> niet volledig
>
> ---
> Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
> https://www.avast.com/antivirus
>
>
> ___
> 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] adressen

[Sander Deryckere]

Ok, ben het script aan het runnen, binnen een dik uur zal de data weer
up-to-date zijn (als er zich geen problemen voordoen).

Mvg,
Sander

Op 7 september 2015 12:08 schreef Marc Gemis :

> Sander,
>
> kan jij de database dan nog eens bijwerken aub ?
>
> mvg
>
> m
>
> 2015-09-07 11:49 GMT+02:00 Jan Laporte :
>
>> De grote bijwerking gebeurde inderdaad later, ik dacht in mei.
>>
>>
>>
>>
>>
>> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
>> *Verzonden:* vrijdag 4 september 2015 15:07
>>
>> *Aan:* OpenStreetMap Belgium 
>> *Onderwerp:* Re: [OSM-talk-be] adressen
>>
>>
>>
>> Dan wordt het tijd dat we nog eens een nieuwe dump  maken van de crab
>> data, want als ik naar
>>
>>
>>
>>
>> http://crab-import.osm.be/import.html?pcode=2610=true=true=
>>
>>
>>
>> kijk, lijkt de data van Wilrijk niet echt correct. Addressen met postcode
>> 2610 moeten in het ZZW van Antwerpen liggen, niet in het noorden. De data
>> is van 2 maart 2015.
>>
>>
>>
>>
>>
>> mvg
>>
>>
>>
>> m
>>
>>
>>
>> 2015-09-04 14:56 GMT+02:00 Jan Laporte :
>>
>> Hallo,
>>
>> Antwerpen is in principe volledig, correct en actueel in het CRAB. Zeker
>> voor woningen en appartementen. Die informatie zou je zeker mee moeten
>> nemen, kwestie van er iets minder titanenwerk van te maken.
>>
>> Bye,
>> Jan
>>
>>
>> -Oorspronkelijk bericht-
>> Van: Ben Laenen [mailto:benlae...@gmail.com]
>> Verzonden: donderdag 27 augustus 2015 16:12
>> Aan: OpenStreetMap Belgium 
>> Onderwerp: Re: [OSM-talk-be] adressen
>>
>>
>> Ik denk niet dat er al iemand begonnen is met het systematisch mappen van
>> alle adressen in Antwerpen? De straten moeten er zo goed als allemaal in
>> zitten, in de beginjaren werd daarvoor vergeleken met de straatnamenlijst
>> die je online kan vinden. Maar adressen zelf is nog een ander titanenwerkje
>> (en al zeker als we gebouwen ook ineens willen mappen), dus tegen wanneer
>> dat in OSM staat daar durf ik alvast niets over zeggen. Ten vroegste over
>> een paar maanden, op voorwaarde natuurlijk dat er iemand nu meteen aan
>> begint (en het volhoudt tot het eind), aangezien het volgens mij wel een
>> werkje is waar iemand fulltime wel enkele weken mee zoet zou zijn.
>>
>> Als er interesse is misschien iets met een aantal mensen coördineren om
>> er eens werk van te maken?
>>
>> Ben
>>
>>
>> 2015-08-27 10:01 GMT+02:00 joost schouppe :
>> > Dag allen,
>> >
>> > Ik heb ontdekt dat onze geostatistische website voor Antwerpen sinds
>> > kort Openstreetmap gebruikt om te zoeken op adres (een van de knopjes
>> > rechtsboven als je een kaart in beeld hebt).
>> > Vroeger gebruikte die service de api van CRAB. Alvorens te vragen of
>> > ze alsjeblieft weer naar een volledig adressenbestand kunnen
>> > verwijzen, iemand off the top of their head een idee welk aandeel van
>> > de adressen in 't Stad nu al gemapped zijn en op welke termijn we
>> volledig zouden kunnen zijn?
>> >
>> > Ik vermoed dat onze leverancier ervoor kiest omdat Nominatim sneller
>> > is, en gebiedsdekkend in hun werkingsgebied (Nederland en Vlaanderen).
>> > Maar openaddresses.io is ook gebiedsdekkend. Zou iemand daar al een
>> > open adreszoeker op gebouwd hebben?
>> >
>> > --
>> > Joost @
>> > Openstreetmap | Twitter | LinkedIn | Meetup | Reddit | Wordpress
>> >
>> > ___
>> > 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
>>
>> 
>>
>> AGIV e-mail disclaimer: http://www.agiv.be/gis/organisatie/?artid=355
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>>
>> --
>>
>> AGIV e-mail disclaimer: http://www.agiv.be/gis/organisatie/?artid=355
>>
>> ___
>> 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] adressen

[Sander Deryckere]

Zo, ondertussen is de data geupdated, zie
http://crab-import.osm.be/import.html?pcode=2610=true=true=
(vergeet niet de browser volledig te refreshen indien je nog maar net de
oude data bekeken hebt).

De meeste straten lijken nu in orde, maar de Weversstraat en de
Berkenlaan_WI hebben nog altijd verdachte posities (en de Berkenlaan ook
een verdachte naam).

Mvg,
Sander

Op 7 september 2015 14:47 schreef Jan Laporte <jan.lapo...@agiv.be>:

> Ok, als er nog systematische fouten in zouden zitten, laat weten en ik
> confronteer de stad ermee.
>
>
>
> Bye,
>
> Jan
>
>
>
>
>
> *Van:* Sander Deryckere [mailto:sander...@gmail.com]
> *Verzonden:* maandag 7 september 2015 13:56
> *Aan:* Marc Gemis <marc.ge...@gmail.com>
> *CC:* OpenStreetMap Belgium <talk-be@openstreetmap.org>
> *Onderwerp:* Re: [OSM-talk-be] adressen
>
>
>
> Ok, ben het script aan het runnen, binnen een dik uur zal de data weer
> up-to-date zijn (als er zich geen problemen voordoen).
>
> Mvg,
>
> Sander
>
>
>
> Op 7 september 2015 12:08 schreef Marc Gemis <marc.ge...@gmail.com>:
>
> Sander,
>
>
>
> kan jij de database dan nog eens bijwerken aub ?
>
>
>
> mvg
>
>
>
> m
>
>
>
> 2015-09-07 11:49 GMT+02:00 Jan Laporte <jan.lapo...@agiv.be>:
>
> De grote bijwerking gebeurde inderdaad later, ik dacht in mei.
>
>
>
>
>
> *Van:* Marc Gemis [mailto:marc.ge...@gmail.com]
> *Verzonden:* vrijdag 4 september 2015 15:07
>
>
> *Aan:* OpenStreetMap Belgium <talk-be@openstreetmap.org>
> *Onderwerp:* Re: [OSM-talk-be] adressen
>
>
>
> Dan wordt het tijd dat we nog eens een nieuwe dump  maken van de crab
> data, want als ik naar
>
>
>
>
> http://crab-import.osm.be/import.html?pcode=2610=true=true=
>
>
>
> kijk, lijkt de data van Wilrijk niet echt correct. Addressen met postcode
> 2610 moeten in het ZZW van Antwerpen liggen, niet in het noorden. De data
> is van 2 maart 2015.
>
>
>
>
>
> mvg
>
>
>
> m
>
>
>
> 2015-09-04 14:56 GMT+02:00 Jan Laporte <jan.lapo...@agiv.be>:
>
> Hallo,
>
> Antwerpen is in principe volledig, correct en actueel in het CRAB. Zeker
> voor woningen en appartementen. Die informatie zou je zeker mee moeten
> nemen, kwestie van er iets minder titanenwerk van te maken.
>
> Bye,
> Jan
>
>
> -Oorspronkelijk bericht-
> Van: Ben Laenen [mailto:benlae...@gmail.com]
> Verzonden: donderdag 27 augustus 2015 16:12
> Aan: OpenStreetMap Belgium <talk-be@openstreetmap.org>
> Onderwerp: Re: [OSM-talk-be] adressen
>
>
> Ik denk niet dat er al iemand begonnen is met het systematisch mappen van
> alle adressen in Antwerpen? De straten moeten er zo goed als allemaal in
> zitten, in de beginjaren werd daarvoor vergeleken met de straatnamenlijst
> die je online kan vinden. Maar adressen zelf is nog een ander titanenwerkje
> (en al zeker als we gebouwen ook ineens willen mappen), dus tegen wanneer
> dat in OSM staat daar durf ik alvast niets over zeggen. Ten vroegste over
> een paar maanden, op voorwaarde natuurlijk dat er iemand nu meteen aan
> begint (en het volhoudt tot het eind), aangezien het volgens mij wel een
> werkje is waar iemand fulltime wel enkele weken mee zoet zou zijn.
>
> Als er interesse is misschien iets met een aantal mensen coördineren om er
> eens werk van te maken?
>
> Ben
>
>
> 2015-08-27 10:01 GMT+02:00 joost schouppe <joost.schou...@gmail.com>:
> > Dag allen,
> >
> > Ik heb ontdekt dat onze geostatistische website voor Antwerpen sinds
> > kort Openstreetmap gebruikt om te zoeken op adres (een van de knopjes
> > rechtsboven als je een kaart in beeld hebt).
> > Vroeger gebruikte die service de api van CRAB. Alvorens te vragen of
> > ze alsjeblieft weer naar een volledig adressenbestand kunnen
> > verwijzen, iemand off the top of their head een idee welk aandeel van
> > de adressen in 't Stad nu al gemapped zijn en op welke termijn we
> volledig zouden kunnen zijn?
> >
> > Ik vermoed dat onze leverancier ervoor kiest omdat Nominatim sneller
> > is, en gebiedsdekkend in hun werkingsgebied (Nederland en Vlaanderen).
> > Maar openaddresses.io is ook gebiedsdekkend. Zou iemand daar al een
> > open adreszoeker op gebouwd hebben?
> >
> > --
> > Joost @
> > Openstreetmap | Twitter | LinkedIn | Meetup | Reddit | Wordpress
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
> >
>
> ___
> Tal

Re: [OSM-talk-be] Fietsnetwerk herziening West-Vlaanderen

[Sander Deryckere]

Westtoer hangt me serieus de keel uit. Niet enkel als OSM mapper, maar ook
als recreatieve fietser.

Dan koop je 4 dergelijke kaarten, van €7,5 per stuk, en twee jaar later
zijn ze waardeloos.
Op 5-jul.-2015 12:10 schreef Jo winfi...@gmail.com:

 Dan zullen er hopelijk vanaf oktober mensen zijn die het hele netwerk nog
 's willen affietsen. We kunnen geen gebruik maken van de data die de
 provinvies of Toerisme Vlaanderen ter beschikking stellen, zolang zij de
 clausule over verbod op afdrukken nodig vinden.

 Jo

 Op 5 juli 2015 11:30 schreef Jakka vdmfrank...@gmail.com:

 Misschien is het onnodig tijd en werk insteken tot na ...
 Vanaf 1 oktober 2015 tot maart 2016 herziening netwerk
 http://www.westtoer.be/nl/actief-beleven/fietsen/herziening-fietsnetwerk

 Jakka


 ___
 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] Melkerij / Laiterie

[Sander Deryckere]

Bij ons wordt met een melkerij de melkverwerkende fabriek bedoeld. Dit zie
je ook aan straatnamen, typisch loopt de Melkerijstraat naar een melk
fabriek (zie https://www.openstreetmap.org/#map=17/50.91316/2.90858 ).

Een plaats waar koeien verzorgd, en dan ook gemolken wordt meestal een
Melkveebedrijf genoemd, en geen melkerij.

Ik zou gaan voor man_made=works + produce=diary, eventueel met de shop tags
als ze daar zuivelproducten verkopen aan particulieren. Het feit dat de
melkerijen in Mali kleiner zijn is niet echt van belang voor mij. Grootte
moet in perspectief gezien worden, en aangezien bijna alle fabrieken daar
kleiner zullen zijn, vergelijkbaar met onze fabrieken van een aantal
decennia terug, kunnen we ook gerust van een fabriek spreken.

Door het gebruik van de sub-tag maak je meer kans dat de fabrieken
gerenderd worden. Zelfs als de renderer niet weet wat een melkerij is, kan
a.d.h.v. man_made=works een fabrieks-icoontje weergegeven worden, en
dankzij de naam wordt het meestal duidelijk welke fabriek het is. Meer
gespecialiseerde renderers kunnen dan een specifiek melkerij icoontje tonen
voor man_made=works + produce=diary.

Groeten,
Sander

Op 16 juni 2015 13:11 schreef Jorieke Vyncke jorieke.vyn...@gmail.com:

 Hey Jo,

 Bedankt voor je antwoord en het mee denken!

 Ik denk dat de soort melkerij waar ik naar op zoek ben, eigenlijk wel
 heel vergelijkbaar is met het systeem dat er vroeger bestond bij ons.
 Vroeger werden de koeien immers allemaal met de hand gemelkt en werd
 de melk nadien naar de melkerij gebracht. Elk dorpje had vroeger zijn
 eigen melkerij, kijk maar hoeveel oude melkerijen er bestaan en
 melkerijstraten. Deze melkerijen zijn na een tijd inderdaad
 geevolueerd naar een melkfabriek bij ons. Hier trouwens ook, er zijn
 enkele grote melkfabrieken, vb MaliLait, maar de meerderheid is dus
 nog de kleine melkerij. Ook op wikipedia trouwens een mooi artikel
 http://nl.wikipedia.org/wiki/Milcobel.

 Eigenlijk denk ik dat je het een beetje met een windmolen kan
 vergelijken...
 die mappen we als man_made=works, dus wat denken jullie van man_made=diary
 ?
 Met dan inderdaad toe te voegen shop=beverages + drink:milk=yes en
 andere...

 Groetjes, Jorieke


 Op 16-06-15 heeft Jowinfi...@gmail.com het volgende geschreven:
  Ik vrees dat je een tag zal moeten voorstellen. In zekere zin is het niet
  echt een melkerij, al heet het wel zo. De melkerij is, wat mij betreft,
 de
  plaats waar de koeien gemolken worden.
 
  Dit is eigenlijk de volgende stap, het verwerken van de melk. Ik vrees
 dat
  je nieuwe tags zal moeten voorstellen op tagging. Je kan er dan ook nog
  boter of yoghurt van maken en verpakken. Dat zal soms op dezelfde
 plaatsen
  gebeuren en soms ook niet, dus aparte tags voor elk stap van het
 proces...
 
  Hier gaat het als volgt, de koeien worden om de 12 uur aan melkmachines
  gehangen. Daarna gaan ze de wei op, of ze worden vooraf  binnengehaald.
  Alles gaat in een groot vat en er komt een citerne langs om de melk op te
  halen. Dan gaat het naar een 'melkfabriek', die de hele rest van de
  verwerking en verpakking doen.
 
  Vroeger ging dat anders; er bestaan bv. ook aanhangers waarmee de koeien
 op
  de weide gemolken kunnen worden, of het kan 'ambachtelijk' met de hand
  gedaan worden.
 
  Groeten,
 
  Jo
 
  Op 16 juni 2015 12:27 schreef Jorieke Vyncke jorieke.vyn...@gmail.com:
 
  Dag iedereen,
 
  Ik ben op zoek naar een tag voor een melkerij.
  Want tot nu toe heb ik nog niet echt iets geschikts gevonden.
 
  Ik werk momenteel voor BTC (het Belgisch ontwikkelingsagentschap van
  de overheid) in Mali en we gaan hier proberen zo veel mogelijk
  melkerijen in kaart te brengen.
 
  Wat is een melkerij hier: een plek waar de boeren hun melk binnen
  brengen en ze gecontroleerd en gepasteuriseerd wordt. Vaak is er ook
  een verkoopspunt aan, maar niet altijd. De melk gaat na deze melkerij
  meestal naar verschillende andere bedrijven of verkoopspunten in
  steden.
 
  Het is dus niet enkel een verkoopspunt, maar een echte fabriek is het
  ook niet omdat ze allemaal heel kleinschalig zijn. Hierbij een foto
  van eentje:
  https://www.dropbox.com/s/93mts1qz5kdokld/2015-04-23_16-23-23.jpg?dl=0
 
  Wat denken jullie?
 
  Groetjes, Jorieke
 
  ___
  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] Osmose waterway is deprecated

[Sander Deryckere]

Apparently, that page is active again:
http://wiki.openstreetmap.org/w/index.php?title=Tag:waterway%3Driverbankaction=history

Some say waterway=riverbank is deprecated, others say it isn't. And the
wiki page only reflects the opinion of the one who last edited it.

As always, in OSM you should do what seems best, and not blindly trust the
wiki nor tool authors. I peronally like the water=river tagging, just
because waterway=riverbank seems strange to use it for an area (certainly
for a canal). You can be sure that the renderers understand both cases as
natural=water and waterway=riverbank are used a lot.

Regards,
Sander

2015-05-26 13:28 GMT+02:00 Jakka vdmfrank...@gmail.com:

 Hi,
 Is this correct osmose gives waterway as deprecated.
 Tag waterway is deprecated: natural=water+ water river, canal,... 

 If something changes must the wiki page not first be corrected ??
 http://wiki.openstreetmap.org/wiki/Tag:waterway%3Driverbank
 examples here.

 http://osmose.openstreetmap.fr/nl/map/#zoom=17lat=50.8498230lon=4.3352867item=4010level=2

 Jakka


 ___
 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] Fietsknooppunten, bicycle nodes Roundabouts and around squares

[Sander Deryckere]

The old recommendation was to not split roundabouts. It makes it easier for
the software to see it's a roundabout when it's closed, and it makes
routing stuff (like counting the exit number) easier.

However, that recommendation changed on the wiki some years ago (AFAICS,
without discussion). So now both situations happen (complete roundabout as
part of a route, and split roundabouts), and tools have to be able to
handle both situations.

For me, the disadvantage of split roundabouts is that you can't modify them
as easily. When it's a complete circle, it's easy to scale it, rotate it,
and make it perfectly circular. With split roundabouts, this becomes harder.

I still prefer complete circles for most cases.

Regards,
Sander

2015-05-15 12:12 GMT+02:00 Marc Gemis marc.ge...@gmail.com:

 Not everybody splits a roundabout for a route, although I usually split
 it. JOSM shows a nice roundabout icon in the route relation editor in case
 you do not split. Routers are probably smart enough to escape the
 roundabout themselves.
 When it is not a roundabout, it is normal to split the street (square),
 just as with a regular street.

 Extend of market place: area:highway is often mentioned to map the extend
 of a street.


 regards


 m

 On Fri, May 15, 2015 at 11:49 AM, Jakka vdmfrank...@gmail.com wrote:

 Hi,

 How do we tag the roundabouts in a relation of hiking route minor problem
 but bicycle routes (knooppunten) and public transport routes  ?
 I cute the roundabouts in pieces highway to highway. Is this the properly
 way?
 But gives the tester prg like http://osma.vmarc.be/  or
 http://analyser.openstreetmap.fr/cgi-bin/index.py?relation=2718669 a
 alert?
 Roundabouts you must take at the right hand.(Europe)
 1 Example south point 03 to north roundabout 5 highways, coming from the
 south leaving first highway to point 28, got a nice line in relation.
 Coming back from the opposite way from point 28 the way must leave at the
 4 highway to point 03 a have a gap in the relation.
 If the junction=roundabout must be keep to getter you see symbol
 roundabout.
 2 Example what with a large square, marketplace, which cannot be tagged
 as roundabout but still need to drive ride right hand around it?
 situation like first example you have a gap in the relation line.

 On response of Guy question several wikipage were recommended not easy to
 find your way.
 --

 Jakka


 ___
 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] Kaartje om huisnummer-mappers terug te vinden

[Sander Deryckere]

De OSM data is van december 2014, dus idd al wat verouderd.

Op 20 april 2015 15:39 schreef Marc Gemis marc.ge...@gmail.com:

 Karel,

 Ik weet dus niet wat en hoe er geteld wordt om het percentage te bepalen.
 Dus misschien map jij net iets anders dan wat er gezocht wordt ? Of gaan ze
 uit van een hele oude dump ? Ik weet het niet.
 Ik merk wel dat in mijn thuisbasis er wel een verschil is, waarvan de
 meeste adressen ook manueel gemapped zijn.

 Momenteel is er telkens veel tegenkanting bij automatische imports. Dus ik
 zie dat nog niet zou snel gebeuren. Ook al omdat de AGIV databank nu niet
 bepaald fouten vrij is.
 Mensen die echt AGIV zonder correcties willen gebruiken kunnen natuurlijk
 zelf OSM  AGIV combineren. De sterkte hier is juist die extra validatie,
 dus snel zal het niet gaan.

 mvg

 m



 2015-04-20 15:32 GMT+02:00 Karel Adams fa348...@skynet.be:

  Huh, ik dacht dat ik heel flink had gewerkt in Haacht, maar blijkbaar
 komt het % hier nog maar amper boven de ruisdrempel? Frustratie! Ik weet
 wel dat er nog heel wat te doen blijft, maar toch... Of is het eigenlijk
 weinig zinnig om manueel huisnummers te mappen, omdat er vroeg of laat toch
 wel een massa-import komt vanuit een of ander GIS, al dan niet
 overschrijvende wat met veel toewijding manueel werd ingebracht?
 Karel

 PS sed -e 's/area\'s/areas/' ;)



 On 20-04-15 13:14, Marc Gemis wrote:

 Deze kaart [1] zou aangeven waar huisnummers gemapped zijn.

  Kan wel kloppen, 'k hier toch duidelijk regio's waar Sander, Glenn en
 Sus, e.a. adressen hebben toegevoegd.

  mvg

  m


  A map [1] that clearly shows the area's where housenumbers have been
 mapped.



  [1]
 http://www.regio-osm.de/hausnummerauswertung/anzeige_dynamisch.html?zoom=9lat=51.01825lon=4.92155layers=BTTFF


 ___
 Talk-be mailing 
 listTalk-be@openstreetmap.orghttps://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] Iinconsistences at the level of municipalities?

[Sander Deryckere]

2015-04-08 12:45 GMT+02:00 Alexander Mikhailian mikhail...@mova.org:

 Hello,


 I am total noob in OSM, but here are a couple of issues that I spotted
 after exporting municipalities from OSM:

 1. relation 3364845 seems to be a duplicate of the relation 1245629 for
Aken.

 The first one is the postal code boundary, the second one is the
administrative boundary. Postal codes often match with administrative
boundaries, but not always. That's why, in the past, we added postal code
information to administrative boundaries, but we later realised that it's
better to have their own boundary type, so we can catch the special cases.



 2. the generic name for relation 2416075 is grod instead of Olne.
FYI, grod is town in Polish.


This is indeed a mistake (someone accidentally changed the name 2 weeks
ago). You can correct it if you want.


 There are a few subtler issues, but just for those two: who can fix
 and what's the best way of making the fix?


When working with boundary relations, the best editor is JOSM. So you
install JOSM, download a part of the boundary of Olne, then search for the
boundary relation in the relation list, and edit the name. We can give more
info if it's needed (but you should best tell what you already know).


 P.S. I used the following Overpass API query to extract municipalities:

 [out:json];
 area[name:en=Belgium][admin_level=2]-.a;
 rel[admin_level=8](area.a);
 out geom;


 --
 Alexander Mikhailian


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

[OSM-talk-be] Fwd: Administrative map of Belgium with mapping of the polygon to the municipality name or zip code?

[Sander Deryckere]

Overpass is the answer to your question.

You can use overpass to extract the boundary polygons, and then other
software to convert it to a rendered map.

See this example query: http://overpass-turbo.eu/s/8rD

With that query, you can simply extract all municipalities (mapped with
admin_level=8) in the province West-Vlaanderen. A smaller area makes it
easier to test. To load Belgium, you should just switch the name to
Belgium, and the admin_level to 2 (for national boundaries).

It's possible that Belgium becomes too heavy for overpass-turbo, in that
case, you can go via Overpass API directly (see
http://www.overpass-api.de/query_form.html ), which doesn't render the
received data, but just gives you the data as text.

Also note that the output format is defined to be JSON, if you prefer other
formats, there are more choices:
http://wiki.openstreetmap.org/wiki/Overpass_API/Overpass_QL#Output_Format_.28out.29

Is that enough for the municipalities? Or do you also want more info on
rendering the maps?

For the zip codes, well, those aren't completely mapped yet. Some
municipalities have multiple zip codes, and it's very hard to find correct
boundaries for those.

Regards,
Sander

2015-03-28 13:36 GMT+01:00 Alexander Mikhailian mikhail...@mova.org:

 Hello,

 I have an idea for a language study project in Belgium and it would
 really help if there were a map of Belgian municipalities with the names
 of municipalities or zip codes linked to polygones. I found [1] but it
 has only ids of the form path80-8-8. which is not very helpful.

 Could you by any chance give me hint as to where I can find such a map?

 Thanks in advance,

 --
 Alexander Mikhailian

 [1] http://commons.wikimedia.org/wiki/File:Belgium_administrative.svg


 ___
 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] Local chapter OSMF

[Sander Deryckere]

So what will be the local chapter?

Will OFKN as a VZW be the local chapter? Will it be a part of OFKN, or a
new VZW? I guess it needs to be some sort of organisation.

Apart from that unclear part. I fully support having a local chapter for
Belgium. It can only help with finding funds to organise stuff.

Regards,
Sander

2015-03-23 11:59 GMT+01:00 Ben Abelshausen ben.abelshau...@gmail.com:

 Hi Marc,

 On Mon, Mar 23, 2015 at 11:51 AM, Marc Gemis marc.ge...@gmail.com wrote:

 Everybody is free to do what (s)he wants, not ? :-)


 No because if we claim to represent the OSM-community in Belgium we should
 act according to what they want to do! ;-)

 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

Re: [OSM-talk-be] Adressen via AGIV Crab

[Sander Deryckere]

Tadaa: http://crab-import.osm.be/import.html?pcode=3800loadOsm=true

Overpass heeft de nieuwe grenzen al gevonden.

Op 18 maart 2015 15:37 schreef Sander Deryckere sander...@gmail.com:

 Aangezien ik geen oude kaarten van Sint-Truiden kon terugvinden, heb ik
 dus maar een schatting gemaakt van de onderverdeling. Verbeteren is dus
 altijd toegestaan.

 Zie hier de nieuwe postcode grenzen:

 http://osm.org/relation/4681897
 http://osm.org/relation/4681898
 http://osm.org/relation/4681899

 Normaal gezien zou overpass die binnen enkele dagen moeten oppikken.

 Groeten,
 Sander

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

Re: [OSM-talk-be] Adressen via AGIV Crab

[Sander Deryckere]

Kopiëren mag niet, controleren wel.

Nu, als je een verschil ontdekt, waar ligt de grens tussen kopiëren en
controleren? De grens ligt volgens mij bij de hoeveelheid werk je in je
onderzoek stopt. Als je na de ontdekking van het verschil gewoon de versie
van bPost overneemt, dan is dat kopiëren. Als je daarentegen een fout
rapporteert aan de gemeente, en het onderzoek van de gemeente afwacht, dan
ben je bezig met controleren, en dat mag wel.

Op 19 maart 2015 10:30 schreef Marc Gemis marc.ge...@gmail.com:

 gebruik voor commerciële doeleinden van het geheel of een deel van deze
 website is verboden

 IMHO is de data een deel van de website. Je kopieert dit naar een databank
 die voor commerciële doeleinden kan gebruikt worden.
 Gelukkig leven we niet in Canada, waar iemand die postcodes verzamelt via
 crowd-sourcing en via open source beschikbaar stelt, een oproep voor de
 rechtbank heeft gekregen van de Canadese Post.
 Hier gaat er  hopelijk geen haan naar kraaien.

 m.

 2015-03-19 10:14 GMT+01:00 Verhoeven Fr sus...@gmail.com:

  Dit is toch een dienst die gratis wordt aangeboden


 http://www.bpost.be/site/nl/residential/customerservice/search/address.html

 De enige beperking is maximum 20 raadplegingen per dag.  Of ik het
 resultaat gebruik om OSM te valideren of om op een omslag te zetten, daar
 zie ik het verschil niet in.
 Ik gebruik geen enkel deel van hun lay-out.

 Groetjes

 Sus



 Le 17/03/15 17:51, Marc Gemis a écrit :

 Je mag feitelijk de gegevens van de bpost website niet gebruiken:

  http://www.bpost.be/site/nl/disclaimer.html

  *Auteursrecht*
 De website met inbegrip van teksten, lay-out, grafische bestanddelen,
 presentatie, logo’s, software en andere bestanddelen van deze site is
 beschermd door de intellectuele eigendomsrechten van bpost of haar
 informatieleveranciers, zoals het auteursrecht, naburige rechten,
 databankrecht en merkenrecht.
 Reproductie, verspreiding, verkoop, verdeling, publicatie, aanpassingen,
 vertalingen, bewerkingen en gebruik voor commerciële doeleinden van het
 geheel of een deel van deze website is verboden, tenzij met
 voorafgaandelijke en schriftelijke toestemming van bpost.


  mvg

  m


 2015-03-17 16:31 GMT+01:00 Sus Verhoeven sus...@gmail.com:

  Een middel is voor elke straat éénmaal Bpost op te roepen, die geeft
 het goede zonenummer., Zelden heeft een straat 2 zonenummers, en in dat
 geval geeft men de uiteinden op. En stillaan zou de zone grens zichtbaar
 worden.
  De Amstenradelaan ligt in 3800.

  Sus

  2015-03-17 15:41 GMT+01:00 Sander Deryckere sander...@gmail.com:



 Op 17 maart 2015 15:04 schreef Sus Verhoeven sus...@gmail.com:

  Ik heb met de import tools van Sander op de 3800 (Sint-Truiden) de
 Amstenradelaan genummerd en alles verliep normaal., De gebouwen waren daar
 al getekend.
 Ik moet in OSM wel nadien tot het uiterste inzoomen om de nummers
 zichtbaar te krijgen.Ook Nominatin kan er mee overweg. Alles is dus
 normaal, alhoewel er daar nog meer dan 13.000 gebouven te nummeren zijn.
 Op de import tools van Sander zijn de aanpassingen nog niet zichtbaar,
 maar dat kan wel nog een tijdje duren.
  Sander, hoe dikwijls per dag wordt die import tool aangepast ?


  De OSM data komt live van Overpass iedere keer dat je de pagina
 vernieuwt of op Update klikt. En normaal heeft overpass slechts enkele
 minuten vertraging (hoewel er natuurlijk op iedere server wel eens grotere
 vertragingen voorkomen).

  Het probleem is echter dat er geen postcode grens bestaat in
 Sint-Truiden (zoals https://www.openstreetmap.org/relation/3366823
 voor postcode 8840). Sint-Truiden zelf heeft 3 postcodes, en een adres is
 maar gedefinieerd onder een postcode (twee verschillende huizen in
 Sint-Truiden kunnen perfect hetzelfde huisnummer hebben en dezelfde
 straatnaam, maar een verschillende postcode).

  Ik heb geprobeerd om ook addr:postcode als tag toe te staan, maar dan
 werd de overpass query verschrikkelijk traag (die moest immers alle
 adressen in Vlaanderen gaan filteren.

  De enige mogelijkheid is dus om die grenzen te tekenen (ook al zijn
 ze slechts bij benadering), en dan zal Sint-Truiden meteen heel wat groener
 zijn.


   Ook in Crab zitten er fouten in de zone nummering, maar er is nog
 Bpost voor de controle, ook voor missende huisnummers. Fouten op
 zonenummers in CRAB gebeuren meestal op straten die een zonegrens
 overschreiden.

  Ik zit nu terug rustig bezig op de 3582, nog ogeveer 1000 te gaan ;-)

  Sus

  Ik doe nu rustig verder opde 3582


  ___
 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 
 listTalk-be@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk-be] Adressen via AGIV Crab

[Sander Deryckere]

Aangezien ik geen oude kaarten van Sint-Truiden kon terugvinden, heb ik dus
maar een schatting gemaakt van de onderverdeling. Verbeteren is dus altijd
toegestaan.

Zie hier de nieuwe postcode grenzen:

http://osm.org/relation/4681897
http://osm.org/relation/4681898
http://osm.org/relation/4681899

Normaal gezien zou overpass die binnen enkele dagen moeten oppikken.

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

Re: [OSM-talk-be] Adressen via AGIV Crab

[Sander Deryckere]

Op 17 maart 2015 15:04 schreef Sus Verhoeven sus...@gmail.com:

 Ik heb met de import tools van Sander op de 3800 (Sint-Truiden) de
 Amstenradelaan genummerd en alles verliep normaal., De gebouwen waren daar
 al getekend.
 Ik moet in OSM wel nadien tot het uiterste inzoomen om de nummers
 zichtbaar te krijgen.Ook Nominatin kan er mee overweg. Alles is dus
 normaal, alhoewel er daar nog meer dan 13.000 gebouven te nummeren zijn.
 Op de import tools van Sander zijn de aanpassingen nog niet zichtbaar,
 maar dat kan wel nog een tijdje duren.
 Sander, hoe dikwijls per dag wordt die import tool aangepast ?


De OSM data komt live van Overpass iedere keer dat je de pagina vernieuwt
of op Update klikt. En normaal heeft overpass slechts enkele minuten
vertraging (hoewel er natuurlijk op iedere server wel eens grotere
vertragingen voorkomen).

Het probleem is echter dat er geen postcode grens bestaat in Sint-Truiden
(zoals https://www.openstreetmap.org/relation/3366823 voor postcode 8840).
Sint-Truiden zelf heeft 3 postcodes, en een adres is maar gedefinieerd
onder een postcode (twee verschillende huizen in Sint-Truiden kunnen
perfect hetzelfde huisnummer hebben en dezelfde straatnaam, maar een
verschillende postcode).

Ik heb geprobeerd om ook addr:postcode als tag toe te staan, maar dan werd
de overpass query verschrikkelijk traag (die moest immers alle adressen in
Vlaanderen gaan filteren.

De enige mogelijkheid is dus om die grenzen te tekenen (ook al zijn ze
slechts bij benadering), en dan zal Sint-Truiden meteen heel wat groener
zijn.


Ook in Crab zitten er fouten in de zone nummering, maar er is nog Bpost
 voor de controle, ook voor missende huisnummers. Fouten op zonenummers in
 CRAB gebeuren meestal op straten die een zonegrens overschreiden.

 Ik zit nu terug rustig bezig op de 3582, nog ogeveer 1000 te gaan ;-)

 Sus

 Ik doe nu rustig verder opde 3582

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

Re: [OSM-talk-be] Preference ? : address number as NODE in building/house, or WHOLE building/house with address number ?

[Sander Deryckere]

Our postbox stands about 10m from our house, and about 20m from our main
entrance. Though we only use our main entrance once or twice per week, so
it's hardly our main entrance. And there's no way you can find our entrance
without coming in our front-yard.

So I prefer to add a housenumber to the identifying feature. If a building
has multiple doors, with different housenumbers, then tag the entrances
with the numbers. If a building matches one-to-one with a housenumber, tag
that building with the housenumber. If there are multiple buildings under
one address (for example a school), then tag the outline (the
amenity=school area f.e.) with the housenumber.

Finding a general rule doesn't work, for one company (bPost) the address is
the post box, for another company (package delivery), the address is the
delivery entrance, for people, the address is the front door, ...

So I think you must interpret every case as see it, and find the most
descriptive feature for it. After all, for software, it's easy to extract a
centroid from an area. And it can also be handy when the address is linked
to a physical feature with extra tags.

For example, if you have a commercial building with one address, but a
delivery and a customer entrance, clever routing software could be able to
see that the address is tagged on the building, and that the building way
contains two nodes tagged with entrance=*, so it could ask you which
entrance you want.

And the JOSM problem is just that, a JOSM problem. It's not something the
data users will be annoyed with.

Regards,
Sander

2015-03-17 14:29 GMT+01:00 henkevdb m...@henkevdb.be:

 My preference is mapping a house or building as 'yes', and then place a
 node with the address number and street in the building/house as close
 nearby to the 'main' entrance, because that is usually the place where the
 postbox also is. Or is that wrong ?
 Also, when a building has a 'strange', and often large shape, josm then
 places the address number sometimes in a corner of that shape/building ,
 way of the 'main' entrance.

 ___
 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] Adressen via AGIV Crab

[Sander Deryckere]

Mijn eerste idee is dat er iets fout is met de grenzen. De postcode grens
is nodig om de correcte adressen uit OSM te halen. Als die ontbreekt, of
niet correct is, dan kan overpass geen adressen vinden, waardoor alle
staten dus op 0 blijven staan.

Ik zal morgen eens kijken naar die grenzen, maar het probleem kan nog een
eindje blijven bestaan. Overpass is niet zo snel met het updaten van
gebieden als met het updaten van andere objecten, omdat het wat meer
rekenkracht vraagt om vanuit een OSM relatie een geografisch gebied te
maken. Ik verwacht dat er dus enkele dagen vertraging op kunnen zitten.

Groeten,
Sander
Op 16-mrt.-2015 21:09 schreef Guy Vanvuchelen guy.vanvuche...@gmail.com:

 De laatste maanden maak ik dankbaar gebruik van de mogelijkheid om
 adressen in te brengen. Iemand maakte mij de opmerking dat in Sint-Truiden
 geen enkel adres ingebracht is. Daar wilde ik wel iets aan doen. Dus begon
 ik met de straat met de meeste adressen: de Luikersteenweg. Voor wie die
 straat kent, het was met niet te doen om de ‘uitstalramen’! Nadat ik een
 honderdtal adressen ingebracht had wilde ik bewijzen dat de teller niet
 meer op nul stond…maar er was niets gewijzigd. Dan heb ik enkele straten
 met weinig (of slechts 1 huis) ingebracht maar ook nu blijkt er niets te
 wijzigen. Eigenaardig genoeg kwam ik straten tegen waar slechts één huis
 ontbreekt terwijl er wel 20 huizen ontbreken (Halingenstraat bijvoorbeeld).

 Kan iemand dat verklaren? Sint-Truiden heeft postcode 3800.



 Guy Vanvuchelen



 ___
 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] On Wheels

[Sander Deryckere]

Again in the media: http://onwheelsapp.com (see the VRT news f.e.)

Too bad they seem to use a proprietary dataset to start from. The data is
as such closed, and completely depends on the activity of the current team
around it.

Sigh

(and yes, I did try to contact them some months ago, but never got a reply)
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Maritime boundary

[Sander Deryckere]

Sea-sand isn't really what we need. It's not pure enough, and a lot rounder
than river sand, so less useful for construction.

But this does matter to the economical activities happening there I guess.
Like the ice cream selling boy going over the beach. If the wet beach
wouldn't belong to the region, that could create a whole lot of
administrative problems.

But since I fail to find any good data concerning the water lines (even
tried altitude data), I guess we won't be able to adapt the boundaries for
now.

Regards,
Sander

2015-03-06 12:15 GMT+01:00 Jo winfi...@gmail.com:

 I think it was in EOS that I read, sand is becoming more and more of
 economic value and given the quantities we need even a somewhat scarce
 commodity.

 Jo

 2015-03-06 11:44 GMT+01:00 André Pirard a.pirard.pa...@gmail.com:

  On 2015-03-04 23:05, Sander Deryckere wrote :

 Hi all,

 Just heard Bart Tommelein on De Ideale Wereld this evening, state
 secretary of the north sea (amongst other things). There he said that the
 north sea is a pure federal responsibility, but the beach is a regional
 (thus Flemish) responsibility. However, the boundary isn't the high water
 line (which we tag with natural=coastline), but the official boundary is
 the low water line (I assume it's the average low water line here, though
 it could also be the most extreme low water line).

 I guess, ideally, this should be reflected in our data, where we tag the
 intermediate section as tidal too.

 Now, the only thing we're missing is actual high and low water data :)

 So if anyone knows about open, high position datasets that contains the
 tidal regions, that would be great. Else we might try to split it with
 estimated data.


 Given that unusable wet sand is of little value, the real issue is to
 whom the water and the shrimps would belong.
 Half of the time they would be over regional land and half of the time
 over federal land.

 Cheers

   André.


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



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


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

Re: [OSM-talk-be] Mapping in West-Vlaanderen

[Sander Deryckere]

Heeft iemand concrete voorstellen voor een locatie? Misschien is de nieuwe
bib van Roeselare wel iets: http://www.arhus.be

Wat verbinding betreft zit het goed denk ik. Recht onder de bib is er een
ondergrondse parking (http://osm.org/node/1805179023), en het is ook op
wandelafstand van het station.

Ook wat voorzieningen betreft is het tamelijk goed: er is gratis WiFi (je
hoeft geen lid te zijn van de bib) en je kan een atelier reserveren, wat
een chic woord is voor een glazen kot, waar je wat luider mag overleggen.
In die ateliers zijn ook voldoende stopcontacten, maar jammer genoeg kan je
niet mag eten en enkel water drinken. In de leescafé mag je dan wel weer
eten en drinken, maar daar zijn er dan minder stopcontacten, en dat valt
niet te reserveren.

Het grootste probleem zijn de openingsuren denk ik. De zaterdag is het
altijd vrij druk in Roeselare (dus is er een kans dat de parking vol staat,
en er weinig plaats is in de café), en de zondag is de bib maar 2 uur open.

Als er voorstellen zijn in Brugge of Kortrijk, dat is natuurlijk ook heel
welkom.

Mvg,
Sander

Op 5 maart 2015 11:29 schreef Jakka vdmfrank...@gmail.com:

 Indien nodig klik ik mee.
 Misschien vermelden Wat breng ik mee of niet? kabels .., hoe wordt er
 online gegaan? hoe maak ik eventueel verbinding op verplaatsing?

 Jakka

 Marc Gemis schreef op 5/03/2015 om 11:19:

 als je de tekst doorgeeft, wil ik gerust een paar tientallen keren
 klikken om die aan te schrijven

 mvg

 m

 2015-03-05 10:25 GMT+01:00 Ben Abelshausen
 ben.abelshau...@gmail.com
 mailto:ben.abelshau...@gmail.com:

 Misschien moeten we alle mappers die we kunnen vinden eens
 uitnodigen voor een meetup ergens in WVL? Echt actief iedereen een
 bericht sturen via osm.org http://osm.org?

 Met vriendelijke groeten,
 Best regards,

 Ben Abelshausen

 2015-02-27 11:49 GMT+01:00 Marc Gemis
 marc.ge...@gmail.com
 mailto:marc.ge...@gmail.com:

 volgens
 http://resultmaps.neis-one.org/oooc?zoom=10lat=51.08579;
 lon=3.89178layers=B00TFT
   zijn er ook niet zo heel veel mappers in West-Vlaanderen.

 mvg

 m

 2015-02-27 11:39 GMT+01:00 Jakka vdmfrank...@gmail.com
 mailto:vdmfrank...@gmail.com:

 Ben Abelshausen schreef op 26/02/2015 om 14:55:

 Hallo,

 2015-02-21 10:35 GMT+01:00 Ben Abelshausen
 ben.abelshau...@gmail.com
 mailto:ben.abelshau...@gmail.com
 mailto:ben.abelshausen@gmail.__com
 mailto:ben.abelshau...@gmail.com:

  Laat zeker weten als je dit ziet zitten. Laat je
 niet afschrikken
  voor de workload want dat zal nogal meevallen denk
 ik.


 = écht niemand die dit ziet zitten?

 Met vriendelijke groeten,
 Best regards,

 Ben Abelshausen


 _
 Talk-be mailing list
 Talk-be@openstreetmap.org
 mailto:Talk-be@openstreetmap.org
 https://lists.openstreetmap.__org/listinfo/talk-be

 https://lists.openstreetmap.org/listinfo/talk-be


 @Ben weinig reactie op de vraag.
 - Zijn de West-Vlaamse mappers wel lid van deze list? Andere
 fora?. Persoonlijk vind ik deze list niet zo
 gebruiksvriendelijk om in te zoeken te raadplegen. (mogelijk
 persoonlijk gebrek aan kennis)
 - Nieuw geïnteresseerde komen op OSM via de web editors en
 lopen na enkel mappingen vast, mijn persoonlijk ervaring
 was, hulp zoeken op het net is niet evident, je verdrinkt
 als het ware in de wiki pagina's en termen en je klikt je
 steeds verder weg, van wat je eigenlijk zoekt.
 Heb eens mijn nabije buren opgevraagd. En zit hier dicht bij
 Franse grens dus mogelijk Buitenlanders erbij.
 wijzigingensets van gebruikers in de buurt
 dagboekberichten van gebruikers in de buurt

 pinguin_8123 (1 km verwijderd)  (geen bewerkingen)
 colnagoboys (3 km verwijderd)   (geen bewerkingen)
 jorisvdc (3 km verwijderd)  (geen bewerkingen)
 coyke (3 km verwijderd) (geen bewerkingen)
 rafel1810 (4 km verwijderd) (geen bewerkingen)
 bekvh (4 km verwijderd) (geen bewerkingen)
 Garlaban (5 km verwijderd)  (geen bewerkingen)
 Aäron Catteeuw (5 km verwijderd)(geen bewerkingen)
 on4dfc (5 km verwijderd)(geen bewerkingen)
 Chris DW (6 km verwijderd)  (geen bewerkingen)
 Butchamon (6 km verwijderd) (geen bewerkingen)
 bridgemen (6 km verwijderd) (geen bewerkingen)
 jeanclaude1946 (4 km verwijderd)Laatste 

[OSM-talk-be] Maritime boundary

[Sander Deryckere]

Hi all,

Just heard Bart Tommelein on De Ideale Wereld this evening, state secretary
of the north sea (amongst other things). There he said that the north sea
is a pure federal responsibility, but the beach is a regional (thus
Flemish) responsibility. However, the boundary isn't the high water line
(which we tag with natural=coastline), but the official boundary is the low
water line (I assume it's the average low water line here, though it could
also be the most extreme low water line).

I guess, ideally, this should be reflected in our data, where we tag the
intermediate section as tidal too.

Now, the only thing we're missing is actual high and low water data :)

So if anyone knows about open, high position datasets that contains the
tidal regions, that would be great. Else we might try to split it with
estimated data.

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

Re: [OSM-talk-be] Mogelijkheid om een SIMPELE 'button' of zoiets in josm te verkrijgen , om fouten door te seinen naar AGIV ?

[Sander Deryckere]

@henke: wat heb je gedaan? Bij mijn weten was die grens correct zoals ik ze
ingebracht heb (hoewel lodde die blijkbaar ondertussen ook al eens
aangeraakt heeft).

De eigenlijke grens van Bosstraat en Waterstraat hangt samen met de
gemeentegrens. Er is namelijk geen Waterstraat in gemeente Staden.

Op 28 februari 2015 18:51 schreef henke m...@henkevdb.be:

 Hallo Sander, ik heb je links es bekeken, en de Waterstraat iets verder ,
 juist op de grens gezet, en ik zag ook dat de 'eigenlijke grens' van
 Bosstraat/Waterstraat aan huisnummer 3 begint, zie hier :
 https://smartshare.be/public.php?service=filest=
 1b5d13bfd185299969767687d6303299
 doch dat laat ik aan anderen over om te veranderen ;)


 ___
 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] Mogelijkheid om een SIMPELE 'button' of zoiets in josm te verkrijgen , om fouten door te seinen naar AGIV ?

[Sander Deryckere]

Ik denk dat je het hebt over fouten in de adressen (CRAB)?

In dat geval zou je moeten weten, als je de documentatie volledig hebt
gelezen, dat je die moet rapporteren aan de gemeentes via Lara, niet
rechtstreeks aan Agiv. Helaas kan ik daar geen link voor maken, aangezien
je eerst door een login scherm moet vooraleer je bij de kaart terecht komt.

Het is idd wat werk per aangifte, maar het is dan ook de bedoeling dat de
aangiftes weloverwogen en kwaliteitsvol zijn.

Groeten,
Sander

2015-02-28 2:16 GMT+01:00 André Pirard a.pirard.pa...@gmail.com:

  On 2015-02-28 00:28, Glenn Plas wrote :

 Zie
 http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data/Reporting_errors_to_AGIV
 https://crab.agiv.be/Lara/Home/Index2

 Lara heet het.  Simpel is het niet bij veel fouten.

 Glenn

  Anything semblable voor SPW? ;-)

 There is a JOSM ExtTools plugin
 http://wiki.openstreetmap.org/wiki/JOSM/Plugins/ExtToolsthat allows a
 script (1) to be written, configured and invoked.
 The script is passed the coordinates of the clicked point.
 If that's all that's needed to make an AGIV report, the script could send
 an e-mail to contactp...@agiv.be.
 (plus standard and script prompted text, of course). I suppose it should
 be rather straightforward.
 The script is supposed to return a .osm file to update the current layer
 but I imagine that it can send an e-mail instead.  JS example
 https://gist.github.com/goldfndr/5719417.  VBS example
 https://gist.github.com/goldfndr/5719016.
 Also Scripting Plugin
 http://josm.openstreetmap.de/wiki/Help/Plugin/Scripting, but apparently
 less adequate.

 And what about reporting roadsign errors or such things to MET (Transport
 Ministry)?
 I spotted a missing 30 km/h zone sign in Esneux.
 I posted every MET e-mail address I could find without an answer.
 I wrote to the SPW help desk, asking for a MET alert address and she
 replied there is none.
 The sign stayed missing for 6 month until they planted a temporary one.
 And exceeding speed limit is a highest severity offense!
 And now it's the opposite end of zone sign that's broken down.
 In compensation, maybe?

 Cheers

   André.
 (1) program usually written in one of the many interpreted languages that
 are readily available in Unix

  On 27-02-15 22:52, hvdb wrote:

  Als je een fout vind, kan je contact opnemen met :

 AGIV-contactpunt.

 T 09 276 15 00 | F 09 276 15 05 | 
 contactp...@agiv.bemailto:contactp...@agiv.be contactp...@agiv.be | 
 www.agiv.be http://www.agiv.be http://www.agiv.be
 Het AGIV contactpunt is bereikbaar op weekdagen van 8u00 tot 17u00.

 doch, als je 'ettelijke' fouten vind, is het wel 'vermoeiend' om telkens
 een hele 'rimram' te moeten gaan mailen of telefoneren naar AGIV. Daarom
 zou het meer 'comfortabeler' zijn, als er een soort 'button' of zoiets,
 dat, wanneer je daar dan op klikt, je ergens direkt een 'link' kan geven
 met de coordinaten ofzoiets , waar de fout zit, en dan wat uitleg ...




 ___
 Talk-be mailing 
 listTalk-be@openstreetmap.orghttps://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] Mogelijkheid om een SIMPELE 'button' of zoiets in josm te verkrijgen , om fouten door te seinen naar AGIV ?

[Sander Deryckere]

@André, I replied to the original post, not to you.

@henke: de gemeentes zijn verantwoordelijk voor de naamgeving van de
straten, niet Agiv. Als een straat op een grens ligt, dan kan die straat 2
totaal verschillende namen krijgen, of 2 namen die enkel in spelling
verschillen. Als een straat een gemeentegrens oversteekt, dan kan de
spelling ook veranderen (zie http://osm.org/#map=19/50.95714/3.08237 ).

Voor een voor een straat die op een grens ligt met 2 totaal verschillende
namen, zet je best een combinatie van de namen in de name tag, en dan
gebruik je ook name:left en name:right om aan te duiden dat de
verschillende zijden een andere naam krijgen. Zie deze weg als voorbeeld:
http://osm.org/way/311932083 . Dit is vergelijkbaar met wat we in Brussel
doen voor Nederlandse en Franse namen.

Voor een grensstraat met een spellingsverschil of ander klein verschil, dan
is het IMO beter om voor 1 spelling te kiezen, maar ook de name:left en
name:right tags met verschillende spelling te gebruiken. Zie
http://osm.org/way/42942798 als voorbeeld.

Deze zaken gebeuren voor bijna iedere gemeente. Dus moeten de tools er
gewoon mee leren werken. OsmAnd kan er mee werken, Nominatim niet, da's
spijtig. Als je de namen echt wil wijzigen voor die gemeentes, dan moet je
de gemeentebesturen zelf aanschrijven. Deze kunnen dan kiezen om een
naamsveranderingsprocedure in gang te zetten (waarbij er in de gemeenteraad
moet gestemd worden), en daarna kunnen dan alle bewoners hun adressen laten
aanpassen bij diverse instanties (bij hun telecom operator, hun
electriciteit/gas leverancier, ...). Een straatnaam wijzigen is dus heel
wat werk, en meestal doen de gemeentes dat niet.

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

Re: [OSM-talk-be] Viewing recent notes on OSM.org

[Sander Deryckere]

Hi Jakka,

I don't think you should care for regions you don't know very well. It's
better to let the locals handle it.

But as a reply to your question, there's an API build that allows you to
download a number of notes:
https://wiki.openstreetmap.org/wiki/API_v0.6#Map_Notes_API

However, no parameter is included to select on opening date, so you should
download all and sort them locally. Some JOSM devs are developing a note
reading plugin, maybe that plugin will allow to filter in some way.

Regards,
Sander

2015-02-27 17:52 GMT+01:00 Jakka vdmfrank...@gmail.com:

 Hi,
 How can I receive or view, open de recent notes from this map ?
 Immediately or after day XX Now I must control them one by one over en over
 again. Some notes are there longer then 6 months
 https://www.openstreetmap.org/#map=10/50.9039/4.5305layers=N

 Jakka


 ___
 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] city names - bug in OFM?

[Sander Deryckere]

Some of them are digitised, some aren't.

You can go to
http://www.kbr.be/collections/cart_plan/collections/collections_nl.html
then under Kadastrale plannen, click on one of the provinces (For Luik,
click on a different, random province, for Luxembourg, there are no maps
sadly).

This opens the search website which gives you no results (but at least
brings you to the right page). On that page, go to Cartes et plans =
Kaarten en plannen, and this time, click on the correct province. Then you
see a list of municipalities (from the 19th century, with old spelling),
sorted by arrondissement.

Then you can open the scan reader by clicking on the image (not the title).
You'll see that the map gets a copyright mark, this means that the map as
image is protected. However, the data you can deduce from the map isn't
altered since the creation of it (it isn't rectified nor georeferenced), so
it's usable for OSM.

As there's no export option, the easiest way to use it is to zoom in to
certain parts, and make screenshots. I normally made 4 screenshots for a
normal village, with a bit of overlap. However, the maps may be so skewed
that you need to adapt the reference points depending on the part of
boundary you're drawing.

Note that not all villages are present. Sometimes you're lucky that all
surrounding villages of a certain village are present, then you also have
the boundaries. Other times, it might take guesswork, or using even worse
(older) maps.

Regards,
Sander

2015-02-25 14:12 GMT+01:00 Marc Gemis marc.ge...@gmail.com:


 On Tue, Feb 24, 2015 at 4:44 PM, Sander Deryckere sander...@gmail.com
 wrote:

 In short, I used out-of-copyright Popp maps from the royal library


 As a complete noob on this topic, where can I get them (going to the
 library ? or are they already on-line somewhere ?)

 regards

 m

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


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