Re: [OSM-talk-be] Status GRB-import tool ?

[Glenn Plas]

Goeie suggesties ivm discardable tags.

De fout zal zeker niet in JOSM zitten, die tags worden geexporteerd. 
Het is een kwestie van :  wil je ze zien of niet bij export ?

De status gegeven door Marc is de juiste, idd aan het kijken hoe we het
gebouwenregister als enige adres referentie kunnen nemen zonder het
verliezen van de link naar GRB objecten, daar zit de moeilijkheid erin

Glenn

On 24-01-19 20:37, Marc Gemis wrote:
> dat is inderdaad een van de workarounds, maar voor de een of andere
> reden bleef JOSM bij mij toch nog die tags doorsturen. Ik zal wel iets
> verkeerd gedaan hebben.
>
> m.
>
> On Thu, Jan 24, 2019 at 8:33 PM Jo  wrote:
>> Ik voel me ook niet geroepen om die rol op me te nemen, maar ik heb wel een 
>> suggestie voor tags die niet mogen worden doorgestuurd.
>>
>> JOSM heeft daar ondersteuning voor.
>>
>> Wat ik gewoonlijk doe is zulke tags created_by of odbl noemen, aangezien die 
>> al in de lijst staan.
>>
>> De andere mogelijkheid is een key (tags.discardable) in de instellingen 
>> aanpassen en dan worden ze vanzelf weggegooid voordat er data naar de server 
>> gaat.
>>
>> mvg,
>>
>> Jo
>>
>>
>> On Thu, Jan 24, 2019 at 8:13 PM Marc Gemis  wrote:
>>> Hallo Denis,
>>>
>>> Ik had gehoopt dat iemand die dichter betrokken is bij de ontwikkeling
>>> tijd zou hebben om je te beantwoorden, maar ze hebben het misschien te
>>> druk momenteel.
>>> Ik zal dan maar proberen te de situatie te schetsen:
>>>
>>> - de import mailing list had niet echt bezwaren, dus die hindernis is 
>>> genomen
>>> - de documentatie is volgens mij zo goed als af. De laatste beetjes
>>> zouden tijdens een soort van kick-off meeting kunnen aangevuld worden
>>> - de tool heeft nog 2 problem (voor zover ik weet)
>>> * er komen nog extra tags mee die je niet mag uploaden. Daar bestaat
>>> wel een eenvoudige workaround voor.
>>> * niet alle adressen zijn correct. Vooral bij appartementsgebouwen met
>>> meerdere huisnummers, zou het beter kunnen. Stel je hebt een gebouw
>>> met 3 ingangen en huisnummers 15, 16 en 17.
>>> Nu zal je 3 gebouwen met nummer 15-17 krijgen. Er is een mogelijkheid
>>> om dit te verbeteren door een extra databank te laden in de tool. Dit
>>> vraagt natuurlijk ontwikkelingstijd.
>>>
>>> Ik begrijp Glenn wel dat die wijziging echt noodzakelijk is voordat de
>>> tool beschikbaar kan gemaakt worden. Als iemand die altijd klaagt over
>>> foutieve data van externe bronnen, juich ik dat alleen maar toe.
>>>
>>> Ik weet echter niet of het enkel aan ons is om daarover te beslissen.
>>>
>>> Momenteel werkt ook Lodde1949 rustig verder aan het intekenen van
>>> gebouwen adhv de GRB achtergrond en met de oude adres import tool. Dus
>>> in een groot deel van de provincie Antwerpen is de tool al niet meer
>>> zo relevant.
>>>
>>> Misschien moet er gewoon iemand een datum prikken, een zaal met
>>> internet verbinding voorzien, iemand uitnodigen die de nodige
>>> toelichtingen kan geven en de "import" officieel starten.
>>> Het is duidelijk dat iemand de "projectleiderrol" op zich zal moeten
>>> nemen om alles naast de ontwikkeling van de tool te organiseren en
>>> daar dan ook voldoende tijd in stoppen.
>>>
>>> mvg
>>>
>>> m.
>>>
>>> p.s. Ik wil hier niemand met de vinger wijzen, we zijn allemaal
>>> vrijwillers met beperkte tijd. Ikzelf heb ook geen tijd noch interesse
>>> om deze rol op te nemen.
>>>
>>> On Sun, Jan 20, 2019 at 6:02 PM Denis Verheyden  wrote:
 Dag iedereen,

 Graag wou ik nog eens polsen wat de status is van de GRB-import tool. 
 Ergens in 2017 is de publieke versie uitgezet omdat veel mensen hiermee 
 onbedoelde of verkeerde wijzigingen hebben gedaan.

 Voor mij is deze tool echter het middel waarop ik wacht om nieuwe of 
 aangepaste gebouwen toe te voegen/wijzigen in OSM. Het heeft geen zin nu 
 gebouwen te tracen als we ze later opnieuw moeten vervangen door de 
 "officiële" geometrie van A(G)IV. Tot dan beperk ik mij enkel tot 
 toevoegen van nodes of features niet gerelateerd aan gebouwen.

 Groeten,
 Denis
 ___
 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] Crab Addr import tool

[Glenn Plas]

On 23-04-18 13:29, Sus Verhoeven wrote:
> Ik gebruik altijd de laatste versie van JOSM, nu 13576.
> Ik ben wel een tijdje inactief geweest.

Verklaart het idd, ook waarom ik het ook voorheb, ik gebruik ook steeds
de laatste versie en kon het probleem reproduceren.

Morgen doe ik een nieuwe data run van de address gegevens.

Glenn


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

Re: [OSM-talk-be] Crab Addr import tool [solved]

[Glenn Plas]

Hi Sus,

(EN below)
 
Ik heb het in orde gebracht. in de XML kan je definieren dat de export
niet geupload mag worden, daar stond 'upload=no' ipv 'upload=false' en
er is recentelijk 'never' bijgekomen, sindsdien geeft JOSM een fout op
die 'no' , voordien werkte dat gewoon, nu niet meer.

De HTTPS versie van aptum werkt niet goed in combinatie met JOSM voor
een resem technische redenen (+ lokale aanpassingen aan JOSM settings) ,
dus de enige echte die zeker moet werken voor iedereen is :

http://crab-import.osm.be

Bedankt voor de melding .


---

I resolved the problem with exporting data, in the XML that is being
exported we define a field called 'upload' and used to give it a value
of 'no'.  So upload=no , which stopped working after another option got
introduced : upload=never.  Since then the latest releases of JOSM
started giving errors when you use upload=no as it should have been
upload=false instead officially.

the HTTPS version of the crab-import tool will not work, due to a number
of technical reasons (+ local setting changes), so the one and only link
that should definitely work is the non-https one.

http://crab-import.osm.be

Thanks for the headsup,

Glenn




On 23-04-18 10:54, Sus Verhoeven wrote:
> Het lukt mij niet meer de Crab gegevens in te laden in JOSM, enkel de
> straatgegevens van OSM worden nog ingeleladen als ik op een straatnaam
> klik. De gegevens zijn wel bijgewerkt tot 2018-03-26 .
> Ik gebruik http://aptum.bitless.be/
> Is er iets mis of doe ik iets mis ?
>
> 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

Re: [OSM-talk-be] Crab Addr import tool

[Glenn Plas]

You need to use http://crab-import.osm.be/  or https://crab-import.osm.be/

Ik kan bevestigen dat er een probleem is bij het exporteren , blijkbaar
aanvaard JOSM de web request niet meer (JOSM heeft een interne webserver)

Kan je uw JOSM versie eens doorgeven aub ?  Heb je recentelijk een
upgrade gedaan ?

Glenn


On 23-04-18 10:54, Sus Verhoeven wrote:
> Het lukt mij niet meer de Crab gegevens in te laden in JOSM, enkel de
> straatgegevens van OSM worden nog ingeleladen als ik op een straatnaam
> klik. De gegevens zijn wel bijgewerkt tot 2018-03-26 .
> Ik gebruik http://aptum.bitless.be/
> Is er iets mis of doe ik iets mis ?
>
> 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

Re: [OSM-talk-be] PICC, CRAB & Data updates questions

[Glenn Plas]

On 05-04-18 16:22, Divoy John wrote:
>
> Everyone,
>
>  
>
> Before using openStreetMap data, I have a few questions about data
> updates and the PICC and CRAB data that are in use
> (https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Using_AGIV_Crab_data).
>
>
>  
>
> Can someone specify me the frequency of the updates of the CRAB & PICC
> data as well as the updates of the maps for Belgium (Brussels,
> Flandres & Wallonia) ?
>
> How are these updates made and what are the accuracy checks done ?
>
> Additionally, can someone tell me when PICC & CRAB data was updated
> for the last time ?
>
>  
>
> Thanks a lot for your help !
>
>  
>
> Best regards,
>
>  
>
> John
>

Hi John,

I can answer the CRAB section for you.

It's not clear to me if you are asking about the integration of this
data within OSM,  or if you are just asking about the source data
updates individually?

CRAB is continuously updated.  ( see
https://download.agiv.be/Producten/Detail?id=447=CRAB_Adressenlijst )
OSM is also continuously updated, every edit made is immediately applied
after upload and from there on trickles down in depending services like
the map (ex: tile generation) and geocoding (ex: nominatim)

We have a set of tools that allow us to validate OSM addresses against
crab counterparts which can be used to update OSM or sometimes to mark
errors in CRAB as OSM.   The Map for Belgium is just part of the world
map , however there is a Belgian tile server that uses a modified style
with multilanguage support.   For commercial use you need to consult
with those service providers if you want to use them.

The frequency of updates from CRAB to OSM totally depends on the total
effort of all mappers involved and what they are working on.   You can
also do this yourself as a contributor in your areas of interest.

Greetings,

Glenn


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

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

[Glenn Plas]

On 04-04-18 11:23, eMerzh wrote:
> Thanks for your responses :)
> and yeah i totally agree that an import is probably not a good idea,
> but i was thinking more like a map  of missings schools or streets
> without surface  (with one in the dataset)
> and with ideally a "one-click" import ( 1 feature by 1 feature)

The datasets are fine in a  'supporting' role, like the cases you
mention above.   If I take the school case , it's do-able to take all
schools out from OSM, put them in a postGIS table and then do the same
with Urbis data , you can then throw postGIS functions on those 2 to
extract a diff.  You need some common ground and postGIS is perfect for
that.   Since BXL dataset is quite small compaired to GRB, that work
will be fast.   If I want to reprocess the GRB data the way it's
processed now, we are talking about 6 hours of crunching, and if
something isn't quite right you need to start over.

In any case, you probably need to verify every school to see if it still
exists.  There are quite a few schools in Brussels according to OSM :
http://overpass-turbo.eu/s/xzj


Glenn

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

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

[Glenn Plas]

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

hi,

Concerning the 3D buildings and Street surfaces, I know for sure that
this is data coming from Urbis which is a high quality dataset but even
that doesn't justify importing it into OSM without human review.

I've been considering to include the Urbis dataset in my tool but I have
to keep the focus on GRB, once that is launched I will point my
attention to Urbis data.  The tool basically does what you state, it
imports it into postgis and makes it easy to export into JOSM directly
and translated to OSM model as good as I/IT can.  The urbis source data
model will work quite well with my transform procedure and tools

Not all the data there is GIS oriented either.  But a lot is scatttered
around, for example, on the parking subject we are dealing with 12
different datasets, there are sets who represent the access to the
parkings , which in OSM would be a simple access tag on another set. 
Here you will have to combine the parking sets and do process the data ,
do the Q/A , handle the exceptions etc.  You cannot consider this job
easy and straightforward, it's going to be painful instead.

Also, the more I look at the data, the more errors and problems I see, 
I've been working with GRB data for a long time and only last week I
contacted Marc to verify if he also noticed that there seems to be an
"addressing" problem in the transformed data where housenumbers seem to
be messed up in certain cases, and he confirmed this.  And that is a
"new" problem, aka: something which slipped my attention for a good year
now...  I traced this down to the .dbf data files containing the address
data, so it's a source problem we need to mitigate. (it's not
impossible, it's just more work)

That's just to say, preparing this data is so much work, I've been
working on that part alone -daily- for the last 3 months.   It all
starts with quality.  I've been using GRB 3D data set as an aid to
determine building types, that is about as far as I want to go for
several reasons.  the GRB set (non 3D) is a lot better maintained than
3D grb, which kinda looks like an experiment (that went quite well)

That is also the big issue I have with all the imports in the wild
without data analysis, scrutiny and Q/A work.  We do notice people are
just importing the shape files straight into OSM without understanding
the problems related to this.  Antwerp for example is huge mistake
happening,  Antwerp used to be quite empty on buildings but now it looks
like it's just a flat import of GRB shapefile data (1)

Also Yves has done his homework on VILLO and STIB data, I've seen what
he had to deal with those datasets, I totally agree with his conclusion
that this isn't just a simple: "hey it's gis data, that's good enough" 
and that bulk imports like the one that fucked up Antwerp (but makes it
look good on the map) should be avoided.

I work at CIBG/CIRB so I can determine the source of certain datasets if
required and talk to people here to get to know where they are coming
from (not all datasets are from government sources, a lot are from
customers of CIBG/CIRB )

In short, I would be careful and not import in bulk, the schools you
could probably merge/verify with OSM in a few days manually.  I would
choose the latter.  There is more time spent on automating than you(and
definitely me too)  would think at first glance.

Glenn



[1]   Diff tool : 
http://tiles.grbosm.site/slide/app/index.html#15/51.2091/4.4226



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

Re: [OSM-talk-be] Where to suggest/discuss the renderer?

[Glenn Plas]

Mapping for the renderer is de facto wrong and what you experience now
(in france etc.) is the endresult of that attitude.  I don't understand
why you get discouraged on OSM because of a map you don't like.   It's
like saying:  "I don't contribute to Wikipedia anymore because when I
print a page out, it's not aligned the way I want it."

There are several options for anyone in your situation:

1. make your own map.  There are several sites that allow you to make
custom maps.
2. more technical: copy cartoCSS, change whatever you want, set up a
tile server and enjoy your perfectly suited map
3. try to change the consensus, lobby for universal solution, try to get
the standard cartoCSS changed to your likings (and repeat later when
someone else does the same)
4. Look for existing map alternatives  (different renderings)

You should realise that it has nothing to do with the source data. 
There are already ton's of different map rendering out there, perhaps
one will be perfect for you.

Don't stop mapping because of someone elses decision to represent a
feature in a way that doesn't appeal to you.  It's the worst reason to
stop as that might just change in an instant.

Glenn


On 19-01-18 16:43, Karel Adams wrote:
> When I first consulted maps - paper-only, at that time, of course -
> the famous Michelin 1:20 had distinct symbols for (bigger)
> airports, (smaller) airfields, and glider fields. As of 2018, the
> generic map of openstreetmap has only a single icon to represent
> anything mapped with "aeroway:aerodrome" - and all of them rendered as
> from zoomlevel=13 - and none below.
>
> This is really very bad. Why should I want to contribute to a system
> that delivers poorer info than paper maps of 50 years old?
>
> Even worse, many active and able mappers are reluctant to update the
> database properly because the correct info will be so poorly rendered.
> Especially in France and Italy, where I had endless arguments with
> people removing the "aeroway=aerodrome" tag from real proper
> aerodromes, because they didn't want their local grass runway mapped
> the same as CDG Roissy airport. Even if I don't agree, I can fully
> understand their point of view!
>
> What is the proper place to question this matter, and discuss schemes
> of improvement? Is there a discussion site for the renderer?
>
>
>
>
> ___
> 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] Overpass turbo exporteren as png

[Glenn Plas]

It works now.  Tested on chrome Version 62.0.3202.94 (Official Build)
(64-bit)

Glenn


On 27-01-18 11:23, Jakka wrote:
> Hi,
>
> Trying to export a query map in png do not work.
>
>
>     rendering map data      rendering map tiles
>     prepare map
>
>
> Is this a known issue ?
>
>
> ___
> 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] CRAB tool data update - 2018-01-02

[Glenn Plas]

Hallo

In de reeks maandelijkse CRAB updates: Nieuwe CRAB data is processed en
staat reeds ter beschikking hier:

http://crab-import.osm.be

Zoals steeds verdwijnen er straten, maar komen er nog meer bij.  Deze straten 
verdienen vaak onze extra aandacht omwille van het feit dat ze vaak over een 
nieuwe verkaveling gaan waarbij niet alle addressen reeds in kaart zijn 
gebracht.  

Kijk altijd even de lijst na van nieuwe ( http://crab-import.osm.be/new.txt )  
en gewiste straten ( http://crab-import.osm.be/deleted.txt )


Glenn



Hello

In the series: CRAB updates

New CRAB data has been processed and is at your service using the
following url : http://crab-import.osm.be

As always streets come and go, usually there are more being created than 
deleted.  These streets often require our special attention as they might not 
be totally correct/complete yet due to the fact that it's often about locations 
with new development and ongoing constructing works.  It's possible that this 
data is not matching reality yet due to this.  Make sure you always check the 
list of new ( http://crab-import.osm.be/new.txt ) and deleted streets. 
( http://crab-import.osm.be/deleted.txt )


Glenn


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

Re: [OSM-talk-be] OSM and SIAMU

[Glenn Plas]

Hi Ben,

I'm really missing something in the logic, but how can 2 seperate
datasets get common ground on this ?  aka: how does it work that this
single ID would be generated identically for 2 different datasets, given
the fact that coordinates are not exactly 100% the same.  I don't see
that connection with openLR.  Would love to know this.

tx,

Glenn

On 23-11-17 20:21, Ben Abelshausen wrote:
> I think this problem can be solved with OpenLR, or at least to a level
> of acceptable quality comparable to mapping the ID's in OSM. I'm
> willing to help out with that, how that would work for examples for
> brussels:
>
> OpenLR, encodes a location on a network in a kind of ID like this:
>
> KwMXmiQm5xt0Af+x/79bBGY=
>
> This decodes into a segment like this:
>
> http://openlr.itinero.tech/?code=KwMXmiQm5xt0Af+x/79bBGY=
>
> In your internal database you keep the code above, and link the
> streetname to that segment, the segment always decodes no matter who
> updates the map or the ID's of the OSM ways. As long as the road still
> exists the code will work. It's a perfect way to associate data to a
> road network for cars (or in this case firetrucks) without having a
> dependency on the network ID's or mapped ID's on the network.
>
> Other examples:
>
> http://openlr.itinero.tech/?code=KwMXuCQnBSOKAQB6/76jGoQ=
> http://openlr.itinero.tech/?code=KwMaESQmxiOVBP9E/zOjBaw=
> http://openlr.itinero.tech/?code=KwMZgSQmHSOaBP+mANRjEUQ=
>
> Generating codes can be done by just clicking on the map if you want
> to generate your own.
>
> All this software is open-source and can be setup locally.
>
> Met vriendelijke groeten,
> Best regards,
>
> Ben Abelshausen
>

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

Re: [OSM-talk-be] Mijlpalen

[Glenn Plas]

http://data.gov.be/en/node/11125

KM palen zijn reeds open dus.  licentie: 
https://metadata.geopunt.be/zoekdienst/apps/tabsearch/?uuid=fa453d09-d577-4f5a-ad6c-04f938b757c4

Glenn


On 18-11-17 19:14, Philippe Casteleyn wrote:
>
> Naast geodetische punten ben ik ook wel geïnteresseerd in mijlpalen
> (onze Vlaamse groene hectometerpaaltjes) .
>
> Zou er geen relatie moeten zijn om te weten bij welke weg een paaltje
> hoort ?
>
> En de precisie van de plaatsing ?
>
> We zullen ooit de Vlaamse mijlpalen als Open Data krijgen.
>
> Vooreerst zal ik ze (niet over heel Vlaanderen, ik laat ook wat voor
> een ander) degelijk photographeren.
>
>
>
> 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] Urgent: New mapper added wrong tags.

[Glenn Plas]

I fixed this edit in bulk with overpass, with what I think is the best
possible solution, if you don't know back/forward. just use distance,
it's actually also much more common to use the latter.

Glenn

On 18-11-17 18:13, marc marc wrote:
> maybe start to request him to not add this a fake name :)
> nor a tourism=information
>
> I found nothing better than highway=milestone (maybe ppl should make a 
> request for comment on tagging mailing)
> Is the distance the same on both direction ?
> if yes distance=number is enought.
> If not, distance:forward/backward can be used.
> I also think for inscription before reading the wiki
>


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

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

[Glenn Plas]

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

Sounds like an interesting challenge.  I've done a similar thing with
Velo in Antwerp, their JSON was in better shape however and also
includes capacity (calculated from data) .  I used it to correct and
append the existing data. I would however caution you that this data
still contained errors, the locations where sometimes wrong and also the
spelling of some stations had typo's , so was incorrect.

The one thing that is wrong in your suggestion is to tag it with
housenumbers that belong to the buildings in front of it.  It's wrong
for several reasons, addr:housenumber is an exact address, not an
indicator of an area and cannot be used as such.  Also, you will create
duplicate housenumbers which except for a few circumstances are an
error.  It would be misuse of this key.   It is also not needed as
geographically , we can determine the closest address using geometric
functions , aka math.  That is a lot easier to maintain, when the
numbers change or get expanded, this will be taken into account
automatically.  And lastly... ironically... it's not a house and the key
is called addr:housenumber for a reason.

In that sense, I believe the entire addressing is actually overkill,  it
can be deducted from the data around it, and it will be done like that
too by tools that do this.

For test, I ran my velo Q/A program again on the data in Antwerp and I
see new discrepancies , I'm taking 2 random ones (it's giving me lots of
warnings):

...
[] - Parsing features ref '223'
[] - Found OSM information tags count: 5
[scan_node] - Matching tag data to OSM..
[scan_node] - Matching velo name to OSM name..
[scan_node] - Ref + name matches. 'Red Star Line' - '223- Red Star Line'
[scan_node] - Matching velo capacity to OSM capacity..
[scan_node] - Equal capacity.  OK:  22+13=35
[scan_node] - Matching lat to OSM lat.. 
[scan_node] - Different lat. '51.2333883' - '51.2333460'
[scan_node] - Matching lon to OSM lon.. 
[scan_node] - Different lon. '4.4030503' - '4.4031140'
[scan_node] - Calculating distance .. 6 meters apart
[scan_node] - Filtering lat/lon changes

[] - Parsing features ref '224'
[] - Found OSM information tags count: 5
[scan_node] - Matching tag data to OSM..
[scan_node] - Matching velo name to OSM name..
[scan_node] - Different name. 'Indiëstraat' - '224- Indiestraat'
[scan_node] - Try fuzzy matching to OSM name..
[scan_node] - Different fuzzy name. 'Indiëstraat' - '224- Indiestraat'
...

Looks like we already have a wrong spelled streetname in the data for 224

for 223, there is a 6 meter offset in the data.   It took me some time
to find the exact place in mapillary,
https://www.mapillary.com/app/?lat=51.2336468694=4.40295866677=17=photo=WNkCQiefgXsWelO-XTmWGA

6 meters might sound ok, but there is more going on here.  First of all,
that road has recently been reworked.  When I check where the node is
placed right now, it's on the opposite of the place where it really is. 
It's in front of the Red Star Line building, not across the road.    I
doublechecked the velo data manually and theirs seems to be placed
correctly.

I've also seen the opposite, OSM being totally correct on the location
and Velo just missing the ball by 25 meters... their own stations.  the
lesson I learned here was :  Never blindly trust data until verified,
Never just import without thinking about Q/A.  Never assume data is
accurate until tested.  Big lessons sometimes ( You probably recall my
URBIS Q/A efforts where I thought to have received a correct streetlist
of Brussels, written correctly -I assumed- only to find out it wasn't. 
I stopped using my Q/A program there, If I get a correct streetlist one
day I could start using it again, until then, nothing I can do.)

So back to Villo, like Velo in Antwerp, they combine  ref + name as the
name of the stations,  Velo does this to and we need to split this using
the name and the ref keys, I think you split it correctly in your
suggestion ,that would be consistent with other bike rentals.   If you
really want to include the extra information about the location, I would
suggest using the 'description' tag.

One issue you bring up I do frown upon:  you are worried nodes are going
to be put in the middle of the street ?   If that is the case , the
source data just sucks and we should not use it.  OSM can do better here
and we should not bring in mediocre data.

I could probably adapt my Velo Q/A tool to work with Villo, but I just
noticed that by changing their JSON, they broke my tool, I'll fix that
first.

Hope sharing my previous experience on this matter will help you make
the best decisions.  If you want to know more, let me know.

Glenn



___
Talk-be mailing list
Talk-be@openstreetmap.org

Re: [OSM-talk-be] LiDAR

[Glenn Plas]

Do you have more information on that algorithm (I assume this is what
you mean by special pattern) ?

Quite interested in trying to get this from elevation data.

Glenn

> An interesting thing about raw lidar data is that it can help identify
> trees, as they have a special kind of pattern in the data. So you
> could use processed data to identify potentially missing
> landuse=forest / tree rows / trees.
>
> -- 
> 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

Re: [OSM-talk-be] building = staketsel

[Glenn Plas]

It's indeed due to a bad import job.   Partly the data is probably to
blame as well , since it comes from building DB it's marked as a
building but in OSM it should be turned into man_made=*

Whenever you find dutch in the values of a building or man_made key,
chances are very high that they come from GRB dataset.

It used to be translated automatically but I haven't finished this
yet.   Translations can be suggested directly in the source code of the
script to build the DB (full auto)

https://github.com/gplv2/grb-postgis

You can add directly in the form of a sed search/replace (done before
import, has to be quite unique to work, but very fast).   Or a postgres
query in 
https://github.com/gplv2/grb-postgis/blob/master/helpers/process_source.sh
(done after import)  Or in the form of a carto-css mapping (done during
import)

Some source keys will cause multiple OSM keys to be created.

Glenn


On 18-10-17 13:16, Marc Gemis wrote:
> A man_made=pier should be rendered on the default style, see
> e.g. http://www.openstreetmap.org/way/22909776#map=18/51.08352/4.36580
> Adding building is wrong. I don't know whether a pier mapped as an
> area will show up though. Perhaps one could add area=yes.
>
> Can you include a link to the Pier in Zuidlede ?
>
> m.
>
> On Wed, Oct 18, 2017 at 10:04 AM, Pieter Brusselman
>  > wrote:
>
> Hi,
>
> Some time ago I mapped some 'man_made = pier' on the Zuidlede. 
> Those items don't show up on the map.  Perhaps due to the
> rendering_style.
>
> I was looking for some examples and i found:
> http://www.openstreetmap.org/relation/7340858#map=18/51.0/3.73357
> . 
> Here, the pier/staketsel is mapped as a 'building'.  I don't think
> this is realy a building :-).
>
> According to http://wiki.openstreetmap.org/wiki/Marine_navigation
>  it should
> be 'Piers  against which boats
> can be moored should be tagged as (man_made
> =pier
> ) together
> with mooring
> =yes/ferry/etc. '
>
>
> -- 
>
> Pieter Brusselman
> /Cartografie ~ Projectmedewerker/
>
> (logo boompja) 
>
> *A* Kasteellaan 349 A, 9000 Gent
> *T* 09 / 331 59 27
> *W *www.tragewegen.be 
>
> logo facebook 
>
> ter info: ik werk niet op vrijdag
>
>
> ___
> 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] How we deal with this kind of note

[Glenn Plas]

On 05-10-17 11:10, Marc Gemis wrote:
> Does a tourist information sign indicates any access rights ? Is the
> fact that a place is for rent indicates any access rights to the
> driveway ?  It can still be access=customers (or visitors, but we
> don't have that)

What I am sure about is that when you don't want tourists on your
property, you do not put up a tourist sign showing people where to go.
It's like an invitation to trespass your property.

reasonable doubt is definitely a thing

> 
> m.
> 
> On Thu, Oct 5, 2017 at 10:58 AM, joost schouppe
>  wrote:
>> Jakka mapped it as private, based on an anonymous note. However, we now have
>> clear indications this is wrong. We can't use Streetview to define this as
>> access=yes, but I believe we can use this to overrule an anonymous source.
>> So I have removed the tag and left a fixme and a comment at the note. I
>> would suggest we only change this based on a survey or a decent reply from
>> the local government.
>>
>> ___
>> 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] How we deal with this kind of note

[Glenn Plas]

It probably is Château de Miremont when checking the map.

On 04-10-17 18:50, Glenn Plas wrote:
> I can also see on the opposing side of the road a touristic sign that
> points you toward what I think reads "Chateau de miracle" even though
> it's blurred.
> 
> That hardly looks private.
> 
> https://www.google.be/maps/@50.5623311,4.2435211,3a,21y,117.34h,75.78t/data=!3m6!1e1!3m4!1sY7eetCLpKRiHgvO06v-M0Q!2e0!7i13312!8i6656
> 
> GLenn

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

Re: [OSM-talk-be] How we deal with this kind of note

[Glenn Plas]

I can also see on the opposing side of the road a touristic sign that
points you toward what I think reads "Chateau de miracle" even though
it's blurred.

That hardly looks private.

https://www.google.be/maps/@50.5623311,4.2435211,3a,21y,117.34h,75.78t/data=!3m6!1e1!3m4!1sY7eetCLpKRiHgvO06v-M0Q!2e0!7i13312!8i6656

GLenn


On 04-10-17 15:46, Gerard Vanderveken wrote:
> On second view, on the left tree, seems to be a little C1 sign and on
> the right tree there seems some text on a panel behind the leaves.
> I believe it is private, unless a visit at the place proves otherwise.
> 
> Regards,
> Gerard.
> 
> mgwebm...@fastmail.fm wrote:
>> Strange. That’s the link that is provided by their app. Could you try
>> again with this one or go to http://www.ngi.be/topomapviewer/ and then
>> search for Feluy : the path is just nest to the pointer.
>>
>> PS : I know it’s evil but still, have a look of the place on street
>> view
>> <https://www.google.be/maps/@50.5623074,4.2437303,3a,75y,10.39h,88.35t/data=%213m6%211e1%213m4%211sx-EXWKLUs4ThR1msjfdILw%212e0%217i13312%218i6656>
>>  :-)
>> There is absolutely nothing stating that this way is private.
>>
>> Matthieu
>>
>>> On 4 Oct 2017, at 13:55, Glenn Plas <gl...@byte-consult.be
>>> <mailto:gl...@byte-consult.be>> wrote:
>>>
>>> Hi,
>>>
>>> This link gives a bad request response for me:
>>>
>>> Bad Request
>>>
>>> Your browser sent a request that this server could not understand.
>>>
>>>> FYI, the path is mapped by the NGI, with driving restriction. See this
>>>> link
>>>> <http://www.ngi.be/topomapviewer/public?lang=fr=10=%7B%22x%22:641130,%22y%22:639266%7D=%7B%22autoMap%22:true,%22baseMaps%22:%5B%5B%22cartoweb_topo%22,100%5D%5D,%22aerialMaps%22:%5B%5D,%22overlayMaps%22:%5B%5D%7D;>
>>>
>>> Could you doublecheck this, I'm quite interested in this data.
>>>
>>> Cheers,
>>>
>>> Glenn
>>
>> 
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>   
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

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

[Glenn Plas]

Hi,

comments below

On 01-10-17 15:06, Yves bxl-forever wrote:
> Hello,
> 
> It may be a good idea to freshen up the pages on the wiki to remove all 
> confusion about this.
> Perhaps we could summarize all the discussions as such.
> 
> 
> 1) If a street is one-way for motor traffic but open to cyclists in both 
> direction, we use this:
> 
>   oneway=yes
>   oneway:bicycle=no
> 
> (This scheme is better than the legacy cycleway=opposite tag, because it also 
> allows to add oneway:moped_P=no if we have the new M11 roadsign allowing 
> speed pedelecs too.)
> 
> 
> 
> 2) A properly-marked lane 
> (http://wiki.openstreetmap.org/wiki/File:Cycleway_lane1_be.jpg), i.e. 
> stripped lines
> In Belgian traffic rules, this is the same as a track (fietspad/piste 
> cyclable) and gives right-of-way to cyclists
> 
>   cycleway=lane
> 
>   (if cyclists can use the street in both directions, use cycleway:left
>   or cycleway:right if the situation is not the same on both sides)
> 
> 
> 
> 3) Just logos 
> (http://redac.cuk.ch/archives_v3/5237/bandecyclablesuggeree.png) or color, 
> but without the stripped lines
> This is the example eMerzh brought up to start the discussion.
> This situation does not do anything with regard to traffic rules, but is 
> useful for cycling applications because it feels a little safer than a street 
> with nothing.
> 
>   cycleway=shared_lane
>  
> 
> 
> 
> What do you think?

You are totally correct is what I think.  Cycleway=opposite as per marc
marc's suggestion is wrong in this particular case.  well formulated.

Glenn


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

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

[Glenn Plas]

On 30-09-17 08:13, Jo wrote:
> True, we could use shared_lane, but then we either have to do that on
> all highways where bicycles aren't banned, or we go on with that as the
> de facto standard.
> 
> The fact that a bicycle is drawn, doesn't make it 'more' of a shared
> lane than it would be without the wasted paint.
> 
> All it does is make motorists aware that there might be bicycles sharing
> their lane. Something they should have been aware of anyway.

It also confirms for sure what Marc suggests for tagging, that this is
indeed a shared_lane.

I support tagging this as he proposes.  But so far for legality, this is
just suggestive painting.  Traffic signs should also be taken into
account as they override whatever is painted.

Glenn



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

Re: [OSM-talk-be] Hectometerbordjes

[Glenn Plas]

On 15-08-17 15:02, Philippe Casteleyn wrote:
> http://wegenenverkeer.be/persberichten/19300-kilometerbordjes-worden-vervangen
> 
> 19.300 kilometerbordjes worden vervangen | Wegen & Verkeer
> 
> wegenenverkeer.be
> De referentiebordjes, in de volksmond ‘kilometerbordjes’, langs de
> Vlaamse autosnelwegen krijgen een make-over. Het nieuwe ontwerp oogt
> frisser, is duidelijker en ...
> 
> 
> Zou dat geen mooie en gemakkelijke import zijn ?

Technisch is er nooit echt een moeilijke import.  Politiek is wat
anders , en met goede reden trouwens.  OSM is geen import dump.

Het gaat over een case maken eerst om de community te overtuigen van het
nut, het OSM belang, data accuracy, licensing, case study.

Wat ik me echt wel afvraag is wat het nut is van die bordjes, welke
added value hebben deze juist ?

Glenn

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

Re: [OSM-talk-be] Fwd: [Tagging] Brasserie

[Glenn Plas]

cuisine described the food served, not the restaurant type.

The wiki is quite clear on that
https://wiki.openstreetmap.org/wiki/Key:cuisine

So I quite agree with Marc that putting brasserie as this key's value is
not a description of the food being served.

Glenn

> I'm not sure whether I like the cuisine=brasserie. Do all the
> brasseries serve the same type food ? Can't you have a brasserie that
> is only serving fish dishes, or meat or vegetarian or a combination ?
> Can you expect the same food from a brasserie in Belgium and France ?
> 
> as for amenity=brasserie (and amenity=tavern) I fear that is a useless
> tag, as long as the data consumers will not start using it.
> What about the Danish Kro ? should they use amenity=tavern as well ?
> 
> Furthermore what is the difference between a brasserie, bistro,
> taverne, eetcafe ? (I see Thomas has an explanation for brasserie)
> 
> m.
> 


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

Re: [OSM-talk-be] Brugnummering

[Glenn Plas]

On 08-08-17 15:39, Marc Gemis wrote:
> old_name ?

Die tag kende ik eigenlijk niet direct en dus niet overwogen, vandaar
dat ik graag bijkomende input hoorde.  Tx

> p.s. is het wikipedia artikel dan ook verkeerd ? die geven dan zelfs
> nog een alt_name ook
> p.p.s Onroerend erfgoed noemt ze zelfs "wafelijzerbrug":

Is dat geen type brug gewoon ?  Voor zover ik weet was de brug te
nekkerspoel (is vervangen) een wafelijzerbrug

Die zien er zo uit meestal:
https://c1.staticflickr.com/3/2644/3945028467_f7f4e309f5_b.jpg

Wij spraken toch vroeger over wafelijzerbrug alsof het een soort brug
was en dan ging het over die te nekkerspoel

> https://inventaris.onroerenderfgoed.be/erfgoedobjecten/1504 . Ook
> verkeerd ?

Glenn


> 
> 2017-08-08 15:32 GMT+02:00 Glenn Plas <gl...@byte-consult.be>:
>> On 08-08-17 15:14, Marc Gemis wrote:
>>>>
>>>> Wat ik tegenwoordig veel zie is dat mensen de bruggen een naam geven,
>>>> die eigenlijk officiel nooit gebruikt wordt, die dus verkeerdelijk in
>>>> 'name' key worden gezet.
>>>
>>> Heb je daar een voorbeeld van ?
>>
>> https://www.openstreetmap.org/way/448871500
>>
>> Niemand, maar dan ook niemand in Mechelen zoekt of praat over de
>> Koepoortbrug.  Dit zijn historische namen, die wanneer je ze in de name
>> tag plaats de database vervuilen en verkeerde resultaten geeft bij
>> reverse geocoding in het bijzonder.  Ze worden ook op de map gerenderd
>> op de bruggen.
>>
>> Probleem is complex want eigenlijk bestaat er geen ideale tagging voor
>> dit soort data.  Ik verplaats ze naar description tags die iets beter
>> geschikt zijn maar ik sta open voor betere oplossingen.  alt_name is ook
>> niet echt geschikt omdat de vereiste daarvoor is dat er een name tag
>> bestaat.
>>
>> De namen staan niet in GRB volgens mij maar daar moet ik eerst naar op
>> zoek om zeker te weten.
>>
>> Glenn
>>
>>
>>>
>>> Als je kijkt naar bv.
>>> https://nl.wikipedia.org/wiki/Lijst_van_onroerend_erfgoed_in_Moerbeke-Waas
>>> dan zie je daar een 4-tal bruggen. (bijna onderaan de pagina).
>>> De naam van de bruggen is ook dikwijls aangegeven met borden in de
>>> buurt van de brug. Zoals bv. bij deze:
>>> https://nl.wikipedia.org/wiki/Lijst_van_onroerend_erfgoed_in_Moerbeke-Waas#/media/File:Coudenbormbrug.jpg
>>>
>>> Staan die namen in GRB ?
>>>
>>> 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] Brugnummering

[Glenn Plas]

On 08-08-17 15:14, Marc Gemis wrote:
>>
>> Wat ik tegenwoordig veel zie is dat mensen de bruggen een naam geven,
>> die eigenlijk officiel nooit gebruikt wordt, die dus verkeerdelijk in
>> 'name' key worden gezet.
> 
> Heb je daar een voorbeeld van ?

https://www.openstreetmap.org/way/448871500

Niemand, maar dan ook niemand in Mechelen zoekt of praat over de
Koepoortbrug.  Dit zijn historische namen, die wanneer je ze in de name
tag plaats de database vervuilen en verkeerde resultaten geeft bij
reverse geocoding in het bijzonder.  Ze worden ook op de map gerenderd
op de bruggen.

Probleem is complex want eigenlijk bestaat er geen ideale tagging voor
dit soort data.  Ik verplaats ze naar description tags die iets beter
geschikt zijn maar ik sta open voor betere oplossingen.  alt_name is ook
niet echt geschikt omdat de vereiste daarvoor is dat er een name tag
bestaat.

De namen staan niet in GRB volgens mij maar daar moet ik eerst naar op
zoek om zeker te weten.

Glenn


> 
> Als je kijkt naar bv.
> https://nl.wikipedia.org/wiki/Lijst_van_onroerend_erfgoed_in_Moerbeke-Waas
> dan zie je daar een 4-tal bruggen. (bijna onderaan de pagina).
> De naam van de bruggen is ook dikwijls aangegeven met borden in de
> buurt van de brug. Zoals bv. bij deze:
> https://nl.wikipedia.org/wiki/Lijst_van_onroerend_erfgoed_in_Moerbeke-Waas#/media/File:Coudenbormbrug.jpg
> 
> Staan die namen in GRB ?
> 
> 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] Brugnummering

[Glenn Plas]

Aha, interesting...  mijn dislike voor mapillary hield me tegen om dit
zelf te vinden.

Spijtig dat deze gegevens niet in GRB zitten, zou wel handig zijn.

Tx voor info.


On 08-08-17 15:09, Marc Gemis wrote:
> Zoals je kan zien bij de foto van de brug (via de mapillary link op de
> way), staat er een bordje met B.15 op. Dit lijkt mij nog een bordje
> oude stijl (blauw met witte letters).
> Veel bruggen hebben nu een geel bordje met zwarte letters, niet ? Ik
> denk dat er zelfs een zwart leeuwtje opstaat. Omdat bruggen nu onder
> Vlaanderen vallen ?
> 
> Let wel: bridge:ref op de weg of gewoon ref op het man_made vlak.
> 

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

Re: [OSM-talk-be] Brugnummering

[Glenn Plas]

Hier is de echte brugconstructie, in 2 keer geupload met tagfix.

http://www.openstreetmap.org/way/513944080

On 08-08-17 15:01, Glenn Plas wrote:
> 
> 
> On 08-08-17 14:35, Philippe Casteleyn wrote:
>>
>>
>> Nu jullie toch met bruggen bezig zijn, ik zie graag het juiste nummer erbij.
> 
> En waar haal je dat 'juiste nummer' vandaan  ?   De enige officiele
> referenties over bruggen die ik ken komen uit GRB.
> 
> Wat ik tegenwoordig veel zie is dat mensen de bruggen een naam geven,
> die eigenlijk officiel nooit gebruikt wordt, die dus verkeerdelijk in
> 'name' key worden gezet.
> 
> De tags die ik zie in uw link zijn er van een highway, niet van
> man_made=bridge waar wij het over hebben in de andere thread
> 
> Glenn
> 
> 
>> Dat is nog een extra hulp om over hetzelfde te spreken.
>>
>> https://www.openstreetmap.org/way/16735167#map=18/50.93209/4.47267=D
>> <https://www.openstreetmap.org/way/16735167#map=18/50.93209/4.47267=D>
>>  
>> OpenStreetMap | Way: ‪Sint-Martinuslaan‬ (‪16735167‬)
>> <https://www.openstreetmap.org/way/16735167#map=18/50.93209/4.47267=D>
>> www.openstreetmap.org
>> OpenStreetMap is a map of the world, created by people like you and free
>> to use under an open license.
>>
>>
>>
>>
>> Ha, deze brug heeft een officiële mapillary key.  Veel plezier ermee.
>>
>> Heeft iemand al "mijn" mly<->osm bookmarklet geprobeerd ?
>>
>>
>> ___
>> 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] Brugnummering

[Glenn Plas]

On 08-08-17 14:35, Philippe Casteleyn wrote:
> 
> 
> Nu jullie toch met bruggen bezig zijn, ik zie graag het juiste nummer erbij.

En waar haal je dat 'juiste nummer' vandaan  ?   De enige officiele
referenties over bruggen die ik ken komen uit GRB.

Wat ik tegenwoordig veel zie is dat mensen de bruggen een naam geven,
die eigenlijk officiel nooit gebruikt wordt, die dus verkeerdelijk in
'name' key worden gezet.

De tags die ik zie in uw link zijn er van een highway, niet van
man_made=bridge waar wij het over hebben in de andere thread

Glenn


> Dat is nog een extra hulp om over hetzelfde te spreken.
> 
> https://www.openstreetmap.org/way/16735167#map=18/50.93209/4.47267=D
> 
>   
> OpenStreetMap | Way: ‪Sint-Martinuslaan‬ (‪16735167‬)
> 
> www.openstreetmap.org
> OpenStreetMap is a map of the world, created by people like you and free
> to use under an open license.
> 
> 
> 
> 
> Ha, deze brug heeft een officiële mapillary key.  Veel plezier ermee.
> 
> Heeft iemand al "mijn" mly<->osm bookmarklet geprobeerd ?
> 
> 
> ___
> 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] determination: man_made=bridge wrong rendered ?

[Glenn Plas]

On 08-08-17 14:27, Jakka wrote:
> Do not quit understand.
> "man_made bridge 'under' a highway"

This was a cryptic way of explaining that highways that go over a bridge
are lying on top of the bridge sort of speak.  you have to visualise it
like this to understand, but I missed the part where you mentioned the
existing way is really going underneath it, then of course, do not
connect at the edges.

> In this case the bridge, there was a railway on/over it and the highway
> passes under it. So there is nothing to connect at the edges.

yea, in your case the railway would have to be connected, but since it
doesn't seem to be there you cannot connect indeed.  The idea is that
highway's with bridge tags area lying on top of the man_made=bridge
object.   One would expect the renderer to represent this correctly, at
the moment it doesn't.

Here's an example :
http://www.openstreetmap.org/#map=19/50.97426/4.46971=N

here you can see Damstraat being drawn over the bridge, and it is realy
below it, also the cycleway is rendered incorrect on top of it.

realistically the bridge should cover the stuff below it but I think for
producing a decent map, an opaque solution would probably be appropriate
on the part where the road below crossed the bridge above.

what I'm saying is probably that this issue isn't limited to a bridge
that has nothing crossing it, it's also showing up where things do run
over it.

I assume the railroad is historic and has disappeared in the field, if
not, by all means: draw it.  It represents reality.

But never map for the renderer, once the error is fixed there, it will
invalidate those solutions and you have to go in and fix it again, it's
better to leave accurate data intact and tackle the renderer issue.

Glenn

> 
> Op 8/08/2017 om 13:13 schreef Glenn Plas:
>> I have a few remarks on this, the biggest one is that we don't map for
>> the renderer...  (hardly ever preferably).
>>
>> The second one is that I think this solution is not the correct one, if
>> you put a man_made bridge 'under' a highway, you should connect the
>> bridge to the highway at the edges.   add a node that connects both and
>> then rendering will be a lot better but not quite like you would expect.
>>
>> transforming a bridge layout into a tunnel one isn't reflecting the real
>> situation.
>>
>> This is something that should be fixed in the renderer, not in the data.
>>
>> Glen
>>
>> On 08-08-17 12:27, Jakka wrote:
>>> Determination: a bridge with nothing going over it anymore added as
>>> man_made=bridge and layer=1 is not rendered well.
>>> To counter it I made for the highway tunnel=yes layer=-1
>>> http://www.openstreetmap.org/#map=19/50.88289/4.11087=N
>>> http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge
>>> https://www.dropbox.com/s/nhmvcgyekaq4i5f/man_made%20bridge.jpg?dl=0
>>> PS image on dropbox will not stay for ever
>>>
>>>
>>> ___
>>> 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] determination: man_made=bridge wrong rendered ?

[Glenn Plas]

I have a few remarks on this, the biggest one is that we don't map for
the renderer...  (hardly ever preferably).

The second one is that I think this solution is not the correct one, if
you put a man_made bridge 'under' a highway, you should connect the
bridge to the highway at the edges.   add a node that connects both and
then rendering will be a lot better but not quite like you would expect.

transforming a bridge layout into a tunnel one isn't reflecting the real
situation.

This is something that should be fixed in the renderer, not in the data.

Glen

On 08-08-17 12:27, Jakka wrote:
> Determination: a bridge with nothing going over it anymore added as
> man_made=bridge and layer=1 is not rendered well.
> To counter it I made for the highway tunnel=yes layer=-1
> http://www.openstreetmap.org/#map=19/50.88289/4.11087=N
> http://wiki.openstreetmap.org/wiki/Tag:man_made%3Dbridge
> https://www.dropbox.com/s/nhmvcgyekaq4i5f/man_made%20bridge.jpg?dl=0
> PS image on dropbox will not stay for ever
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be


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

Re: [OSM-talk-be] meerdere postcodes voor één gemeente

[Glenn Plas]

The advice below isn't correct.  We don't need alternatives, we need to
improve the postal_code boundaries to encompass those houses that are on
the wrong side of the postal code.

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

Postal code's on administrative boundaries will throw a JOSM warning
when validating. I in fact delete those, they add no value to geocoding
at all, and will not be looked at.

However, in Flanders, we have almost a complete coverage in terms of
postal code boundaries.
https://wiki.openstreetmap.org/wiki/Tag:boundary%3Dpostal_code

There is still a lot of work in the rest of the country to complete
those, but they are perfect for handling border cases.   The AGIV/CRAB
tool also takes those into account, so if you mess up the postal code,
even though everything else is fine, you will see a 'error/wrong' on the
completion results. ( see http://aptum.bitless.be/ )

To see how complete this is, you can use overpass:

http://overpass-turbo.eu/s/qIO

Glenn


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

Re: [OSM-talk-be] CRAB-adressen met underscore

[Glenn Plas]

/vaartstraat02.json
 delete mode 100644 data/9971/vaartstraat01.json


Glenn

On 10-07-17 13:07, Sus Verhoeven wrote:
> Hooi Glenn,
> 
> Dat zou fijn zijn.
> Ik ben bezig in Heusden-Zolder 3550 en daar zijn tal van gevallen.
> Schijnbaar is men afgestapt van het A,B,C systeem.
> Op voorhand bedankt.
> 
> Sus
> 
> 2017-07-10 12:10 GMT+02:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> 
> 
> 
> On 08-07-17 15:16, joost schouppe wrote:
> > Juist, die had ik nog niet gecheckt!
> > Ik denk dat het correcte inderdaad is om in huisnummers met een
> > underscore (een bisnummer dus, oftewel een volwaardig huisnummer, niet
> > een busnummer) die te vervangen door een slash. Maar ik ben er niet
> > helemaal zeker of dat in heel Vlaanderen van toepassing is.
> >
> > Maar de Crab import tool houdt daar dan helemaal geen rekening mee?
> 
> Ik zal het nakijken/fixen indien nodig. Ik heb zelf een case hier in de
> buurt, tx voor de background info over die underscores, ik wacht meestal
> gewoon tot crab gefixt is, vaak is het in wijken waar druk verkaveld
> wordt.
> 
> Moet niet te moeilijk zijn om dit op te lossen.
> 
> Glenn
> 
> 
> 
> >
> > Op 8 jul. 2017 10:46 schreef "Sus Verhoeven" <sus...@gmail.com
> <mailto:sus...@gmail.com>
> > <mailto:sus...@gmail.com <mailto:sus...@gmail.com>>>:
> >
> > Hooi,
> >
> > Die underscore geeft ook problemen in de housenumbers, onze crab
> > import tool
> "http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import
> <http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import>
> > <http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import
> <http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import>>" geeft die
> > adressen terug als fout zijnde, wat vervelend is wanneer men een
> > straat wil afwerken.
> > OSMAND erkent die adressen niet, ook vervelend.
> > De validator van Bpost neemt ze wel aan, maar vervangt de
> underscore
> > door een slash.
> >
> > Sus
> >
> >
> > 2017-07-07 18:49 GMT+02:00 joost schouppe
> <joost.schou...@gmail.com <mailto:joost.schou...@gmail.com>
> > <mailto:joost.schou...@gmail.com
> <mailto:joost.schou...@gmail.com>>>:
> >
> > Hoi,
> >
> > In het CRAB zie je soms adressen van de vorm Straatnaam_12,
> > Straatnaam_AB of zelf Straatnaam_ABCD. Dit is niet de
> officiële
> > straatnaam, die is gewoon Straatnaam.
> >
> > De reden dat deze schrijfwijze bestaat, is puur een gevolg van
> > hoe CRAB ooit opgesteld is. Daarbij werd op sommige plaatsen
> > geen rekening gehouden met het feit dat binnen één gemeente
> > dezelfde straatnaam meerdere keren gebruikt kan worden.
> Adressen
> > hoeven immers niet uniek te zijn door de combinatie van
> > administratieve gemeente, straatnaam en huisnummer. Ze moeten
> > maar uniek zijn door óók de postcode mee te nemen.
> >
> > Uiteraard gaan we deze database-technische bijzonderheid niet
> > meenemen naar OpenStreetMap. Het gebeurt nochtans toch wel
> eens,
> > zie deze query:
> >
> > http://overpass-turbo.eu/s/qdE
> >
> > Voel je vrij deze straatnamen te corrigen, en geef de mappers
> > die dit gebruiken een seintje. Ik doe dit zelf wel voor de
> > mappers die dit in Antwerpen deden.
> >
> > Er zijn wel degelijk data-consumers die geen rekening
> houden met
> > de polygonen van de postzones om adressen uniek te maken. Maar
> > dat is natuurlijk het probleem van die data-consumers,
> niet van
> > de OpenStreetMap database.
> > Eventueel kan je adressen wel de tag addr:postcode meegeven.
> > Aangezien de postcode van adressen open data is, maar de
> > geometrie van postcodes niet, lijkt mij dat zeker voor
> > twijfelgevallen geen slecht idee.
> >
> > (verschillende mappers gaven aan dat deze straatnamen met een
> > underscore niet in OSM horen op ons chatkanaal Riot.
> Vandaar dat
> > ik dit als een conclusie presenteer. U ben ste

Re: [OSM-talk-be] CRAB-adressen met underscore

[Glenn Plas]

On 08-07-17 15:16, joost schouppe wrote:
> Juist, die had ik nog niet gecheckt!
> Ik denk dat het correcte inderdaad is om in huisnummers met een
> underscore (een bisnummer dus, oftewel een volwaardig huisnummer, niet
> een busnummer) die te vervangen door een slash. Maar ik ben er niet
> helemaal zeker of dat in heel Vlaanderen van toepassing is.
> 
> Maar de Crab import tool houdt daar dan helemaal geen rekening mee? 

Ik zal het nakijken/fixen indien nodig. Ik heb zelf een case hier in de
buurt, tx voor de background info over die underscores, ik wacht meestal
gewoon tot crab gefixt is, vaak is het in wijken waar druk verkaveld wordt.

Moet niet te moeilijk zijn om dit op te lossen.

Glenn



> 
> Op 8 jul. 2017 10:46 schreef "Sus Verhoeven"  >:
> 
> Hooi,
> 
> Die underscore geeft ook problemen in de housenumbers, onze crab
> import tool "http://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import
> " geeft die
> adressen terug als fout zijnde, wat vervelend is wanneer men een
> straat wil afwerken.
> OSMAND erkent die adressen niet, ook vervelend.
> De validator van Bpost neemt ze wel aan, maar vervangt de underscore
> door een slash.
> 
> Sus
> 
> 
> 2017-07-07 18:49 GMT+02:00 joost schouppe  >:
> 
> Hoi,
> 
> In het CRAB zie je soms adressen van de vorm Straatnaam_12,
> Straatnaam_AB of zelf Straatnaam_ABCD. Dit is niet de officiële
> straatnaam, die is gewoon Straatnaam.
> 
> De reden dat deze schrijfwijze bestaat, is puur een gevolg van
> hoe CRAB ooit opgesteld is. Daarbij werd op sommige plaatsen
> geen rekening gehouden met het feit dat binnen één gemeente
> dezelfde straatnaam meerdere keren gebruikt kan worden. Adressen
> hoeven immers niet uniek te zijn door de combinatie van
> administratieve gemeente, straatnaam en huisnummer. Ze moeten
> maar uniek zijn door óók de postcode mee te nemen.
> 
> Uiteraard gaan we deze database-technische bijzonderheid niet
> meenemen naar OpenStreetMap. Het gebeurt nochtans toch wel eens,
> zie deze query:
> 
> http://overpass-turbo.eu/s/qdE
> 
> Voel je vrij deze straatnamen te corrigen, en geef de mappers
> die dit gebruiken een seintje. Ik doe dit zelf wel voor de
> mappers die dit in Antwerpen deden.
> 
> Er zijn wel degelijk data-consumers die geen rekening houden met
> de polygonen van de postzones om adressen uniek te maken. Maar
> dat is natuurlijk het probleem van die data-consumers, niet van
> de OpenStreetMap database. 
> Eventueel kan je adressen wel de tag addr:postcode meegeven.
> Aangezien de postcode van adressen open data is, maar de
> geometrie van postcodes niet, lijkt mij dat zeker voor
> twijfelgevallen geen slecht idee.
> 
> (verschillende mappers gaven aan dat deze straatnamen met een
> underscore niet in OSM horen op ons chatkanaal Riot. Vandaar dat
> ik dit als een conclusie presenteer. U ben steeds welkom op
> Riot: https://riot.im/app/#/room/#osmbe:matrix.org
>  )
> 
> -- 
> Joost Schouppe
> OpenStreetMap
>  | Twitter
>  | LinkedIn
>  | Meetup 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] duplicates originating from GRB merge

[Glenn Plas]

Hi Seppe,

Sorry it took me a while to open my mailbox lately.

On 02-06-17 19:22, Santens Seppe wrote:
> Hey guys,
> 
> From time to time, I'm seeing duplicate nodes or areas that I reckon are
> due to (wrong use) of the GRB merge tools. One striking example:
> https://www.openstreetmap.org/note/1017110 (let the JOSM validator run
> on this area)

It looks indeed a problem caused by the user, exporting twice, it's kind
of strange this goes unnoticed by the mapper.  I think the docs of the
development tool clearly says to validate and validate again.

Right now it's impossible to be caused by the database, in the past if a
building was in 2 different datasets (at a province border usually) it
got double exported.  This is fixed now, even when the source data
shares objects(even in de database), only 1 will be extracted.

> 
> Is there any news about the tools? I see they are being used quite
> often, but probably not always in the correct way. I guess making them
> somewhat "dummy proof" would help (I'm also speaking for myself :-) )...

A new tool is in development [1], taking in all what was learned and
building a better one.  Making it a bit more dummy-proof is perhaps an
option but it is intended for seasoned mappers in the first place.

There is also a tool[2] based on terraform/google cloud to build the
database from scratch (and translating tags/keys), it's working 100% but
the OSM translations of quite a few objects isn't implemented yet.   The
data in the test/dev tool is therefor changed and less correct
(building='verdieping' is now in there, it wasn't before).  The GRB data
was already a year old so I rebuilt it but this time 100% automated and
I still have to add those queries to the postprocessing.

I have fixed that area you mentioned but I haven't doublechecked the
area yet.

There is a screenshot[3] too if you're curious.

Thanks for doing this Q/A work and reporting it.

Glenn



[1] https://github.com/gplv2/grbtool
[2] https://github.com/gplv2/grb-postgis
[3]
https://raw.githubusercontent.com/gplv2/grbtool/master/screenshots/grbtool_new.png

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

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Glenn Plas]

Hallo Brecht,

Bedankt om ons te woord te staan.  Een bijkomende opmerking, namelijk..
 de fout door Marc ontdekt te Temse ligt in de provincie Oost-Vlaanderen.

Dus in de data van Oost-Vlaanderen zou die weg niet opgenomen mogen
zijn, wat ons dan brengt naar de vraag: waarom is die dan toch
aangepast.  Als het antwoord op die vraag eenduidig kan worden gegeven
denk ik dat we aan de core van het probleem zitten.

Kan je de originele shape file ergens publiceren?  Ik vermoed stilaan
maar sterk dat het probleem ergens dicht aan de bron van de basisdata zit.

Mvg,

Glenn


On 16-05-17 11:07, Brecht Van Maldergem wrote:
> Heren,
> 
> Gezien er begin dit jaar nog veel wegen waren die nog niet omgezet waren van 
> 90 naar 70 in de OSM dB, hebben wij de vrijheid genomen om deze inderdaad 
> zelf op te nemen;
> Zie 
> https://lists.openstreetmap.org/pipermail/talk-be/2017-February/009670.html 
> voor de originele dataset op welke de wijzigingen gebeurd zijn.
> Deze dataset werd ons aangeleverd door AWV inderdaad.
> http://application-mapserver.be-mobile.biz/ms?map=/maps/public-osm/configs/speedReduction.map=WMS=GetCapabilities
> 
> Voor alle feedback cf aanpassingen van Ilona, graag terugkoppelen naar mij.
> http://www.openstreetmap.org/user/Ilona_S/history
> 
> Ik vermoed dat de 'fout' in volgende remark kan zitten;
> Opgelet: Wegsegmenten waar de maximaal toegelaten snelheid '90' blijft, zijn 
> niet opgenomen in dit bestand met uitzondering van deze in de provincie 
> Antwerpen.
> Dat maakt dat de 'fout' zich zou beperken tot regio Antwerpen.
> 
> Indien gewenst kan ook de originele shapeFile aangeleverd worden, mocht dit 
> makkelijker werken.
> 
> Mvg,
> Brecht
> 

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

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Glenn Plas]

Hi Joost,

some inline thoughts added.

On 15-05-17 18:49, joost schouppe wrote:
> Hi Glenn,
> 
> I'm not sure we should fix this ourselves. I think we can ask Be-mobile
> to fix this. But maybe a revert is in order.

That would also be a lot of work btw, very small changesets.  I don't
really like reverts (unchecked) as it tends to throw away the baby with
the water.

> Be-mobile didn't discuss this in advance, but just let us know they did
> afterwards. I personally failed in following this up, so now we have
> this mess on the mailing list. First steps are always hard, and when you
> try to do too much in your first step, you can have a big mess up. Let's
> not judge them too much, and try to make this a learning experience, not
> a first and last step. But there is definitely a lot of learning to be had!

I agree, I tend not to fix the blame, I rather fix the problem.

> I can't judge the quality of their WMS, as I can only get it to tell me
> "something is wrong here", not what needs to happen. The base data from
> AWV seems to be correct, at least in the case Marc found. So I would
> guess it's a question of instructions gone wrong.

If I had to guess, that would also be mine, perhaps communication
problem to the person doing the work.

> In many cases there is both AWV data (which the people at AWV were quite
> confident about) and Mapillary traffic signs, so we do have some
> material to work with. It would be nice to have an idea of the size of
> the problem, so we can give more info to Be-Mobile. Of course we need a
> quick solution, but I think it would be best if a larger problem caused
> by a paid mapper doesn't need to be fixed by a volunteer.

I'll try and make a Q/A tool for this, if I have the datasets.  I'm
messing about with the GRB dataset again, might throw in the roads as
well.  primary/secondary roads are a relatively small dataset.  As long
as the problems isn't the source data, we can detect those.

Wouldn't it be nice if we got paid for edit work ? :)

Glenn

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

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Glenn Plas]

On 15-05-17 17:02, joost schouppe wrote:
> Glenn, calm down :)

it's not because I say fubar that I'm not calm.  this is e-mail, totally
lacking the ability to convey emotional states, not counting ALL-CAPS
messages,  I said fubar because now we need to audit all changes.   Not
for the problem, but for the work I foresee in assessing the impact of this.

> In fact, Be-Mobile announced on this list that they had made a WMS with
> the roads that needed changing because of the 90->70 law in Flanders
> [1]. They also gave Ben and me the username of this person who did the
> changes for them. But I never followed up on that. Sorry!

I see a number of problems here: first of all, "we" trusted a third
party -blindly- it seems.  We(you) seem to have helped them from the
start, which is good. conclusion: that WMS wasn't Q/A' decently before
releasing it into the wild.
Second problem is that this is prime example of armchair mapping making
this look more like a manually executed datamerge than map editing.

The third -biggest problem- is that the data seems to be wrong, at least
for this road!  That is in fact a huge problem when it comes to 'trust'
aspect of the third=party database.

I've been taking a look at some of the changes in detail and so far, I
see little intelligence in it (roads with different speeds in both
direction, exception made with traffic signs aren't there).  But it's
still unclear if they are errors or not without local knowledge, so same
goes for me: I can't even tell if it is correct or not, and I don't
think paper lists will determine that.

It's just a search/replace from my first analysis.  I could have done
that with a few Overpass queries and JOSM in 30 minutes and move on.

> So it is logical that all their changesets would be 90 to 70. The
> question which i can't answer right now is where exactly it went wrong.
> As far as I understood, they used the AWV dataset to find places to
> change, and that is correct in this case [2]. Our contact at Be-Mobile
> is out of office right now, so I can't tell you more right now.

Ok, in context of this knowledge that doesn't really make me feel more
confident now but I do understand why all changesets are like that.
(same commit message all over again, instead of mentioning road names
for example).

> But I think we can definitely ask them to look over these changes again.
> Something clearly went wrong here, but we don't know the scope of
> mistakes yet, and at least we know who did this and why.

indeed, the 'scope', the part that translated into 'fubar' in my initial
message.  We have no idea now on the impact.

But I am going to take a deeper look into why some applications I've
built are flagging speed problems (average maxspeeds way too high for
all traffic) when compared to OSM speeds, including a traffic layer that
depends on those maxspeeds on all primary/secondary roads.

Perhaps I missed the announcement on which user this was going to be
doing,  but it would probably been a better idea to create a dedicated
account indicating the owner/affiliation instead of using personal names.

I could not tell this was BE-Mobile related.

Glenn

> 
> 
> 1: https://lists.openstreetmap.org/pipermail/talk-be/2017-April/009887.html
> 1:
> http://www.geopunt.be/kaart?type=dataset=%5B%7B%27type%27%3A%27WMS%27%2C%27url%27%3A%27https%3A%2F%2Fwww.mercator.vlaanderen.be%2Fraadpleegdienstenmercatorpubliek%2Fows%3FSERVICE%3DWMS%26service%3DWMS%26version%3D1.3.0%26request%3DGetMap%27%2C%27layers%27%3A%5B%7B%27id%27%3A%27tn%3Atn_snelhrg_awv%27%2C%27title%27%3A%27WMS-GetMap%20van%3A%20Snelheidsregimes%20langs%20de%20genummerde%20wegen%20in%20beheer%20van%20AWV%27%7D%5D%7D%5D
> 
> Op 15 mei 2017 om 16:04 schreef Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> Ok, I found her.  omg. she's dedicated to changing all 90's to 70's.
> This is really fubar imho.
> 
> https://www.openstreetmap.org/user/Ilona_S/history#map=10/51.0953/4.3039
> <https://www.openstreetmap.org/user/Ilona_S/history#map=10/51.0953/4.3039>
> 
> 
> On 15-05-17 12:24, Marc Gemis wrote:
> > Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
> > km/h gebracht.
> > Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
> > vervangen zonder lokale kennis.
> > Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
> > wat wijzigingen gedaan
> >
> > Op mijn Nederlandstalige changeset comment, reageerde ze in het
> Engels.
> >
> > mvg
> >
> > m
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
> > https://lists.openstreetm

Re: [OSM-talk-be] 90->70 in Vlaanderen

[Glenn Plas]

Ok, I found her.  omg. she's dedicated to changing all 90's to 70's.
This is really fubar imho.

https://www.openstreetmap.org/user/Ilona_S/history#map=10/51.0953/4.3039


On 15-05-17 12:24, Marc Gemis wrote:
> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
> km/h gebracht.
> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
> vervangen zonder lokale kennis.
> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
> wat wijzigingen gedaan
> 
> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
> 
> 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] 90->70 in Vlaanderen

[Glenn Plas]

changeset ID ?

Dit is altijd zo frustrerend... doe-maar-op-mappers met
ik-heb-mijn-eigen-regels voor OSM

Glenn


On 15-05-17 12:24, Marc Gemis wrote:
> Ik heb dit weekend de N16 tussen Willebroek en Temse terug naar 90
> km/h gebracht.
> Een overijverige mapster heeft volgens mij gewoon alle 90 door 70
> vervangen zonder lokale kennis.
> Misschien best eens in je eigen buurt kijken, want ze heeft behoorlijk
> wat wijzigingen gedaan
> 
> Op mijn Nederlandstalige changeset comment, reageerde ze in het Engels.
> 
> 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

[OSM-talk-be] CRAB tool data update notification - 2017-01-05

[Glenn Plas]

Hallo

In de reeks maandelijkse CRAB updates: Nieuwe CRAB data is processed en
staat ter beschikking hier:

http://aptum.bitless.be/

Ik heb de import resultaten en de nieuwe stratenlijst ook online gezet:

Data extraction date: 2017-05-01 zou je moeten zien (druk
F5/shift+reload als je dit niet direct ziet om cache te clearen)

De results files zijn meestal gecached in de browser, doe een expliciete
reload om die te updaten.


PS: Originele site loopt nog steeds achter
http://crab-import.osm.be/import.html


Glenn




Hello

In the series: Monthly CRAB updates

New CRAB data has been processed and is at your service using the
following url : http://aptum.bitless.be/

You should see Data extraction date: 2017-05-01 and 2 extra links with
import results and new streets. (if you don't see this: purge your
browser cache by doing F5 and/or shift-reload the page)

Glenn

PS: Original crab-import site seems to be unmanaged atm.

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

Re: [OSM-talk-be] Multilingual names

[Glenn Plas]

Hey Marc,

> https://wiki.openstreetmap.org/wiki/User_talk:Gplv2 on the discussion
> tab. Didn't you get a mail for that ?

oh .. I see , that probably goes to my google mail address, a bit of a
trashbin-mail account with massive amounts of spam hiding real messages,
I only check that sporadically

> 
> As for the French-Dutch. I think I added a name once to a path in
> Zonienwoud, in the other order. Can't find it right now. Perhaps
> someone corrected my vandalism :-)

The tool I made would pick that up and flag it, I only corrected about
3% (99%-96%).  It just made sense to further unify the data that way and
match the wiki page, didn't give it much thought hence failed to raise
this issue to the list.

I believe it's better this way as the former rule seemed to be a
political motivated one, and that has no place in OSM.  We should
refrain from making those types of decisions.

Like you, I don't care french is first , dutch is second, as long as it
is done consistently.  It makes the map look good.

In that regard, I am desperately looking for a quality resource on
street names in BXL, and I need one that is written exactly how it
should be written.

I used a document that was very complete but I failed to understand the
spelling rules in french language (I was always taught that capitals
aren't accented but apparently there are notable exceptions, one of them
applies to streetnames).

I was educated on the subject by Yves (bxl-forever).  I stopped my edits
at once and still need to roll back some of those accent problems, but I
need a street list first, when I have one, I can incorporate it in the
tool, that would be an awesome feature to have.

Sorry for not being more forthcoming on this, I didn't expect this
impact on us.

That Q/A tool would help you find the problem if it exists, I downloaded
zonienwoud to an osm file but it seems that a packages I use (medoo) has
been broken since I last used it.  I have to fix the source code first.

Glenn



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

Re: [OSM-talk-be] Multilingual names

[Glenn Plas]

On 07-04-17 13:22, Jo wrote:
> Wow, for the faciliteitengemeenten I don't agree either!

That's not mine :)   I live on the border of those silly legal entities
and I disagree as well :)

Glenn


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

Re: [OSM-talk-be] Multilingual names

[Glenn Plas]

Hi Marc,

gplv2 that will be me :)

On 07-04-17 11:28, Marc Gemis wrote:
> I just stumbled upon the wiki page
> https://wiki.openstreetmap.org/wiki/Multilingual_names#Brussels
> I was surprised to read e.g. "Note that the "first mapper rule" is
> deprecated now." and "In OSM, we have a consensus to use a fixed
> order" (both changes made by Gplv2 on Oct 19, 2016)

Yup, the first mapper rule is even more silly and you end up with a
mixed dataset you can't even automatically perform Q/A checks on, there
was already a defacto standard going on in BXL, I just changed the wiki
to reflect that change, 99% of the data was 'fr - nl'.

> 
> Not that I care about the order of French and Dutch on those
> streetnames, but it would be nice to inform the community about such
> an important change via the mailing list, not ? If this is indeed the
> consensus I would have violated it since I did not know deprecation of
> the first mapper rule.

There was no change really, only an update to the wiki to reflect
reality, if you check the data, it's almost entirely entered in this
way.  Not many new streets pop up these days, so it has little impact.

> 
> I asked Gplv2 to point me to the discussion leading to the consensus.

I've must have missed your question on that, can you let me know
how/where you asked ?  always ready to answer you.

> 
> So I have no problems with this being the consensus, I do have a
> problem that such an important change is made without informing the
> mailing list.

Again, I don't aggree on this being a BIG change, in fact, I guestimate
that at the time, about 96% of BXL was in this format, so it might not
have been a true consensus we talked about in depth, the data told me
that this was a defacto consensus so I changed the wiki to reflect
reality.  I did this to guide OSM newbees

Take a look here, I made a tool to analyse this :
https://github.com/gplv2/urbis-validate

The only problem with it is that it doesn't support capitals with
accents (a change I need to make soon).

Glenn


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

Re: [OSM-talk-be] FW: Basiskaart Vlaanderen (GRB) - Wijzigingen GRB-producten vanaf juli 2017

[Glenn Plas]

On 06-04-17 15:29, Santens Seppe wrote:
> Possibly of importance for the GRB - OSM merge.

Impact isn't too big.  Marc gemis will probably cheer as Gba  type
uitbreiding will be gone.  Those are usually just buildings/parts of and
probably belong in Gbg :)

Glenn


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

Re: [OSM-talk-be] Addr Import

[Glenn Plas]

On 27-03-17 16:08, Sus Verhoeven wrote:
> Bedankt voor de link, zou het niet goed zijn deze ergens op de wiki te
> zetten ?

- http://wiki.openstreetmap.org/wiki/WikiProject_Belgium/GRB (onderaan)
- http://wiki.openstreetmap.org/wiki/GRBimport  (in het midden)

Ze staat er reeds op. En reeds paar keer op de mailing lijst ook
langsgeweest :)

wel bedankt om toch te vragen achter die link, door een 2de server bij
te steken was die site even in de mist (je kreeg om de beurt de andere
server, de ene met de oudere data).  Niet zo goed voor de consistency
van afgeleide data trouwens, ik hoop dat niet teveel mensen deze
gebruikt hebben in die tijd.   Het was een emergency actie voor een
andere site en zo is het wat stuk gegaan.

Mvg,

Glenn

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

Re: [OSM-talk-be] Addr Import

[Glenn Plas]

On 26-03-17 16:43, Glenn Plas wrote:
> Hallo Lodde,
> 
> Sander zijn tool is niet up to date, je kan deze URL gebruiken voor
> up-to-date data
> 
> http://aptum.bitless.be/

Ik heb mijn versie aangepast, deze draait op 2 servers in parallel en
1tje ervan had een probleem, bij deze zou je nu bovenaan dit zien staan:

Please read the documentation before using this import site
Data extraction date: 2017-03-10 - parser output - new streets - deleted
streets

Dat is de laatste versie van de data import.

Glenn

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

Re: [OSM-talk-be] Addr Import

[Glenn Plas]

Hallo Lodde,

Sander zijn tool is niet up to date, je kan deze URL gebruiken voor
up-to-date data

http://aptum.bitless.be/

Glenn

On 15-03-17 17:13, Louis van Boeckel wrote:
> Wat is er mis met import, krijg altijd *Data extraction date:* 2015-03-02
> 
> lodde
> 
> 
> 
> Avast logo
> 
>   
> 
> Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware.
> www.avast.com
> 
> 
> 
> 
> 
> 
> ___
> 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] CRAB tool data update - 2017-03-10

[Glenn Plas]

Hallo

In de reeks maandelijkse CRAB updates: Nieuwe CRAB data is processed en
staat reeds ter beschikking hier:

http://aptum.bitless.be/

Originele site staat wel nog achter http://crab-import.osm.be/import.html

Pull request is nog niet geaccepteerd.  Ik heb de import resultaten en
de nieuwe stratenlijst ook online gezet:

Data extraction date: 2017-03-10 zou je moeten zien (druk
F5/shift+reload als je dit niet direct ziet om cache te clearen)

Glenn



Hello

In the series: Monthly CRAB updates

New CRAB data has been processed and is at your service using the
following url : http://aptum.bitless.be/

The data should become available on the original site @
http://crab-import.osm.be/import.html when the pull request is applied.

You should see Data extraction date: 2017-03-10 and 2 extra links with
import results and new streets. (if you don't see this: purge your
browser cache by doing F5 and/or shift-reload the page)

Glenn



Pull request(s):

https://github.com/aptum/aptum.github.io/pulls

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

Re: [OSM-talk-be] Notes pollutie in Brussel

[Glenn Plas]

Mr Casteleyn,

Dit is de 2de maal dat u iemand persoonlijk aanvalt, en 2 maal dezelfde
persoon over een paar notes die u niet aanstaan.

U overdrijft gewoon.  Ik heb met de mantel der liefde al mensen
aangepakt die brokken data vernielden van mijn hand uit onwetendheid,
iedereen in OSM doet dubbel werk van tijd, live with it.  It's part of
the game.

Als de notes u werkelijk niet aanstaan, kijk er dan niet naar!  Dit is
een community, geen concurentie.  geen enkele 'dictator' verplicht u
toch om er rekening mee te houden ?

Ik vind dat Math nog heel proper reageerde op uw voorlaatste klaagzang,
ik stel voor om dezelfde diplomatische houding aan te nemen, uw
aanvallen storen mij meer dan de notes waar ik niet naar kijk.  Steek uw
energie in het editten van de kaart ipv in dit soort thrash mails te
schrijven.

Er is geen deadline voor editeren van OSM, het is een constante golf van
veranderingen en aanpassingen aan de realiteit, we zullen de factor
altijd achterlopen op de werkelijkheid.

Don't fix the blame, fix the problem.

Glenn




On 16-02-17 09:38, Philippe Casteleyn wrote:
> http://www.openstreetmap.org/user/philippec
> 
> Het is beleefd op het OSM profiel te zeggen wat u waar doet.
> 
> 
> Ik heb er altijd een punt van eer van gemaakt de foto's voor
> fatsoenlijke notes de dag zelf te publiceren.  De laastste 5 maand zit
> ik naar de 50 notes van Math te staren en ik zie meer beweging in de
> winkels dan in de notes.  Bovendien zijn zijn notes geen notes.  Zelfs
> een Brusselaar kan op de OSM kaart zien welke panden en
> winkelgaanderijen niet getagd zijn.  Er is geen verdienste aan.   Het is
> gewoon hondjesgedrag.
> 
> 
> Ik ben niet van plan elke dag te kijken of er een éénenvijftigste
> fatsoenlijke note tussen zit.  Ik ben ook niet van plan naar de pijpen
> van een buitenlandse dictator te dansen.  Zijn er al precendenten ?  Hoe
> reageren andere beschavingen op zulke D.O.S. bombardementen ?  Ik heb
> ook niet de indruk dat de locals 100 procent achter mij staan.  De notes
> staan er nog.  Ik zal dan ook stoppen met de winkelgaanderijen te
> bolfotograferen.  Trop is te veel.
> 
> 
> 
> Ph Casteleyn
> Dahliastraat 16
> 2800 Mechelen
> animals.slippers.loaders
> gsm 0486 516261
> 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] KBO

[Glenn Plas]

Nope, we can't.  The license is incompatible with OSM.   It's too
restrictive.
http://economie.fgov.be/nl/modules/publications/kbo/licence_open_data.jsp

I investigated this about a half year ago.  They call it open data but
they impose restriction on the usage.  I downloaded it back then and
gave as intended use : "creating a webapp".  It's a bit silly because
you can keep it very generic but it's too limiting to be a real opendata
license.

They used to sell this DB for a small fee of about 70K euro's in the
past, probably still a relic of clinging on reselling data that in
essence is 'ours' to begin with.

See also the cookbook:
http://economie.fgov.be/nl/binaries/Cookbook%20KBO%20Open%20Data%201.0.0_nl_2_tcm325-246659.pdf

I've considered using this data to augment up the GRB data on import,
but decided against it.

Glenn


On 16-02-17 10:37, Killian De Volder wrote:
> Does anyone know if we are allowed to use
> http://kbopub.economie.fgov.be/kbopub/zoeknummerform.html ?
> 
> I would read some of the policies on their site, but all the links are broken.
> 
> If nobody knows, I could send an email to the department to ask.
> 
> Regards,
> Killian
> 
> ___
> 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 tool data update - 2017-02-14

[Glenn Plas]

On 14-02-17 20:17, Sus Verhoeven wrote:
> Hooi Glenn,
> 
> Ik overdrijg niet, eens ik de data binnengeladen heb gebruik ik die een
> ganse dag, behalve nu met dat uitproberen.
> Zelfs na sleepmode blijven die gegecens bewaard.
> Met filters moet ik de server meermaals aanspreken, ik veroderstel dat
> dat nog meer tijd kost.

De oppervlakte is kleiner als je dit op basis van straten filtert.  Vele
kleintjes maken een grote zeg maar gerust.

De overpass query die in je browser wordt uitgevoerd wordt zwaarder,
afhankelijk van hoe groot het gebied is, maar hij doet het maar 1 keer.

Als je dan in bv Antwerpen alles tesamen opvraagt: dat is echt een pak
data, grote oppervlakte dus 'zwaarder' voor de service.

Voorlopig zie ik geen oplossing door de beperking van de alternatieve
Overpass services.

Zelf werk ik veel kleinerschaliger, maar ik snap dat je op een bepaald
punt het overzicht wil zien van wat er nog te fixen valt.  Die kleurtjes
maken het aantrekkelijk om het resultaat van je werk te bekijken, ik doe
het ook wel eens maar als dat langer duurt ga ik een tas koffie halen.

Ik woon in een relatief kleine gemeente en heb praktisch alles compleet
gemaakt, Mechelen is ook al redelijk goed in orde wat betreft de
binnenstad, maar die volledig laden is bijna niet te doen. Ik werk dan
alles alfabetisch af. (A*, B* , etc)

Ook al is Overpass net gemaakt om van die massieve queries aan te
kunnen, het is economischer en optimaler om het in stukjes te kappen.

Ergens tussenin ligt wss het meest optimale, een straat of 10,20 a 30
gok ik.  Je zal nooit klachten krijgen dat je teveel kleine queries doet
in alle geval.  De hoeveelheid ervan is minder van belang dan het
'gewicht' ervan.

Ik zal het toch eens bekijken of we het optimaler kunnen maken al zal
dat niet voor deze maand zijn.

Glenn


> In ieder geval, bedankt voor de moeite.
> 
> Sus
>  
> 
> 2017-02-14 19:44 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> On 14-02-17 18:40, Sus Verhoeven wrote:
> > Bedankt iedereen voor de snelle antwoorden waarvan er enkele boven
> mijn
> > petje gingen en vooral aan Glenn voor de aanpassing van de data; maar
> > uiteindelijk gaat het nog niet sneller. ;-(
> 
> Hi Sus,
> 
> Ik heb de duitse versie terug moeten aanzetten.  De Franse overpass
> service laat niet toe dat we deze gebruiken op de huidige manier.
> 
> Meer bepaald, CORS(*) restricties zijn van toepassing, zowel op de
> Russische als de Franse overpass service.
> 
> Volgens mij doe je toch teveel straten in 1 keer, als ik een straat of
> 10 filter dan komt het wel snel genoeg terug.
> 
> Vergeet niet dat dit een privelege is om hem te gebruiken, geen recht.
> Wij hebben de verantwoordelijkheid om er spaarzaam mee om te gaan, we
> betalen er geen bal voor.  Community sponsored dus.
> 
> Probeer uw straatlijst klein te houden ipv steeds ganse gemeente te
> analyseren.
> 
> Glenn
> 
> 
> * https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
> <https://en.wikipedia.org/wiki/Cross-origin_resource_sharing>
> 
> 
> >
> > Sus
> >
> > 2017-02-14 17:04 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>
> > <mailto:gl...@byte-consult.be <mailto:gl...@byte-consult.be>>>:
> >
> > Hallo
> >
> > In een van men vorige posts zei ik dat ik de tool niet vond om
> de data
> > te processen, maar niets was minder waar.  Alles was proper
> > gedocumenteerd, dus heb ik maar even een processing opgestart.
> >
> > Nieuwe CRAB data is processed en staat ter beschikking hier:
> > http://aptum.bitless.be/
> >
> > Pull request is ook aangemaakt , zie
> > https://github.com/aptum/aptum.github.io/pulls
> <https://github.com/aptum/aptum.github.io/pulls>
> > <https://github.com/aptum/aptum.github.io/pulls
> <https://github.com/aptum/aptum.github.io/pulls>> voor de status
> hiervan.
> >
> > Als deze wordt aanvaard en uitgerold wordt naar de originele
> site zal de
> > data ook hier te zien zijn later:
> > http://crab-import.osm.be/import.html
> <http://crab-import.osm.be/import.html>
> > <http://crab-import.osm.be/import.html
> <http://crab-import.osm.be/import.html>>
> >
> > Vergeet uw partner(s) niet vandaag met al die recente data
> >
> >
> > 
> >
> > Hello
> >
> > In one of my 

Re: [OSM-talk-be] CRAB tool data update - 2017-02-14

[Glenn Plas]

On 14-02-17 18:40, Sus Verhoeven wrote:
> Bedankt iedereen voor de snelle antwoorden waarvan er enkele boven mijn
> petje gingen en vooral aan Glenn voor de aanpassing van de data; maar
> uiteindelijk gaat het nog niet sneller. ;-(

Hi Sus,

Ik heb de duitse versie terug moeten aanzetten.  De Franse overpass
service laat niet toe dat we deze gebruiken op de huidige manier.

Meer bepaald, CORS(*) restricties zijn van toepassing, zowel op de
Russische als de Franse overpass service.

Volgens mij doe je toch teveel straten in 1 keer, als ik een straat of
10 filter dan komt het wel snel genoeg terug.

Vergeet niet dat dit een privelege is om hem te gebruiken, geen recht.
Wij hebben de verantwoordelijkheid om er spaarzaam mee om te gaan, we
betalen er geen bal voor.  Community sponsored dus.

Probeer uw straatlijst klein te houden ipv steeds ganse gemeente te
analyseren.

Glenn


* https://en.wikipedia.org/wiki/Cross-origin_resource_sharing


> 
> Sus
> 
> 2017-02-14 17:04 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> Hallo
> 
> In een van men vorige posts zei ik dat ik de tool niet vond om de data
> te processen, maar niets was minder waar.  Alles was proper
> gedocumenteerd, dus heb ik maar even een processing opgestart.
> 
> Nieuwe CRAB data is processed en staat ter beschikking hier:
> http://aptum.bitless.be/
> 
> Pull request is ook aangemaakt , zie
> https://github.com/aptum/aptum.github.io/pulls
> <https://github.com/aptum/aptum.github.io/pulls> voor de status hiervan.
> 
> Als deze wordt aanvaard en uitgerold wordt naar de originele site zal de
> data ook hier te zien zijn later:
> http://crab-import.osm.be/import.html
> <http://crab-import.osm.be/import.html>
> 
> Vergeet uw partner(s) niet vandaag met al die recente data
> 
> 
> 
> 
> Hello
> 
> In one of my latest posts I claimed to be lacking the proper tools to
> process the data but I was incorrect, everything was there to do this
> succesfully so I went ahead and started a processing job to create an
> update.
> 
> New CRAB data has been processed and is at your service using the
> following url : http://aptum.bitless.be/
> 
> A pull request has been created on github to feed those updates back to
> the original tool, once this has been processed and rolled out, the data
> should become available on the original site @
> http://crab-import.osm.be/import.html
> <http://crab-import.osm.be/import.html>
> 
> You can view the pull request status here:
> https://github.com/aptum/aptum.github.io/pulls
> <https://github.com/aptum/aptum.github.io/pulls>
> 
> Don't forget to buy your spouse flowers/beer depending on what works for
> you!
> 
> Mvg,
> 
> Glenn
> 
> 
> ___
> 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>
> 
> 
> 
> 
> ___
> 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] CRAB tool data update - 2017-02-14

[Glenn Plas]

Hallo

In een van men vorige posts zei ik dat ik de tool niet vond om de data
te processen, maar niets was minder waar.  Alles was proper
gedocumenteerd, dus heb ik maar even een processing opgestart.

Nieuwe CRAB data is processed en staat ter beschikking hier:
http://aptum.bitless.be/

Pull request is ook aangemaakt , zie
https://github.com/aptum/aptum.github.io/pulls voor de status hiervan.

Als deze wordt aanvaard en uitgerold wordt naar de originele site zal de
data ook hier te zien zijn later: http://crab-import.osm.be/import.html

Vergeet uw partner(s) niet vandaag met al die recente data




Hello

In one of my latest posts I claimed to be lacking the proper tools to
process the data but I was incorrect, everything was there to do this
succesfully so I went ahead and started a processing job to create an
update.

New CRAB data has been processed and is at your service using the
following url : http://aptum.bitless.be/

A pull request has been created on github to feed those updates back to
the original tool, once this has been processed and rolled out, the data
should become available on the original site @
http://crab-import.osm.be/import.html

You can view the pull request status here:
https://github.com/aptum/aptum.github.io/pulls

Don't forget to buy your spouse flowers/beer depending on what works for
you!

Mvg,

Glenn


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

Re: [OSM-talk-be] Agiv crap import

[Glenn Plas]

rgh.  Crap(b)!  Staat er wel los in beschreven, maar was te lui om
de readme te lezen.  extract.py is het script dat we nodig hebben.

https://github.com/aptum/aptum.github.io/

My bad. We kunnen dit dus zelf doen.  Als iemand zich geroepen voelt dit
even te doen, ik kan toegang geven tot een fork van crab tool (
https://github.com/gplv2/aptum.github.io/ ) en dan steek ik ze daar in
voorlopig.

Zelf heb ik vandaag te weinig tijd over om het nog te doen.

Glenn


On 14-02-17 15:49, Glenn Plas wrote:
> De json files die hiervoor nodig zijn worden door Sander gegenereerd en
> die scripts/tools steken niet in de GIT repository (voor zover ik kan
> zien) -> https://github.com/aptum/aptum.github.io/
> 
> Af en toe doe ik eens een 'git pull' om ze bij te werken maar er is idd
> al een hele tijd geen update meer gebeurd op die repository.
> 
> Indien ik die tools wel had zou ik ze kunnen aanmaken natuurlijk, maar
> voor dat stukje hangen we af van Sander.  Je kan hem mss best direct
> contacteren hiervoor, als hij dat dan in git steekt, dan komt het er bij
> mij ook uit.
> 
> Glenn
> 
> On 14-02-17 15:38, joost schouppe wrote:
>> Ik zie dat de CRAB data die aan de basis ligt van die site (volgens de
>> site zelf) van november 2015 is. Ik vind het redelijk pijnlijk dat we
>> data van een jaar en een paar maand oud gebruiken, terwijl de bron
>> dagelijks bijgewerkt wordt. "Adressen veranderen niet zo vaak" (ahum,
>> tot je met die data eens aan de slag gaat), maar er zijn ondertussen
>> geweldig veel fouten rechtgezet in de bron. In Antwerpen heb ik er het
>> meeste zicht op natuurlijk, maar hier hebben we volgens mij minstens
>> 1000 adressen verbeterd sinds die tijd. De data begint pas het laatste
>> jaar écht gebruikt te worden binnen de administratie, dus ik vermoed dat
>> er nog meer plaatsen zijn waar de datakwaliteit veel beter is dan in de
>> dump van november 2015.
>>
>> (uiteraard doen we geen blinde import enzo, maar waarom zou je niet
>> gewoon de beste versie van de data gebruiken?)
>>
>>
>> -- 
>> Joost Schouppe
>> OpenStreetMap
>> <http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter
>> <https://twitter.com/joostjakob> | LinkedIn
>> <https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
>> <http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>
>>
>>
>> ___
>> 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 crap import

[Glenn Plas]

De json files die hiervoor nodig zijn worden door Sander gegenereerd en
die scripts/tools steken niet in de GIT repository (voor zover ik kan
zien) -> https://github.com/aptum/aptum.github.io/

Af en toe doe ik eens een 'git pull' om ze bij te werken maar er is idd
al een hele tijd geen update meer gebeurd op die repository.

Indien ik die tools wel had zou ik ze kunnen aanmaken natuurlijk, maar
voor dat stukje hangen we af van Sander.  Je kan hem mss best direct
contacteren hiervoor, als hij dat dan in git steekt, dan komt het er bij
mij ook uit.

Glenn

On 14-02-17 15:38, joost schouppe wrote:
> Ik zie dat de CRAB data die aan de basis ligt van die site (volgens de
> site zelf) van november 2015 is. Ik vind het redelijk pijnlijk dat we
> data van een jaar en een paar maand oud gebruiken, terwijl de bron
> dagelijks bijgewerkt wordt. "Adressen veranderen niet zo vaak" (ahum,
> tot je met die data eens aan de slag gaat), maar er zijn ondertussen
> geweldig veel fouten rechtgezet in de bron. In Antwerpen heb ik er het
> meeste zicht op natuurlijk, maar hier hebben we volgens mij minstens
> 1000 adressen verbeterd sinds die tijd. De data begint pas het laatste
> jaar écht gebruikt te worden binnen de administratie, dus ik vermoed dat
> er nog meer plaatsen zijn waar de datakwaliteit veel beter is dan in de
> dump van november 2015.
> 
> (uiteraard doen we geen blinde import enzo, maar waarom zou je niet
> gewoon de beste versie van de data gebruiken?)
> 
> 
> -- 
> 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] Agiv crap import

[Glenn Plas]

Sus,

Ik heb een mirror van de aptum tool staan hier :

http://aptum.bitless.be/

Deze gebruikt de franse Overpass API nu.  Hopelijk helpt dit

Mvg,

Glenn


On 14-02-17 12:56, Sus Verhoeven wrote:
> Hooi,
> Sinds enkele tijd is de Agiv crab import heel pijnlijk, heel traag en
> soms loopt het mis.
> Is de overpass server te zwaar belast of Is daar wat 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

Re: [OSM-talk-be] Agiv crap import

[Glenn Plas]

Gebruik je straatfilters ?   Als je die niet aanzet (wildcard) is de
overpass query gigantisch.

Ik raad je aan om die steeds op te zetten, dan vliegen ze binnen

Glenn


On 14-02-17 12:56, Sus Verhoeven wrote:
> Hooi,
> Sinds enkele tijd is de Agiv crab import heel pijnlijk, heel traag en
> soms loopt het mis.
> Is de overpass server te zwaar belast of Is daar wat 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

Re: [OSM-talk-be] Namen van kerken

[Glenn Plas]

Hallo,

Volledig atheïst hier, maar vergeet niet dat buiten kerken en
kathedralen ook nog concepten bestaan zoals een basiliek.  Daarom vind
ik het woord kerk niet onbelangrijk.

bv: https://nl.wikipedia.org/wiki/Onze-Lieve-Vrouw_van_Hanswijk_(Mechelen)



On 06-02-17 09:04, joost schouppe wrote:
> Gerard, ik ben niet bepaald katholiek, maar ik denk dat het woord kerk
> in de naam wel degelijk betekenis heeft. Ik stel mij voor dat ze hier
> systematisch het woord "kerk" gebruiken om aan te duiden dat het om een
> "parochiekerk" gaat, en dus duidelijk geen kapel of kathedraal.
> 
> Op 6 februari 2017 om 08:35 schreef Gerard Vanderveken  >:
> 
> Goedendag,
> 
> Iedereen gaat in zijn dorp naar "de kerk" en het gebouw staat
> alsdusdanig bekend, maar dat is voor mij geen alt name.
> Voor mij dient er helemaal geen kerk in de naam te staan. Gewoon de
> patroonheilige is voldoende: dus Heilige Familie of Sint-Bavo.
> Dat het een kerk is zie je aan het gebruikte symbool of de rest van
> de data.
> 
> Met vriendelijke groeten ,



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

Re: [OSM-talk-be] Overpass mirror uit sync?

[Glenn Plas]

On 01-02-17 10:37, Karel Adams wrote:
> Mijn dagelijkse download van de Europese luchtvaartterreinen sprak
> altijd  http://overpass-api.de/api/interpreter aan, maar die heeft het
> dikwijls te zwaar, zelfs nadat ik de query heb opgesplitst in zes delen.
> 
> Ik had dan maar het scriptje aangepast zodat het
> http://api.openstreetmap.fr/oapi/interpreter aanspreekt, maar deze is nu
> al bijna een week uit sync, recente wijzigingen zijn er niet in terug te
> vinden.
> 
> Of doe ik iets mis? Maar het heeft altijd gewerkt... Hieronder het
> script dat ik gebruik
> 
> Zijn er problemen gemeld/bekend met de Franse mirror?
> 
> Was er niet een mirror in Rusland ook, die ik kan aanspreken?

Gans onderaan op deze pagina, status + urls te vinden:


http://wiki.openstreetmap.org/wiki/Platform_Status

Als ik een hint mag geven over performance, je kan best jouw 3 queries
in een union steken, bv dit ongeveer:


  
 
  


  
 


 
 


 
 
 


dit zou een pak sneller moeten draaien als ik het goed heb, en dezelfde
resultaten tonen.

Mvg,

Glenn

> 
> Karel
> 
> 
> 
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
>  
> 
> 
> 
> ___
> 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] Wat mappen in Brussel (was Re: Bulk import, mogelijkheden?)

[Glenn Plas]

On 31-01-17 13:39, Ben Laenen wrote:
> On Tuesday, 31 January 2017 13:14:37 CET Glenn Plas wrote:
>>>> Neen, bvb op het viaduct van Vilvoorde mogen personenwagens 90 km/u en
>>>> vrachtwagens slechts 70 km/h.
>>>
>>> Maar daar staan dan altijd extra verkeersborden, die we uiteraard wel
>>> mappen.
>> Ik zou die wel eens graag willen zien, volgens mij zit in OSM bijna
>> niets als het gaat over locale snelheidsbeperkingen voor een bepaalde
>> manier van transport, buiten de wagen om.  Bitter weinig aanwezig.
>> idealistisch gezien mappen we idd we de verkeersborden, maar in de
>> praktijk zijn ze amper gemapt.
> 
> Of ze in OSM zitten is een andere vraag, maar een extra snelheidsbord met 
> daaronder een onderbord zoals "+3.5t" (of "+7.5t" of dergelijke) bestaat wel 
> meer in dit land.
> 
> En dit staat er op het viaduct in Vilvoorde:
> https://www.mapillary.com/map/im/8RahppbFJDuIl2_dI51kgA
> 
> 
>>> En die 70 daar is niet enkel voor vrachtwagens, maar alles boven 3.5 ton
>>> (als ik me goed herinner).
>>
>> Vind ik niet echt relevant, het punt is dat voor bepaalde voertuigen
>> andere regels gelden.
> 
> Ik denk dat ik niet echt duidelijk heb gemaakt wat ik wou zeggen.
> 
> Het punt is dat sommige voertuigen sowieso niet sneller mogen dan een 
> bepaalde 
> snelheid in dit land, en dat je die extra beperking niet overal moet gaan 
> mappen op plaatsen waar de normale snelheid toevallig hoger ligt.
> 
> Maar als ervan wordt afgeweken naar lagere snelheden zoals het viaduct in 
> Vilvoorde dan moeten die uiteraard wel gemapt worden.
> 
> Wat ik niet wil is dat heel het land binnenkort volledig wordt gemapt met een 
> extra "maxspeed:goods:conditional=90 @ (weight>3.5)" (of wat het wettelijk 
> ook 
> juist is) op de plaatsen waar geen extra verkeersborden staan. Een 
> bromfietser 
> klasse B mag ook maar maximum 45 en dat gaan we ook niet op elke weg in het 
> land zetten.


Yup, met deze opheldering ben ik akkoord, spreekt voor zich dat het
enkel bij uitzondering nodig is, op de autostrades staat ook maar heel
af en toe een indicatie van de maximumsnelheden van zwaar vervoer (bij
de grens bv)

We mappen dat niet overal, enkel de algemene max snelheden, by default:
de wagen.

Glenn



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

Re: [OSM-talk-be] Wat mappen in Brussel (was Re: Bulk import, mogelijkheden?)

[Glenn Plas]

>> Neen, bvb op het viaduct van Vilvoorde mogen personenwagens 90 km/u en
>> vrachtwagens slechts 70 km/h.
> 
> Maar daar staan dan altijd extra verkeersborden, die we uiteraard wel mappen.

Ik zou die wel eens graag willen zien, volgens mij zit in OSM bijna
niets als het gaat over locale snelheidsbeperkingen voor een bepaalde
manier van transport, buiten de wagen om.  Bitter weinig aanwezig.
idealistisch gezien mappen we idd we de verkeersborden, maar in de
praktijk zijn ze amper gemapt.

> En die 70 daar is niet enkel voor vrachtwagens, maar alles boven 3.5 ton (als 
> ik me goed herinner).

Vind ik niet echt relevant, het punt is dat voor bepaalde voertuigen
andere regels gelden.

> 
> Er zullen naast vrachtwagens nog wel andere voertuigen zijn die maar 90 of 
> een 
> andere snelheid mogen rijden uit technische overwegingen, we kunnen niet heel 
> België vol zetten met al die mogelijke beperkingen, die eigenlijk van het 
> voertuig afhangen en niet van de weg.

Die hangen af van de combinatie van het voertuig EN de situatie ter
plekke. (bv: wegenwerken, maximum gewicht, toestand wegdek, weer, zeer
scherpe bocht, omleidingen )...

Jij heb het over de maximum snelheden mogelijk/wettelijk per voertuig,
en dat is niet hetzelfde als een locale 70Km/h beperking voor zwaar
transport op plaats X, Y of Z , met hier als voorbeeld het viaduct van
Vilvoorde.

En we doen het wel hee: heel ons land vol beperkingen zetten, als dit in
het echt mogelijk is, is dit wel in een database mogelijk.

Het is net hetzelfde als een straat waar bv +5T verboden is in te
rijden, auto's niet en fietsers ook niet.   Wil je dit weergeven in OSM,
moet je dit mappen want louter afgaan technische
overwegingen/beperkingen van een voertuig helpt je niet vooruit om te
weten wat je mag/kan rijden.

Glenn

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

Re: [OSM-talk-be] why welcoming makes sense

[Glenn Plas]

On 27-01-17 09:06, joost schouppe wrote:
> Well, it goes to show that checking every single first changeset from
> new contributors is useful. And the best tracking tool is welcome.osm.be
>  IMHO.

It's not limited to newbee's ... Check leisure park-use in centre of
Brussels: http://overpass-turbo.eu/s/lxP

a stretch of grass doesn't make it a park me thinks.

Glenn


> 
> (you could use http://neis-one.org/2016/01/suspicious-osm/ and add
> something like #reviewed in a changeset comment)
> 
> Op 27 januari 2017 om 08:56 schreef Marc Gemis  >:
> 
> Pokemon Go  users die denken/hopen/weten dat zo'n park een "nest" geeft.
> 
> 2017-01-27 8:53 GMT+01:00 Georges De Gruyter  >:
> > Dat is al een hele tijd bezig hoor.  Het is dweilen met de kraan
> open :(
> >
> > Georges
> >
> >
> >
> > Op 27-jan.-2017, om 08:49 heeft joost schouppe
> >
> > het volgende geschreven:
> >
> > Because in the process, you'll find beautiful nonsense like this:
> >
> >
> > https://www.openstreetmap.org/way/469253289/history
> 
> >
> >
> >
> >
> > --
> > Joost Schouppe
> > OpenStreetMap | Twitter | LinkedIn | Meetup
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
> 
> >
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
> 
> >
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> 
> -- 
> 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] (no subject)

[Glenn Plas]

On 13-01-17 17:52, Jasper Michels wrote:
> Dank voor je antwoord Marc!
> 
> -Gevoelsmatig vind ik de tag "scrub" te veel eer doen aan de struikjes
> tussen de autostrades met zwerfvuil.
>  Als ik in google afbeeldingen zoek op "scrub terrain" dan krijg ik toch
> iets mooiere landschappen te zien.

Schoonheid is zeer subjectief van criteria.  Een lelijke auto is
nogaltijd een auto.

> 
> -Ik ben zo iemand die momenteel elk rijtje bomen als forest map. 

is nochthans een andere voor :
https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

> Indien de maprendering niet wijzigd zal ik dit ook niet veranderen. Indien dit
> wel moet zal ik vrees ik snel de zin om dit te mappen verliezen.

Taggen voor de renderer is een slecht idee.  (voor 1 welbepaalde dan nog)

> (resultaat naar werk is bij mij nodig)

Het resultaat reken je toch niet af op de render stijl van standaard OSM
tegels?   Maak je eigen kaart, render hoe je wil.

>  Van zodra men ook de landcover zou renderen, is dit een ander verhaal.


> 
> -Het ideale geval van de 3 polygonen boven één ben ik volledig akkoord mee.
>  Zolang men de landcover niet rendert is dit echter onmogelijk. Indien
> we masaal landuse vervangen door landcover zal de kaart al maar witter
> worden. (ik weet dat we niet mogen mappen voor de kaart, maar niet
> iedereen is  een medogenloze databese-addict...)

Heeft er niks mee te maken hoe addict je bent, je kan beter lobbyen om
landcover te ondersteunen, eventueel zelf in de tagging lijst discussies
gaan mengen.

Massaal vervangen is al evengoed slecht idee trouwens, dus gaan we
gewoon niet doen


Glenn


> 
> Op 13 januari 2017 om 17:39 schreef Sus Verhoeven  >:
> 
> Of niet meer durven mappen. ;-)
> 
> Sus
> 
> 
> 2017-01-13 16:55 GMT+01:00 Santens Seppe  >:
> 
> Even binnenkijken in Marc zijn diepste zielenroerselen :-)
> Maar wel een erg nuttige uitleg vind ik, bedankt! En nu nog
> alles verbeteren wat we ooit verkeerd gemapt hebben :-)
> 
> Seppe
> 
> -Oorspronkelijk bericht-
> Van: Marc Gemis [mailto:marc.ge...@gmail.com
> ]
> Verzonden: vrijdag 13 januari 2017 14:14
> Aan: OpenStreetMap Belgium
> Onderwerp: [OSM-talk-be] (no subject)
> 
> Sorry voor de lange mail, maar het is toch slecht weer, dus heb
> je wat om te lezen :-)
> 
> Jasper,
> 
> De oorspronkelijke betekenis van landuse=forest was een
> bosgebied waarvan het hout gekapt wordt voor industriële
> doeleinden (bosbouw).
> Daarnaast had je natural=wood voor natuurlijk, niet onderhouden bos.
> Omdat het meeste bos hier niet meer natuurlijk is, maar
> aangeplant en onderhouden zijn meer mensen landuse=forest
> beginnen gebruiken. Hoewel niet elk onderhouden bos echt voor
> bosbouw is.
> 
> Verder plakken sommige mappers gewoon op alles wat op een
> luchtfoto op een groepje bomen lijkt als landuse=forest. Er is
> geen echte tag voor een groepje bomen.
> 
> Het volgende probleem is dan dat ook bosjes, zonder echte bomen
> maar met grote struiken via luchtfoto's als landuse=forest
> worden gemapped.
> 
> Dit laatste kan je verhelpen door natural=scrub te gebruiken,
> ook voor struiken in meer stedelijke gebieden, ik denk dus ook
> voor het stukje grond dat jij aangeeft. scrub wordt ook wel als
> struikgewas of kreupelhout vertaalt (google translate). Dus dat
> pas wel.
> 
> Dus in jouw geval zou natural=scrub beter zijn dan
> landuse=forest , toch als er meer struiken zijn dan bomen. Maar
> wat als er dan toch wat onderhoud aan te pas komt ?
> 
> Voor je golf terrein, de belangrijkste tag daar is  leisure=golf
> natuurlijk. Ik zou nu voor landcover=trees gaan. Het is helemaal
> geen bosbouw, noch een bos. Dat het niet op de standaard kaart
> komt, het zij zo. Als er genoeg landcover tags gebruikt worden,
> gaan ze die ook wel tonen.
> 
> Over het verschil tussen landcover=grass en landuse=grass
> Landuse zou het gebruik van het land moeten aangeven. Hier wonen
> mensen, hier werken ze, hier wordt gerecreëerd, hier wordt aan
> landbouw of veeteelt gedaan, enz.
> Maar wat is "hier wordt aan gras gedaan" ? Vandaar dat
> landuse=grass niet echt juist is, misschien enkel voor gebieden
> waar graszodes geteeld worden. Maar omdat het op de kaart
> getoond wordt, zie je landuse=grass overal verschijnen. (ipv het
> correctere landcover=grass)
> 
> Landcover slaat op wat je op de grond vindt.
> 
> Volgens mij moet in een ideale OSM map, elke plek op aarde [1]
> tot 2 polygonen behoren:
> eentje met een 

Re: [OSM-talk-be] Fwd: Fietsroutedata OSM

[Glenn Plas]

Als ik die data kan krijgen en ze in postgresql kan steken, dan stel ik
graag die laag ter beschikking.  Kan je ze alvast als overlay gebruiken.

Kan het als vector layer gemakkelijk exporteren voor vrij gebruik.

Glenn

> 
> ​1)In juni jongstleden hebben alle Vlaamse provincies samen een
> samenhangend coherent *fietssnel*wegen-netwerk
>  met aangepaste layout (bijv. voor
> bewegwijzering, geleiding enz) voorgesteld ... ditpast in de vernieuwde
> filosofie dat fietsen (en zeker de (snelle) e-fietsen) voor langere
> afstanden kunnen gebruikt worden ...
> Ook al is dit netwerk nog niet volledig gerealiseerd (grosso modo
> 1200 km van de 2400 km), vraag ik me af of het niet geïntegreerd kan
> worden in de fietslaag
> van OSM ...
> 

...

> ) Ik zit op een berg aan gps-getagde foto's van doorsteken/trage
> wegen/jaagpaden/fietssnelwegen in eigen bedding/parken die op street
> view niet te zien zijn ... Zouden we die op één of andere manier via de
> fietslaag van OSM ter beschikking kunnen stellen?
>



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

Re: [OSM-talk-be] Hoe een onbestaande opslagplaats definieren

[Glenn Plas]

On 29-12-16 12:12, Marc Gemis wrote:
> building=warehouse, not building=hangar ! Ik weet dat we in het
> Nederlands/Vlaams over hangar/hangaar spreken, maar we mappen in het
> Brits-Engels :-)

Yup, ik realiseer me nu dat ik wel wat te verbeteren heb.  voor GRB
integratie en wat ik in het verleden als hangar heb gemapt. :(


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

Re: [OSM-talk-be] Hoe een onbestaande opslagplaats definieren

[Glenn Plas]

Vliegtuig:  aeroway=hangar

https://wiki.openstreetmap.org/wiki/Key:aeroway

Algemeen:  building=hangar

De wiki definitie verbaasd me wel persoonlijk:

"A hangar is a building used for the storage of airplanes, helicopters
or space-craft. Consider adding aeroway=hangar, when appropriate."

een grote opslaghal, los van wat er in zit zou bij mij sowieso een
hangar worden.

landbouwmachines is idd building=farm_auxiliary

etc.



On 29-12-16 10:27, Jakka wrote:
> Hoi,
> Hoe, uit wat wordt een tag (key en value) gedestilleerd om een gebouw
> opslagplaats te definiëren met een specifiek karakter vb opslagloods
> voor boten. (deze nu nodig) of motorfietsen en andere
> auto's hebben garage(s)
> vliegtuigen hangar
> landbouwmachines op boerderij farm_auxiliary
> 
> thx
> 
> 
> ___
> 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] Lightmap

[Glenn Plas]

On 26-12-16 14:12, Philippe Casteleyn wrote:
> 
> 
> Het is nuttiger die tag in te vullen bij fietsstallingen en fietspaden.
>  Aan de kathedraal in Mechelen bijvoorbeeld is er een fietsstalling waar
> je op de tast uw sleutel in uw fietsslot moet steken.
> En dan vergeet ik nog de zebrapaden, allemaal nuttige dingen.

Het zou leuk zijn dat die dan ook werkelijk branden, en dat doen ze niet
altijd hier, sinds een paar jaar worden er 's nachts, voornamelijk op
snelwegen de lichten uitgedaan behalve aan op/afritten.

Dus lit=yes wil niet zeggen dat ze branden wanneer je het verwacht.  In
die zin vind ik lit niet zo een bruikbare tag.  Tijdsindicaties erbij
zou al heel wat goed maken en/of concepten zoals schemerschakeling etc.

Glenn


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


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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

[Glenn Plas]

On 22-12-16 23:18, Marc Gemis wrote:
> On Thu, Dec 22, 2016 at 10:54 PM, Glenn Plas <gl...@byte-consult.be> wrote:
>> Sometimes it's better to actually get a changeset dropped instead of
>> using the plugin.
> 
> I believe this can only done by the DWG and is only used in case of
> data that violates a license or for sensistive data. Never for
> vandalism or other mistakes.

Correct, you need to contact DWG for such cases.   And I believe Ben
Abelshausen is the DWG's primary contact, so passing this by him is
probably a good idea as well.

> 
> Furthermore the data is not deleted from any dataset that was taken
> from the main server before the "purge" is done. Not everybody
> realizes this (although I know Glenn does)

Like -every- preceding mapping mistake :)   Probably won't be an issue
for most consumers.

Glenn


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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

[Glenn Plas]

On 22-12-16 19:57, Marc Gemis wrote:
> Depending on the case, you can immediately revert the change (e.g.
> with the revert plugin in JOSM), 

Keep in mind this is not taking away the changeset, it's just doing the
reversal but in a forward fashion.  It's not a real revert, just a way
to nullify the changes by applying the reverse actions.

Sometimes it's better to actually get a changeset dropped instead of
using the plugin.

That being said, always start with comments to get a better idea of the
situation you're trying to solve.

Glenn

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

Re: [OSM-talk-be] Aanpassingsmeldingen / Notifications

[Glenn Plas]

On 22-12-16 19:44, Steven Clays wrote:
> Thanks! Is there a procedure for reverting outright errors or sabotage?
> Can I do this myself?
> (To be clear: it is a hypothetical question, untill now it did not happen!)

To revert changes you have a few options:

 - Use the revert plugin (which restores rather than reverts a
changeset).  It's hard to use on ages edit's.  You need to use conflict
resolution in JOSM and that's not easy.
 - Report the malicious edit to get it reverted.

You can find more info here https://wiki.openstreetmap.org/wiki/Vandalism

Glenn

> 
> 2016-12-22 19:15 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> On 22-12-16 17:36, Steven Clays wrote:
> > Hallo,
> >
> > dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
> > nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> > de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
> > zelf hebt toegevoegd?
> >
> > This is perhaps a basis question, but I cannot immediately find an
> > answer. Is there any possibility to get a notification when somebody
> > edits a feature / geometry / tag / / ... you submitted earlier?
> 
> you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
> last objects your target has touched.  WhoDidIt uses a bounding box area
> you wish to monitor.  Very handy.  That's how I keep track of a few
> large areas.
> 
> I recommend using an RSS feed reader (thunderbird for example) for both.
>  They both support getting this using RSS
> 
> Glenn
> 
> 
> [1] http://osmose.openstreetmap.fr/en/byuser/
> <http://osmose.openstreetmap.fr/en/byuser/>
> [2] http://zverik.osm.rambler.ru/whodidit/
> <http://zverik.osm.rambler.ru/whodidit/>
> >
> > Merci voor het antwoord!
> > Thanks for helping me out!
> >
> > Steven
> >
> >
> > ___
> > 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>
> >
> 
> 
> ___
> 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>
> 
> 
> 
> 
> ___
> 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] Aanpassingsmeldingen / Notifications

[Glenn Plas]

On 22-12-16 17:36, Steven Clays wrote:
> Hallo,
> 
> dit is misschien een beetje een basisvraagje, maar ik vond het antwoord
> nergens. Is er een mogelijkheid om op de hoogte gehouden te worden van
> de aanpassingen die een andere gebruiker maakt aan de wijzigingen die je
> zelf hebt toegevoegd?
> 
> This is perhaps a basis question, but I cannot immediately find an
> answer. Is there any possibility to get a notification when somebody
> edits a feature / geometry / tag / / ... you submitted earlier?

you can use Osmose [1] and WhoDidIt [2].   Osmose tracks errors on the
last objects your target has touched.  WhoDidIt uses a bounding box area
you wish to monitor.  Very handy.  That's how I keep track of a few
large areas.

I recommend using an RSS feed reader (thunderbird for example) for both.
 They both support getting this using RSS

Glenn


[1] http://osmose.openstreetmap.fr/en/byuser/
[2] http://zverik.osm.rambler.ru/whodidit/
> 
> Merci voor het antwoord!
> Thanks for helping me out!
> 
> Steven
> 
> 
> ___
> 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] Belgium maxheight railway=level_crossing

[Glenn Plas]

On 22-12-16 14:19, Jakka wrote:
> Rechtzetting, deze opmerkingen tot plaatsen lijkt overbodig daar de wet
> in België bepaalt de de maximale lading in hoogte de 4 meter niet mag
> overschrijden. De ongevallen incidenten zijn oorzaak van nalatigheid
> kraan/laadbak omhoog en gebruik of lading normen.

Wettelijk oversized transport vind deze indicaties nog steeds handig om
te weten.

Maximale lading is idd wel 4 meter maar een brug is niet altijd vierkant
dus met te weten hoe hoog ze is het midden kunnen chauffeurs beter
inschatten of ze onder eventuele bogen kunnen rijden.  Vlak voor men
deur ligt zo een brug, daar is deze zomer nog tegen gereden.  Midden is
wel 4m hoog, maar aan de kanten niet.

> 
> Correction: semble superflu puisque la loi en Belgique, la charge ne
> doit pas dépasser la hauteur maximale de 4 mètres ces observations
> lieux. Les incidents sont des accidents causés par la négligence grue /
> camion et l'utilisation ou les normes de chargement.
> 
> Op 22/12/2016 om 11:31 schreef Jakka:
>> Hoi,
>> Naar aanleiding recent incident lijn Oudenaarde: Vrachtwagen rukt
>> bovenleiding af.(3)
>> Zouden we niet standaard voor België de maxheight op stukje highway
>> zetten op plaats van OW trein overweg met bovenleiding?
>> Moeilijker maar niet onmogelijk voor steden met tramleidingen ?(4)
>> Wiki (toevoeging?) is er geen sprake van maxheight aan overwegen waar
>> bovenleiding aanwezig is.(1)(1a)
>> Daar is standaard de hoogte beperkt om 4.5 meter controle portieken (2)
>>
>> (online translate)
>> En raison de l'incident récent à Oudenaarde:le caténaire arracher...(3)
>> Mettre standard le maxheigt en Belgique sur morceau highway sur le
>> passage a niveau qui à une ligne électrifié ?
>> Plus difficile mais faisable les rues avec tram?(4)
>> Les wikis (ajouter ?) rien trouver (1)(1a)
>> Le maxheight standard serai 4.5 m portiek de securité/controle (2)
>>
>> (1) http://wiki.openstreetmap.org/wiki/Key:maxheight
>> (1a) http://wiki.openstreetmap.org/wiki/Tag:railway%3Dlevel_crossing
>> (2) Zie
>> https://www.infrabel.be/nl/chauffeurs-sensibiliseren-rond-afgerukte-bovenleidingen
>>
>>
>> (3)
>> http://www.hln.be/hln/nl/957/Binnenland/article/detail/3034585/2016/12/19/Truck-beschadigt-bovenleiding-geen-treinen-tussen-Kortrijk-en-Oudenaarde.dhtml
>>
>>
>> (4)
>> http://www.hln.be/hln/nl/957/Binnenland/article/detail/2624386/2016/02/22/Tramverkeer-in-Antwerpen-verstoord-door-losgerukte-bovenleiding.dhtml
>>
>>
> 
> 
> 
> ___
> 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 hackday december 11th

[Glenn Plas]

On 15-12-16 05:44, Marc Gemis wrote:
> I'm really looking forward to read the procedure on how you guys came up.
> You might have been lucky that I couldn't make it , now you only have
> to ignore my annoying mails :-)

No, not at all.  The church-issue was brought up without your help :)

> I fail to see how documentation will prevent any participant from just
> dumping the data from GRB into OSM without any check what so ever. The
> same happened in The Netherlands where destroyed buildings were still
> imported and not-yet existing house numbers where dumped in the dunes.

The rule is you need to use the plugin to merge geometries, like this no
history will be deleted , hence you can roll those back.  But we aggree
you need some kind of formal training before getting unleashed on the
data.  So we will give workshops etc, possibly hangouts.

> A model import does not introduce errors that could be avoided by
> simply looking at aerial imagery

Does, or does not ?

> 
> I've been working almost daily with the GRB data now for 6 months (*)
> or so and have a pretty good idea how much work it takes to make this
> a model import. I fail to see how 20-25 people can accomplish this is
> a year, unless they really spend a lot of hours on it.

I did Stekene and surroundings in a month (pretty large part in fact).
It goes really fast when there are no houses yet, where buildings exist
it will go a bit slower.   But it's not an import, the end result needs
to be better than OSM and GRB seperately, it will be if we do it right.

> But I am probably to critical right now and have to see what process /
> documentation you guys came up with.
> 
> so I shut up now and wait

Think I asked for feedback on plenty of occasions, consider your job is
well done and I prefer an early critic over a late one :)

Glenn



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

Re: [OSM-talk-be] GRB hackday december 11th

[Glenn Plas]

On 14-12-16 20:55, Marc Gemis wrote:
> On Wed, Dec 14, 2016 at 8:49 AM, joost schouppe
>  wrote:
>> Expect between 10 and 20 users for the import tool. I think we can handle a
>> little ugliness.
>> So something "not too bad" will do :)
>>
>> That said, if it all goes as planned, we will be doing a "model import". So
>> I think the work on
> 
> A model import of this size and data quality with only 10-20 users ?
> You must be kidding :-)

Sure, I would to it alone in 6Months in madness mass-mode approach.  In
Escada approach with eye for detail and survey  information it would
take a lot but there is not due date planned.  It's not an import, its a
merge tool.

> Without involvement of really local mappers (1 per village), it is
> IMHO impossible to bring the GRB data up to  level that is needed for
> a "model import".
> 
> As you might know, everything with an address is categorized as house,
> everything without as shed.  While this is a choice that Glenn made,
> there are only 2 categories you can start from. There are also roofs
> and some buildings are known as industrial (substations for
> electricity), but that does not help with the issue.

It's not a choice by me, it's a source data driven decision , you can't
make up 5 categories when the source is only 2 big.  But we actually
discussed what we will do with those cases and explained why it is what
it is.  There are plenty of solutions for these cases but since it's a
merge tool you're discussion a well balanced/chosen default based on the
source data, we can/will modify that a bit, there are a few new ideas
now since sunday. But all in all, this is a default, you get the merge
windows which is basically what a mapper does: make informed decisions
with a certain amount of local knowledge.


> 
> So even churches are marked as shed. While this type of correction is
> easy, it might easily be skipped (see Urbis import). However, try to
> recognize apartments, retail vs. commercial, warehouse vs. industrial,
> shed vs. garage (next to house), civic, barns vs. stables vs
> farm_auxilairy etc. buildings based on aerial imagery.

Yes, again, we have discussed this and we have a solution for this, this
hackaton was exactly for bringing this up, you are a power user but you
missed the meeting unfortunately, it happens but now I feel like again
we need to discuss this, we are aware of the issues but we have brained
together solutions for this.

> 
> Unless many, many more mappers get involved in the process, this will
> not be a model import in my eyes, simply because too many buildings
> that are not house/shed will be mapped as such.

20 mappers you can do Belgium in a single year.  Not every mapper is
going to work as detailed as you , but for GRB we need it to be done well.


> 
> BTW, this has nothing to do with the import tool, which even in it's
> current version is good to support local mappers. The main benefit is
> that you do not have to draw the buildings yourself or add the
> addresses. That's already done, changing the building type based on
> ones observations is easy.
> 
> So I really hope that the people involved in the import realize that
> improving the data before uploading is much more important that having
> an exact copy of GRB data in OSM.


Yea, I really missed you there Marc,  you would have been an asset.  You
have good input but missed the party this time.  We know it's not easy
to make it sometimes but give us some time to document things and then
give your feedback again on those solutions.


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

Re: [OSM-talk-be] GRB hackday december 11th

[Glenn Plas]

Hey Jonathan,

On 13-12-16 17:05, Jonathan Beliën wrote:
> Hi Glenn,
> 
> We didn't really discuss about that last Sunday but I'll be happy to help 
> with PHP/JAVASCRIPT/HTML/CSS !

Thanks Jonathan, we seem to share a lot of interests (*) ;-)

I didn't really yell for help on Sunday, probably should have.  I will
send you the details asap and where I'm at.  It would be awesome to not
have to worry about GUI stuff, I'm not a artistic person, I'm visually
challenged in CSS.

Glenn

* : http://bricks.stackexchange.com/users/1122/glenn-plas

> 
> Good afternoon.
> 
> Jonathan Beliën
> 
> -Message d'origine-
> De : Glenn Plas [mailto:gl...@byte-consult.be] 
> Envoyé : mardi 13 décembre 2016 16:44
> À : OpenStreetMap Belgium
> Objet : Re: [OSM-talk-be] GRB hackday december 11th
> 
> On 13-12-16 14:18, Santens Seppe wrote:
>> Looking forward to it!
>>
>> I had a quick look at the documentation and tried the tools, but I 
>> don’t feel confident enough to have a go at it. A short training would be 
>> nice.
> 
> The tool will also be updated before we start, since it's a R version right 
> now.  A v2 version is on the way, the source code is public too.
> It will be a lot more user-friendly, less-nerdy.  I'm about halfway through 
> merging functionalities.
> 
> We will organise workshops to get everyone aligned.  The meeting was quite 
> productive and rather fast as well.  We have a main strategy and 2 backup 
> strategies to get this proposal accepted.
> 
> Looking at my schedule, it will probably be ready mid januari but I'm swamped 
> in paid work so this target is optimistic.  with all the festivit
> 
> If anyone who knows some php/javascript/css (or even the Laravel
> framework) and you want to help, please contact me and I will get the ball 
> rolling.  I could use a CSS expert to assist me in making it pretty and 
> functional on the GUI side.
> 
> Thanks for the patience and also thanks for showing restraint in importing 
> data when you are not sure, it's an excellent decision in the context and 
> timing of this project.
> 
> 
> Glenn
> 
>>
>>  
>>
>> Seppe
>>
>>  
>>
>> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
>> *Verzonden:* dinsdag 13 december 2016 14:10 *Aan:*OpenStreetMap 
>> Belgium
>> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
>>
>>  
>>
>> We are working on a blogpost... :-)
>>
>>  
>>
>> Met vriendelijke groeten,
>> Best regards,
>>
>> Ben Abelshausen
>>
>>  
>>
>> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis <marc.ge...@gmail.com 
>> <mailto:marc.ge...@gmail.com>> wrote:
>>
>> Any chance we see a list of accomplishments somewhere ?
>>
>> regards
>>
>> m
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org <mailto:Talk-be@openstreetmap.org>
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>  
>>
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> 
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
> 


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

Re: [OSM-talk-be] GRB hackday december 11th

[Glenn Plas]

On 13-12-16 14:18, Santens Seppe wrote:
> Looking forward to it!
> 
> I had a quick look at the documentation and tried the tools, but I don’t
> feel confident enough to have a go at it. A short training would be nice.

The tool will also be updated before we start, since it's a R version
right now.  A v2 version is on the way, the source code is public too.
It will be a lot more user-friendly, less-nerdy.  I'm about halfway
through merging functionalities.

We will organise workshops to get everyone aligned.  The meeting was
quite productive and rather fast as well.  We have a main strategy and 2
backup strategies to get this proposal accepted.

Looking at my schedule, it will probably be ready mid januari but I'm
swamped in paid work so this target is optimistic.  with all the festivit

If anyone who knows some php/javascript/css (or even the Laravel
framework) and you want to help, please contact me and I will get the
ball rolling.  I could use a CSS expert to assist me in making it pretty
and functional on the GUI side.

Thanks for the patience and also thanks for showing restraint in
importing data when you are not sure, it's an excellent decision in the
context and timing of this project.


Glenn

> 
>  
> 
> Seppe
> 
>  
> 
> *Van:*Ben Abelshausen [mailto:ben.abelshau...@gmail.com]
> *Verzonden:* dinsdag 13 december 2016 14:10
> *Aan:*OpenStreetMap Belgium
> *Onderwerp:* Re: [OSM-talk-be] GRB hackday december 11th
> 
>  
> 
> We are working on a blogpost... :-)
> 
>  
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
>  
> 
> On Tue, Dec 13, 2016 at 1:54 PM, Marc Gemis  > wrote:
> 
> Any chance we see a list of accomplishments 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
> 


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

Re: [OSM-talk-be] Stylesheets in JOSM Overpass

[Glenn Plas]

On 19-11-16 16:38, Marc Gemis wrote:
> Het was me op het forum ook al niet duidelijk wat je wil bereiken.

Ik begin te vermoeden dat wij het over MapCSS in JOSM hebben terwijl
Phillippe vooral met Overpass MapCSS bezig is.  Het 2de is complexer dan
gewoon in JOSM even wat stijlen uitproberen.

Phillippe, leg eens goed uit wat je probeert te bereiken, met naam en
toenaam en dan komen we er wel uit.

Mg,

Glenn

> 
> Waar wil je het verschil tussen de twee kunnen zien ?
> Bij mij worden in JOSM alle highway=crossing al met een zebraatje
> aangeduid, behalve als er ook nog eens crossing=traffic_signals op
> staat, dan komt er verkeerslichtje met 2 kleurtje.
> 
> Aan welke andere highway=* denk je? traffic_mirror ? daar is er al een
> spiegeltje voor
> highway=crossing is iets wat op een node staat, maar je wil
> waarschijnlijk highwar=primary e.g. die op ways staan niet beïnvloeden
> of wel ?
> 
> Je kan in Overpass Turbo je zoek resultaten met map css "kleuren",
> maar dat staat volledig los van wat je in JOSM ziet of doet.
> 
> Dus je zal echt wat duidelijker moeten zijn in je vraagstelling opdat
> we je kunnen helpen.
> 
> mvg
> 
> m
> 
> 2016-11-19 13:23 GMT+01:00 Philippe Casteleyn :
>> Ik heb de vraag al op de juiste plaats gesteld, maar geen antwoord gekregen
>> :  Ik wil een verschil zien tussen highhway = * en highway = crossing.
>>
>> U kunt het proberen met de Overpass sample "Map CSS Styling"
>>
>> In JOSM krijg ik heb foutbericht :  " ... reported a bad request"
>>
>> 
>>
>>
>>
>> ___
>> 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] Stylesheets in JOSM Overpass

[Glenn Plas]

On 19-11-16 13:23, Philippe Casteleyn wrote:
> Ik heb de vraag al op de juiste plaats gesteld, maar geen antwoord
> gekregen :  Ik wil een verschil zien tussen highhway = * en highway =
> crossing.
> 
> U kunt het proberen met de Overpass sample "Map CSS Styling"
> 
> In JOSM krijg ik heb foutbericht :  " ... reported a bad request"


Ik denk dat je wat meer info moet geven om u te kunnen helpen, ik kan
niet volgen.  idd je kan MapCSS gebruiken, maar wil je die zelf maken of
de bestaande beschikbare sheets eens proberen ?

Installeer eens een MapCSS uit de lijst waar highway rules in staan, dan
kan je die waardes aanpassen, maar dan weet je tenminste dat de syntax
klopt.

Wat Overpass ermee te maken heeft is mij een raadsel, die 2 hebben
elkaar niet nodig om te doen wat ze doen.

Glenn


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

[OSM-talk-be] Evolta - OSM license violation

[Glenn Plas]

Take a look here:

http://www.evolta.be/nl/contact/

It really bothers me that they are not giving 'us' credit for this map.
 This a study bureau that has gotten the assignment from the province to
plan the 'fiets-ostrade' from Mechelen (Nekkerspoel)/Antweroen till
Zemst/Vl-Brabant.

http://www.provincieantwerpen.be/aanbod/drem/dienst-mobiliteit/fietsbeleid/f1-antwerpen-brussel.html

They use GIS data all the time, they should know better.  The tiles are
comming from mapbox, I already verified my "easter eggs" are present in
their map.

tbh, what took me over the edge to raise this issue here is the fact
they will be "study'ing" for 2 full years on how to implement this
bicycle road.  They already determined where it goes so I really wanted
to know what the 2 years of taxpayers money was going to when I stumbled
upon that map.  Spending hours and hours on OSM, I can't stand it people
don't even bother to credit the source.

Does anyone have standard mails/letters they can send out?

If I have to write one, I'm going to sound a wee-bit too hostile even
when I pay attention not to.

Glenn

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

Re: [OSM-talk-be] AGIV aerial no longer default in iD

[Glenn Plas]

On 17-11-16 11:13, joost schouppe wrote:
> Hi,
> 
> Anyone know why AGIV no longer is default imagery in Flanders and
> Brussels? Up until a week or so, this was the case.
> 
> Because of this, we now got newbies doing stuff like this:
> 
> https://www.openstreetmap.org/changeset/43700640#map=19/50.82941/4.45770

What am I looking at here ?
http://osmhv.openstreetmap.de/changeset.jsp?id=43700640

Not sure if I get the match between Perlino * 3 and the aerials

afais: there are indeed 3 blocks there.

Glenn

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

Re: [OSM-talk-be] introducing OSM

[Glenn Plas]

I have one on slideshare...

http://www.slideshare.net/glennplas/opendata-namen

> I think github is a good idea, if only for a place to collect all
> information in one place.

I aggree, there are GUI frontends available for allowing not-techies to
contribute.

> 
> Anyone else who wants to be an admin on our github account btw?

sure ;-)

Glenn

> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> On Wed, Nov 9, 2016 at 11:26 AM, Marc Gemis  > wrote:
> 
> I can export mine from my Google as PDFs and put them anywhere you like
> Perhaps with links to the originals.
> 
> m.
> 
> On Wed, Nov 9, 2016 at 11:07 AM, joost schouppe
> > wrote:
> > Hi,
> >
> > Several of us have done presentations to introduce OSM. What we
> tell exactly
> > depends on the public, of course. But it would be nice to collect
> some of
> > these efforts.
> >
> > Any suggestions for a place where we could share these presentations?
> >
> > I try to keep mine here:
> >
> >
> https://www.dropbox.com/sh/xsr4ed9w5dwgzab/AAAMeTT-bpnt7BLmvt7OSYWUa?dl=0
> 
> 
> >
> > --
> > Joost @
> > Openstreetmap | Twitter | LinkedIn | Meetup
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org 
> > https://lists.openstreetmap.org/listinfo/talk-be
> 
> >
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-be
> 
> 
> 
> 
> 
> ___
> 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] Missing Maps, in Belgium

[Glenn Plas]

On 09-11-16 09:28, Jonathan Beliën wrote:
> Oops, I’ll try to fix that this weekend !

afaik, it's not really fixable on the website, it's because your browser
uses the method you use to visit the website.  So if you want remote
control to work, you can offer the task manager unencrypted which could
give you problems with osm oauth2 logins. It's been a while since I
tested such a setup, not 100% sure.

since remote control that listens on both localhost/8111(non-ssl) and
localhost/8112(ssl) does not let the call pass using ssl (your browser
in fact), due to certificate issues (on your pc)

> 
> @Glenn : I already use Let’s Encrypt certificate for the Task Manager ;-)

I use it everywhere.  +1 for your SSL choices :)

> Sorry for the inconvenience !
> 

not your fault.  It's how it is.  to fix this, you need to get some
certificates installed locally (self-signed)

see: https://josm.openstreetmap.de/wiki/Help/Preferences/RemoteControl

and: "In addition you may need to tell your browser to accept the
self-signed JOSM HTTPS certificate"

Give that a try

Glenn




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

Re: [OSM-talk] OpenStreetView name change

[Glenn Plas]

On 08-11-16 19:16, Hakuch wrote:
> On 08.11.2016 18:34, Glenn Plas wrote:
>> I think it's definitely totally unreasonable by Giegle.
> 
> To be honest, no one would have chosen "View" if there not has been that
> other tool, do you?

View is quite a common word. Imagine apple claiming the rights on
anything that starts with I- : I-crap, I-whatever, I-rail, I-eat (there
are thousands of those). They wouldn't exist either without Apple.

They seem to have no problem with OpenStreetMap vs. Google StreetMap
right?  Because they know they would loose this in court.  It's just FUD
tactics.

I've went against Google in 2008 on a map dispute and won , didn't have
to pay 50K per year for 3 years because of it(prob. peanuts for them but
they went after us anyway).   Didn't cost me nothing btw. well worth it.

They thought they could force American rules on a Belgian company, they
might have plenty of lawyers, doesn't really help as only 1 can talk at
the same time and when they are ignorant they loose.

in our EU law system you cannot claim ownership over common words like
that.  It's not because you're big and bold that you can get away with
bullying.

So, why not use OpenStreetMapView ? It's just an extra word behind an
existing brand, almost as old as Giggle maps.
.
Glenn


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


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

Re: [OSM-talk] OpenStreetView name change

[Glenn Plas]

Knock yourselves out by not being able to choose:

http://www.namemesh.com/domain-name-search/open%20street%20photo?show=1

But I still think it's bullshit to claim this as it's clearly a part of
the openstreet-brand if you just put the word 'view' behind it.

I think it's definitely totally unreasonable by Giegle.

Glenn


On 08-11-16 16:34, Martijn van Exel wrote:
> Hi all, 
> 
> A few months ago, we started with OpenStreetView, the free and open
> street level imagery project made 100% for OSM with apps for Android and
> iOS. Since then, we not only have collected almost 30 kilometers of
> coverage, but also received a lot of attention from both you and the
> press. This has also led to a friendly (for now) request by a well-known
> company with a similarly-named product :) to not use the OpenStreetView
> name. So we are looking for a new name. We have some ideas already but I
> wanted to ask if you had any suggestions for a new name for OSV?
> 
> Thanks for your support and happy capturing / mapping, 
> 
> Martijn + the OpenStreetView team
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk-be] Missing Maps in Belgium - invisible track

[Glenn Plas]

On 08-11-16 17:58, Marc Gemis wrote:
> dus je kan over een willekeurige weide zonderafsluiting een pad
> tekenen ? Zal die landbouwer blij mee zijn.

Dat zou eerder een track zijn imho en geen pad (als we letterlijk
vertalen hier)

paths en tracks zijn zo dubieus eigenlijk

Glenn

> 
> 
> 
> 2016-11-08 17:55 GMT+01:00 Wouter Hamelinck <wouter.hameli...@gmail.com>:
>> Ik vind ook dat je dergelijke wegen in OSM moet houden. Mijn criterium is
>> heel eenvoudig:
>> * pad zichtbaar: in OSM
>> * geen pad zichtbaar en echt ontoegankelijk (bvb door afsluiting of muur):
>> niet in OSM
>> * geen pad zichtbaar, maar toegankelijk zelfs al is het maar een deel van
>> het jaar en met wat moeite: een paar keer over en weer lopen en je zit in
>> mijn eerste geval. In OSM dus.
>>
>> wouter
>>
>> 2016-11-08 17:15 GMT+01:00 Glenn Plas <gl...@byte-consult.be>:
>>>
>>> Er zijn wel wat in de wiki te vinden over temporary features maar of
>>> deze widely accepted zijn is een ander verhaal.
>>>
>>>
>>> https://wiki.openstreetmap.org/wiki/Proposed_features/temporary_(conditional)
>>>
>>> Klopt trouwens dat Trage wegen wel probeert alles in OSM te krijgen,
>>> maar persoonlijk vind ik teveel beter dan te weinig.  Het kost geen
>>> moeite iets te wissen dat er niet bijhoord, iets mappen dat er nog niet
>>> is meer werk.
>>>
>>> Daarom hou ik van thema-mappers, die zijn detailistisch , je kan daarop
>>> rekenen.  Dus dat er hier en daar een path staat dat min of meer dubieus
>>> is lig ik niet van wakker vanaf iemand ontdekt dat die niet te
>>> bewandelen zijn gaan ze weg.
>>>
>>> Zelf heb ik eentje al 2 keer moeten wissen hier beetje verderop, ik heb
>>> echt hard geprobeerd erover te geraken, maar het is er gewoon niet maar
>>> staat wel in Trage Wegen.  Dus iedere keer iemand deze opnieuw intekent
>>> weet ik dat het armchair copy/paste is.
>>>
>>> Glenn
>>>
>>>
>>> On 08-11-16 17:03, joost schouppe wrote:
>>>> Hier in Halle ken ik ook zo'n situatie:
>>>>
>>>> http://www.openstreetmap.org/way/256780484
>>>>
>>>> Niets te zien, maar wel een officieel tragewegenbordje en occasioneel
>>>> gebruik.
>>>>
>>>> In dit geval zou ik (zoals Glenn al zei) eens vragen aan Wegspotter wat
>>>> hij er zelf over denkt. Als het een historisch wegje is dat enkel nog
>>>> wettelijk gezien bestaat, dan denk ik dat hij wel akkoord zou zijn om
>>>> het te wissen. En dat was toch de consensus binnen OSM dacht ik. Als het
>>>> nog effectief af en toe gebruikt zou worden, kan je het eerder wel laten
>>>> staan.
>>>>
>>>> Alleszins zijn dit soort gevallen wel een mooie illustratie van hoe
>>>> moeilijk het is de grens te trekken. Eigenlijk zou je alle "legaal
>>>> bestaande en niet fysiek ontoegankelijke wegjes" (geen omheining, geen
>>>> diepe beek) kunnen mappen. Als iemand er zich door worstelt, dan kan in
>>>> principe niemand daar iets tegen beginnen. En als er véél mensen dat
>>>> doen, dan ontstaat er terug een "echt" pad. Maar ik zou zeker niet
>>>> argumenteren om zomaar alle Atlaswegen in te tekenen.
>>>>
>>>> Datzelfde is uiteindelijk wat er in het voorbeeld van Philip elk jaar na
>>>> het zaaien gebeurt. Bij Trage Wegen vzw organiseren ze op dat soort
>>>> plaatsen soms wandelingen specifiek om dat soort padjes in stand te
>>>> houden, eenvoudig door er een keer met honderd man over te lopen :)
>>>>
>>>> Nog een mooie:
>>>>
>>>> http://www.openstreetmap.org/way/169851483#map=19/50.72151/4.08480
>>>>
>>>> Die is helemaal niet zichtbaar op het terrein, maar wel deel van een
>>>> officiële wandeling. Op het "echte" pad (aan het noordelijke eind) staat
>>>> er gewoon een bordje "hier naar rechts naar volgende knooppunt" en daar
>>>> loop je zo het grasveld in. Dat zou je hier natuurlijk als een "virtueel
>>>> pad" kunnen mappen.
>>>>
>>>>
>>>>
>>>> ___
>>>> 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
>>
>>
>>
>>
>> --
>> "Den som ikke tror på seg selv kommer ingen vei."
>>- Thor Heyerdahl
>>
>> ___
>> 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] Missing Maps in Belgium - invisible track

[Glenn Plas]

Er zijn wel wat in de wiki te vinden over temporary features maar of
deze widely accepted zijn is een ander verhaal.

https://wiki.openstreetmap.org/wiki/Proposed_features/temporary_(conditional)

Klopt trouwens dat Trage wegen wel probeert alles in OSM te krijgen,
maar persoonlijk vind ik teveel beter dan te weinig.  Het kost geen
moeite iets te wissen dat er niet bijhoord, iets mappen dat er nog niet
is meer werk.

Daarom hou ik van thema-mappers, die zijn detailistisch , je kan daarop
rekenen.  Dus dat er hier en daar een path staat dat min of meer dubieus
is lig ik niet van wakker vanaf iemand ontdekt dat die niet te
bewandelen zijn gaan ze weg.

Zelf heb ik eentje al 2 keer moeten wissen hier beetje verderop, ik heb
echt hard geprobeerd erover te geraken, maar het is er gewoon niet maar
staat wel in Trage Wegen.  Dus iedere keer iemand deze opnieuw intekent
weet ik dat het armchair copy/paste is.

Glenn


On 08-11-16 17:03, joost schouppe wrote:
> Hier in Halle ken ik ook zo'n situatie: 
> 
> http://www.openstreetmap.org/way/256780484
> 
> Niets te zien, maar wel een officieel tragewegenbordje en occasioneel
> gebruik.
> 
> In dit geval zou ik (zoals Glenn al zei) eens vragen aan Wegspotter wat
> hij er zelf over denkt. Als het een historisch wegje is dat enkel nog
> wettelijk gezien bestaat, dan denk ik dat hij wel akkoord zou zijn om
> het te wissen. En dat was toch de consensus binnen OSM dacht ik. Als het
> nog effectief af en toe gebruikt zou worden, kan je het eerder wel laten
> staan.
> 
> Alleszins zijn dit soort gevallen wel een mooie illustratie van hoe
> moeilijk het is de grens te trekken. Eigenlijk zou je alle "legaal
> bestaande en niet fysiek ontoegankelijke wegjes" (geen omheining, geen
> diepe beek) kunnen mappen. Als iemand er zich door worstelt, dan kan in
> principe niemand daar iets tegen beginnen. En als er véél mensen dat
> doen, dan ontstaat er terug een "echt" pad. Maar ik zou zeker niet
> argumenteren om zomaar alle Atlaswegen in te tekenen.
> 
> Datzelfde is uiteindelijk wat er in het voorbeeld van Philip elk jaar na
> het zaaien gebeurt. Bij Trage Wegen vzw organiseren ze op dat soort
> plaatsen soms wandelingen specifiek om dat soort padjes in stand te
> houden, eenvoudig door er een keer met honderd man over te lopen :)
> 
> Nog een mooie:
> 
> http://www.openstreetmap.org/way/169851483#map=19/50.72151/4.08480
> 
> Die is helemaal niet zichtbaar op het terrein, maar wel deel van een
> officiële wandeling. Op het "echte" pad (aan het noordelijke eind) staat
> er gewoon een bordje "hier naar rechts naar volgende knooppunt" en daar
> loop je zo het grasveld in. Dat zou je hier natuurlijk als een "virtueel
> pad" kunnen mappen.
> 
> 
> 
> ___
> 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] Missing Maps, in Belgium

[Glenn Plas]

Corrections:

> That is normal if you open the site in https mode, JOSM remote control
> will try to use that method and it's not implemented in JOSM, actually
> it is but the SSL certificate does not validate so you get denied.

The site will try use the same method (http vs https) to open JOSM is
more correct.


> You can verify this with openstreetmap.org site , it works in both modes.

I does NOT work in both modes.

Time to stop reading mailing lists today :)

glenn


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

Re: [OSM-talk] OpenStreetView name change

[Glenn Plas]

Does well-know-bully-company own the word 'view' ?  I don't understand
why you consider yielding on this.  They can ask all they want right ?

Glenn


On 08-11-16 16:34, Martijn van Exel wrote:
> Hi all, 
> 
> A few months ago, we started with OpenStreetView, the free and open
> street level imagery project made 100% for OSM with apps for Android and
> iOS. Since then, we not only have collected almost 30 kilometers of
> coverage, but also received a lot of attention from both you and the
> press. This has also led to a friendly (for now) request by a well-known
> company with a similarly-named product :) to not use the OpenStreetView
> name. So we are looking for a new name. We have some ideas already but I
> wanted to ask if you had any suggestions for a new name for OSV?
> 
> Thanks for your support and happy capturing / mapping, 
> 
> Martijn + the OpenStreetView team
> 
> 
> 
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
> 


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

Re: [OSM-talk-be] GRB import case + wiki page need help

[Glenn Plas]

Hey,

On 08-11-16 15:29, joost schouppe wrote:
> Eh, I would think the legal stuff can just be copied from here:
> 
> https://wiki.openstreetmap.org/wiki/AGIV_CRAB_Import#Legal

mmm, translated license info in English... how did that escape me ?

> 
> CRAB and GRB are under the same licence
> (check 
> https://www.agiv.be/news/2015/december/vlaamse-overheid-stelt-grb-data-gratis-open
> ), and CRAB has been accepted as something we can import.

awesome, we need ammunition like that.  That means they can't argue with
us about the license.  That will save a thread or 2 in the import
mailing list.

> And yes, discussing is much more fun than editing wiki pages of course :)

Let's move forward on this,  we gotta get content in there. I'm quite
motivated to fix the final steps, especially make a production ready
interface.

tx Joost.

Glenn

> 
> 2016-11-08 13:37 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> On 08-11-16 13:30, joost schouppe wrote:
> > I'm a little surprised by how little space there is for explaining the
> > what and why of the import in this template. Things like "current use in
> > OSM", "quality of the data", "data model of the original data", etc
> > "integration methodology" etc. I would expect this to be the most
> > important in evaluating the import. Seems like this is all kept to the
> > imports talk list then? Or is this supposed to be in the explanation of
> > the source itself?
> 
> I just kinda anchored the page and removed some dutch text, I think it
> should be in English too, but I can't find GRB licensing in English atm.
> 
> Feel free to blow it away actually, only the top part is mine.  it's a
> rush job and I was planning on improving it today if only I wasn't
> fighting a evil tile server like a jedi master
> 
> > I would like to work on that part of the page if that is useful. And we
> > could probably get someone from the AIV to review the technical details
> > too.
> 
> Thanks Joost, I noticed the response on actually helping me with these
> is very low atm.  But the "GRB pressure" to get it done seems a lot
> higher (not judging) But I can't do it all by myself.
> 
> If I can make a suggestion, I really want the legal part in order.  For
> technical stuff I have a lot more inspiration.
> 
> Glenn
> 
> ___
> 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>
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap
> <http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter
> <https://twitter.com/joostjakob> | LinkedIn
> <https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
> <http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>
> 
> 
> ___
> 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] Missing Maps, in Belgium

[Glenn Plas]

There is the KBO, which you can consult for free but I strongly doubt
the license is OSM compatible.  they used to sell this data for an
insane amount of money.

http://economie.fgov.be/nl/ondernemingen/KBO/#.WCGss3UrJD8

you could probably deduct some of the shops data when their registered
office has the same address as the place of exploitation.

It's a real mess imho:

"KBO stelt zijn publieke gegevens beschikbaar aan iedereen, en dit op
verschillende manieren om zoveel mogelijk tegemoet te komen aan de
verschillende noden en technische capaciteiten van allen.Sommige van
deze diensten, zoals de toepassingen Public search, de mobile toepassing
en open data, zijn gratis. Andere diensten zoals de web services Public
search en het volledige publieke gegevensbestand dat ter beschikking
gesteld wordt voor hergebruik, zijn betalend."

So, only a few select services are 'open data'.  But it's all about the
same data.  There is the confusing statement: how can the data be open
when you close half of the access to it?  Also, the last part like
downloading the full database for a fee isn't true anymore, you can
download it for free.  So the site content isn't actualised on this subject.

I tried downloading it and next to the fact I had to 'state' what I was
going to use the data for, that answer limits my use.  So I entered
:"for creating a web application".  Turned out to be good enough...

It's truly speckeled with legal mumbo that makes it unusable for OSM,
but it's useful to double check with shop data manually.

http://economie.fgov.be/nl/ondernemingen/Intellectuele_Eigendom/Rechtsbescherming_databanken/bescherming_door_ie/#.WCGuIXUrJD8

Glenn


On 08-11-16 08:04, joost schouppe wrote:
> As for Joost's suggestion for mapping shops in a town. Depending on
> the data source, it might add too much out-of-date data. I fear that
> armchair mappers will blindly copy the data without cross referencing
> other sources that indicate that the shop was closed/moved. Using up
> to date photo's from OpenStreetView or Mapillary could overcome this
> problem, when the mapper is willing to spend enough time and does want
> to be the mapper that finishes most tiles in the shortest period.
> 
> 
> There is no open data source for shops that I'm aware of, so this would
> in fact be a collect data + map task. There is of course the option of
> taking an area that is already densely mapped in Mapillary (say, central
> Brussels) and define a task there. Then the "validation" step would be
> to go into the field and collect the last bits of info.
> 
> 
> ___
> 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] GRB import case + wiki page need help

[Glenn Plas]

Hi everyone,

I like to set things in motion to prepare our semi-automated import.
I've been reviewing many cases where imports have been proposed and it
looks like our semi-automated approach is pretty solid.  Nevertheless,
as it should be, the people from the import workgroup demand we do our
homework.

One of the things I noticed is that there is a lot of focus on the
license of the source data, we'll need to get links in place to the
correct license and all sorts of background information.

I need some help typing this up...   Specifically, can someone who
studied the GRB licensing (I know some are very knowledgeable on that
subject, more than myself) and spread his/her knowledge on the wiki.

I've created a starter page here :
https://wiki.openstreetmap.org/wiki/GRBimport

You can do this ro8ghly, I will fix the markup when needed, I really
need solid content on that.

Meanwhile I'll work on the procedure and example usage cases. I will
also work on getting a technical solid case I can defend personally
(which doesn't mean we cannot deviate from that case) upstream.

we have some really good advantages, as it is NOT a pure mechanical
import and we are expected to validate with surveys (a lot of us already
do, like Marc Gemis does now).  It's a really added value that we have
people doing it the way Marc does and not 'in bulk' like I did with some
test cases (Stekene).

Keep in mind: it was never made to be a bulky full-auto tool and it will
not allow you to use it like that either.  Our manual steps we perform
will be excellent to counter any objections (they rightly have against
full mechanical imports) before they are even made.

So: in short: would love to get help in on this, I really get motivated
to spend more time in building a production ready tool based on my
development work when I see others who got my back on chores I don't
want/can do.

I'll work a more complete short list of tasks/things we need to cover.

Thanks a lot in advance, with all the interest in GRB it should not be
so hard to get 1 to 5 people on board to assist.

I promise: drinks are on me -every- time we meet about this, so please:
don't all just jump on the boat now you know this.

:)

Glenn

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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

[Glenn Plas]

On 07-11-16 12:44, Ben Abelshausen wrote:
> Het is duidelijk dat dit, vanuit technologie standpunt de beste
> oplossing is, dat is niet waar het probleem zit. Dit is zeker een
> elegante oplossing. Het punt is dat we die wiki pagina moeten maken en
> er moet community consensus zijn (min-of-meer) over de aanpak en ik
> geloof niet dat we dat op deze manier gaan bereiken.

Verschil is natuurlijk dat ik hier al een jaar mee bezig ben en het
normaal is dat mijn keuze's worden ontleed.  Altijd bereid om mijn
standpunten te verduidelijken , ook naar de werkgroep toe.

> 
> Het is 100% zeker dat dit zever gaat geven met de import lijst en data
> working group en ik heb gewoon geen goesting om mij daar weer mee bezig
> te houden. En ik bedoel inderdaad mensen die op eigen houtje GRB
> gebouwen over de bestaande hebben gezet... dat moeten we vermijden.

Dat is echt nasty, maar importeren zonder tags is voor mij net hetzelfde
zootje.

> 
> Ik denk nog altijd dat het voldoende gaat zijn om sommige gebouwen
> éénmalig te importeren en dan verder te onderhouden op de gangbare
> manier. Dit gaat de weg van de minste pijn zijn, eenvoudig te
> implementeren en geen (of minder) zever met de data working group of de
> import lijst.

Dan kan je dat dus niet automatiseren en of Q/A tools gaan maken, iets
dat ik ook van plan ben achteraf. zoals mijn Urbis Q/A tool :
https://github.com/gplv2/urbis-validate

> 
> In het kort dus: Voor mij evengoed als we het kunnen regelen dat we die
> tags allemaal kunnen meenemen maar ik heb dan niet veel zin om dit te
> verdedigingen op de import lijst.

Ik wil dit wel op mij nemen.

> 
> Ik wou om deze reden dus ook face-to-face afspreken om te vermijden heel
> deze discussie via mail te voeren...

Och, het is al paar keer langsgekomen, ik verwacht ook dat we erover
discussieren, maar de impact van de keuzes moet wel duidelijk zijn, als
dat niet zo is kom je hier niet goed uit.

> 
> @marc: we zouden de source tag ook op de changeset kunnen zetten. Is ook
> logischer omdat enkel de data die in die changeset nieuw is ook die bron
> heeft.

Daar ben ik 150% mee akkoord, ik zou VEEL liever source=GRB op de
changeset zetten (geloof dat ik dat meestal ook wel deed)

Willen we eens een bijeenkomst organiseren ?  Ik maak daar graag tijd
voor.  Ik zou heel graag GRB data zien in OSM maar dan wel volgens de
regels van de data-kunst.  Ik zou eigenhandig op een maand of 2 tijd
gans Belgie kunnen doen.

Ik moet zeggend dat ik zelf ook al het idee van Jo heb overwogen, om de
data te 'druppel-laden' ipv te doen alsof dit een massieve import is (en
dat is het niet).

GLenn

> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 
> Met vriendelijke groeten,
> Best regards,
> 
> Ben Abelshausen
> 


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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

[Glenn Plas]

On 07-11-16 12:44, Jo wrote:
> source:geometry zou toch hetzelfde moeten zijn als source, wat het
> volgen van de wiki betreft.

Ja, hoe gek is dat niet hee:  Natuurlijk hebben jullie dat process niet
meegemaakt maar toen ik dit initieel had gemaakt stond het er ook zo bij:

source=GRB
source:geometry=GRB
source:position=GRB

En die 2 laatste blijken tegenwoordig hetzelfde te zijn (zie wiki). Dus
die hebben we toen gedropped, en dan wat liggen praten over
source/source:geometry

"Pretty clear it comes from GRB" ;-)

> 
> Persoonlijk vind ik ref beter. Toen ik alle ref op de bushaltes had
> overgezet naar ref:De_Lijn en ref:TEC, kreeg ik van Franse kant wel de
> opmerking dat dit eigenlijk ref:BE:De_Lijn en ref:BE:TEC had moeten zijn.

Je moet echt eens lezen over ref en source verschillen.  Ik heb hier wss
weken aan gespendeerd dus ik ben heel zeker dat ref een minder goede
keuze zal blijken.  Ik geef toe dat je hard moet nadenken over de
intepretaties ervan.  Voor mij is het grote verschil:  een ref dat
slaagt direct op het object.  Terwijl een source tag een referentie is
naar de brondata van een object.

> 
> Maar het maakt me dus niet uit of het source:huppeldepup of ref:...
> wordt. Ik ben ook voorstander van het te verdelen over meerdere tags.

Weet je dat er gebouwen zijn aan de grenzen die zowel in BAG zitten als
in GRB? Dus whatever you do: het mag die BAG data niet ontkrachten of
clashing tags bevatten.  Vandaar dat ik ook een probleem heb met
source=GRB tags

Glenn





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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

[Glenn Plas]

On 07-11-16 12:14, Marc Gemis wrote:
> Ik ben echt niet gelukkig met source=GRB. Probeer dat maar eens te
> combineren met data die je op een andere manier hebt gevonden (bv. via
> survey of wikipedia).
> source:geometry of iets dergelijks ok, maar niet source aub.

En spijtig genoeg is dit verplicht als je de wiki erop naleest

Ik had liever dit gehad :

source:geometry=GRB

Makes more sense, zegt letterlijk:  de geometry komt uit GRB.  Nu heb je
idd nog adress data, en die kan van CRAB komen.

Maar je kan dit niet importeren zonder source tags volgens de regels...

Ik was dus eerder fan van deze tag, indertijd wel wat over gediscussierd
met Sander en hebben voor deze gekozen.

Laat het wel verstaan: voor mijn tool is die source tag niet van belang.
 Dit is om compliant te zijn aan OSM regels.

Dus ik ben akkoord dat dit eigenlijk niet echt nuttig is, maar het is
wel verplicht, ik sta open voor alternatieven.

Glenn


> 
> m.
> 
> 2016-11-07 12:02 GMT+01:00 Glenn Plas <gl...@byte-consult.be>:
>> On 07-11-16 11:51, Ben Abelshausen wrote:
>>> Glenn,
>>>
>>> Kijkend naar de BAG import wat denk je van dit:
>>>
>>> source = GRB
>>> ref:grb = 3746049-6379775 (oidn-uidn)
>>
>> Dat gaat een leuke query worden in de database, met regular expressions
>> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
>> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
>> nummer zegt echt niks.
>>
>> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
>> een source ref.  daarom source:*
>>
>>> Die datum is niet echt relevant voor mappers en als ik het goed begrijp
>>> kunnen we dit via bovenstaande ref nog altijd uit de originele data
>>> halen? Zelfde voor entity? We zouden die entity types ook nog kunnen
>>> gebruiken om andere tags te genereren omdat daar toch wel verschillende
>>> zaken inzitten precies.
>>
>> Dat gebeurd nu ook, maar er is ook overlapping tussen entities.
>>>
>>> Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
>>> (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
>>> overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
>>> menig een slechte zaak is.
>>
>> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
>> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
>> migreren.  zie docs : http://grbtiles.byteless.net/docs/
>>
>>>
>>> Eens de import klaar is en we hebben alle gebouwen doen we maintenance
>>> zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
>>> kunnen nog altijd de datasets vergelijken om te bekijken waar de
>>> wijzigingen zitten.
>>
>> Die maintenance is nu simpel:  match entity en oidn en je weet exact
>> welk gebouw je hebt.
>>
>> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
>> versta niet wat het grote probleem is en waarom we het ons moeilijker
>> moeten maken ook als het makkelijk kan ?
>>
>> Die meta data is voor automatisatie te faciliteren, niet zomaar dus.
>>
>> Glenn
>>
>>
>>>
>>> Met vriendelijke groeten,
>>> Best regards,
>>>
>>> Ben Abelshausen
>>>
>>> On Mon, Nov 7, 2016 at 11:29 AM, Glenn Plas <gl...@byte-consult.be
>>> <mailto:gl...@byte-consult.be>> wrote:
>>>
>>> On 07-11-16 11:22, Glenn Plas wrote:
>>> > (hence source:geometry:entity=GRB.
>>>
>>> Dju, dat moest zijn:
>>>
>>> source:geometry:entitity=Gbg of Knw, maar niet GRB.
>>>
>>> Glenn
>>>
>>>
>>> ___
>>> 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>
>>>
>>>
>>>
>>>
>>> ___
>>> 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-import voor centrum Antwerpen ?

[Glenn Plas]

On 07-11-16 12:12, joost schouppe wrote:
> 
> >
> > source = GRB
> > ref:grb = 3746049-6379775 (oidn-uidn)
> 
> Dat gaat een leuke query worden in de database, met regular expressions
> en stuff. pfff.  En die uidn is volgens mij nog van een minder belang
> dat de datum.  Die is leesbaar voor eindgebruikers, die uidn versie
> nummer zegt echt niks.
> 
> Ik ben trouwens niet akkoord met die ref tag.  het is geen ref, het is
> een source ref.  daarom source:*
> 
> 
> Dus beter datum geometrie + oidn, niet uidn. (+ type eenheid)

die uidn zat er eerst zelfs niet in, de datum vond ik veel interessanter
om te vermijden dat mensen toch geomtrie gaan aanpassen op basis van
oudere sat foto's.  En dat is ondertussen al gebeurd btw met het beetje
dat is geimporteerd ondertussen.

Ik vind het beter hoe het nu staat (evidently)  en ik bekijk dit vanuit
een programmer/sysadmin standpunt ook.  Ik weet uit ervaring dat dit
beetje extra taggin werkt gewoon ons later zoveel hoofdpijn gaat besparen.

> 
> Die tag uiteen trekken als data is iets dat enkel voor onderhoud nodig
> gaat zijn - dus iets complex wordt nog net iets complexer. Lijkt mij
> niet zo'n groot probleem.

> 
>  
> 
> > Ik heb altijd gedacht, we importeren wat gebouwen waar het nodig is
> > (bijvoorbeeld dicht gebouwde steden). We hebben ookal werk van mappers
> > overschreven gezien met GRB gebouwen (delete-upload), iets wat naar mijn
> > menig een slechte zaak is.
> 
> Nee, dan heb je niet opgelet ;-) !!!  wij deleten niets.  De history van
> een gebouw wordt bewaard.  je moet de plugin gebruiken om geometries te
> migreren.  zie docs : http://grbtiles.byteless.net/docs/
> 
> 
> 
> Dat is niet wat Ben bedoelt. Hij heeft het op de wilde imports, of
> mensen die overtekenen uit het GRB zonder respect voor wat er al stond.
> Dat lijkt mij trouwens het beste argument voor een grote import: als we
> het niet doen met jouw excellente tool, dan gaan mensen het toch doen,
> alleen veel slechter.

Ha, idd, ik heb die ook al gezien, dan heb je dus enkel geomtries
aangepast, in lokeren geloof ik dat er zo'n geval is, iemand heeft daar
los GRB data geimporteerd, zonder onderverdeling in gebouwen/tags etc.
zonder die source tags kan je hier niets mee, zelfs ik nu niet, tenzij
ik spatial queries ga bouwen en dan nog is het lastig als iemand
ondertussen een gebouw heeft aangepast.

>  
> 
> > Eens de import klaar is en we hebben alle gebouwen doen we maintenance
> > zoals we dat normaal zouden organiseren moest het GRB niet bestaan. We
> > kunnen nog altijd de datasets vergelijken om te bekijken waar de
> > wijzigingen zitten.
> 
> Die maintenance is nu simpel:  match entity en oidn en je weet exact
> welk gebouw je hebt.
> 
> 
> Ik heb ook altijd begrepen dat de uitdaging bij importeren up to date
> houden is. Als daar technologische middelen voor zijn, dan moeten we die
> toch gebruiken. Ik snap net als jij niet wat de meerwaarde is van de GRB
> gebouwen ENKEL als OSM objecten te gaan updaten. Ideaal toch als we
> zowel the crowd als het AIV (AGIV) kunnen gebruiken?


Vandaar die source tags!  en natuurlijk is het super dan de crab tool
complementair bleek te zijn na analyse/code.


> Welk probleem zijn we nu eigenlijk aan het oplossen met die tags.  Ik
> versta niet wat het grote probleem is en waarom we het ons moeilijker
> moeten maken ook als het makkelijk kan ?
> 
> 
> It's politics baby, niet te veel energie aan verspillen.

Dus, we vragen gewoon meer, we includen alle source tags en als er een
issue is dan moeten ze de data zelf bekijken en zullen ze vaststellen
dat dit de MVP is ( minimum viable product )

Als hostage kunnen we uidn dan afgeven als we de datum bewaren.

Maar eerlijk gezegd,  ik snap de vragen omtrent die tags volledig, maar
zeggen zonder de data te bekijken dat het niet echt nodig is is iets te
snel door de bocht, ik verwacht van de OSM upstream organisatie
onderbouwde argumenten die ik dan snel technisch kan weerleggen, maar
emotie en/of politics heeft hier maar weinig ruimte en begrip bij mij
als de technologische oplossing minderwaardig blijkt te zijn.

Ik wou dat Sander ook even zijn 2c. hier kwam bijsteken :)

Glenn



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


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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

[Glenn Plas]

>> Kijkend naar de BAG import wat denk je van dit:
>>
>> source = GRB
>> ref:grb = 3746049-6379775 (oidn-uidn)


Entity ontbreekt, gaat niet werken, die oidn's die 'uniek' zijn, zijn
het enkel per entity. Dus entity is echt onontbeerlijk.

Het maakt een overpass query ook moeilijker, nu verleg je het
'performance/excess data probleem' dat je aankaart naar extra load voor
overpass API, als we dan toch issues hebben over wat extra tags/text,
dat vind ik erger.

Ik heb dit ook niet alleen bedacht, ik heb veel input van Sander gehad.

Glenn


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

Re: [OSM-talk-be] GRB-import voor centrum Antwerpen ?

[Glenn Plas]

On 07-11-16 11:45, joost schouppe wrote:
> Om het aantal tags verder naar beneden te krijgen, zou
> je source:geometry:entity en source:geometry:oidn gewoon samen kunnen
> voegen, niet? Bijvoorbeeld: Gbg_3746049.

waarom ?  met welk doel ?  Waarom is een extra tag een probleem?  Nu
maak je het gewoon moeilijker om queries te draaien zoals: geef me alles
van entity:GRB

> Analyse kwaliteit GRB is spot on.
> 
> Wat betreft verschil in kwaliteit tussen GRB en CRAB:
> 
> - de adressen in CRAB zijn beter, aangezien daar het volledige datamodel
> in zit (een notatie gekoppeld aan een locatie en aan gebouwen). Het GRB
> krijgt slechts, met vertraging, de adresnotatie mee van de adressen waar
> de adrespositie toevallig in ligt. Enkel CRAB kan dus overweg met één
> adres dat bij meerdere gebouwen hoort, of één gebouw waar adressen in
> verschillende straten bij horen.

Klopt maar er staat veel crap in CRAB.  Op de bruul in mechelen staan
een nummer of 10 midden in de straat, wss wisten ze niet waar ze deze
moesten parkeren.  Dat heb je niet in GRB.  Wat er in GRB zit is gewoon
beter.  Kwa compleetheid is CRAB wss wel vollediger.

> 
> - de gebouwen in GRB en CRAB zijn in principe identiek. Wanneer er een
> adres onstaat voor een nieuw gebouw, dan wordt er doorgaans een ruw
> blokje ingetekend als huis. Dat geeft soms het idee van lage kwaliteit.
> Maar als het GRB daar nog iets heeft, dan is dat per definitie
> verouderd. Uiteindelijk wordt het gebouw ingemeten, en komt dan eerst in
> GRB en dan in CRAB terecht. Daar kan mogelijk enige vertraging opzitten,
> dus dan is GRB tijdelijk inderdaad beter.

Het grote verschil is dit eigenlijk: crab adress data is niet gekoppeld
aan een fysiek gebouw, die van GRB wel want er is maar 1 adress dat je
kan zetten op een gebouw.  Met crab kan je wel indelen in appartementnrs
etc.  Daar is de CRAB meerwaarde.

In de import zijn alle gebouwen met dubbele adressen gedropped (de tags
toch, niet het gebouw).  vaak huizen op de hoek van 2 straten met 2
adressen maar met maar 1 gebouw, en in OSM kunnen we dat niet 2
addressen op 1 building.  Dan werken we met entrance nodes.

Daarom is de finishing touch eens GRB is geimporteerd om de CRAB tool te
gebruiken om te vervolledigen op de hoeken.

> 
> (misschien kan iemand van het AIV-AGIV hier nog enkele punten op de i
> zetten)

Yup, dat zou wel interessant zijn.

> 
> Welke verschillen zie jij nog, Glenn?

Het concept vooral, ik vind GRB meer bottom up approach en crab is meer
top-down -do I make sense?

Daarmee dat het GRB per gebouw 1 adress is voor OSM, we kunnen dat niet
mappen met 2 adressen, de GRB database laat dit wel toe.  Wij moeten een
vertaalslag maken naar het OSM model.  We kunnen simpelweg niet 2
addr:street tags maken voor 1 gebouw...   We kunnen dit wel met
addressed entrance nodes.

Glenn


> 
> 2016-11-07 11:29 GMT+01:00 Glenn Plas <gl...@byte-consult.be
> <mailto:gl...@byte-consult.be>>:
> 
> On 07-11-16 11:22, Glenn Plas wrote:
> > (hence source:geometry:entity=GRB.
> 
> Dju, dat moest zijn:
> 
> source:geometry:entitity=Gbg of Knw, maar niet GRB.
> 
> Glenn
> 
> 
> ___
> 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>
> 
> 
> 
> 
> -- 
> Joost @
> Openstreetmap
> <http://www.openstreetmap.org/user/joost%20schouppe/> | Twitter
> <https://twitter.com/joostjakob> | LinkedIn
> <https://www.linkedin.com/pub/joost-schouppe/48/939/603> | Meetup
> <http://www.meetup.com/OpenStreetMap-Belgium/members/97979802/>
> 
> 
> ___
> 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-import voor centrum Antwerpen ?

[Glenn Plas]

On 06-11-16 17:16, Denis Verheyden wrote:
> Hallo,
> 
> 
> Dit is de eerste keer dat ik post op deze mailing-list. Ik ben de laatste 
> tijd bezig geweest met het aanvullen van winkels en andere voorzieningen in 
> Mechelen en Antwerpen. In Mechelen is blijkbaar al een groot deel van het GRB 
> geïmporteerd of zijn de gebouwen manueel apart getekend, maar in Antwerpen 
> lijkt het wel armoe troef ?
> 

Yup, that was meh.  No import, dit was voor GRB er open was.


> De meest belangrijke winkelstraten van de 2de grootste stad van België hebben 
> maar enkel "blokken", en geen apart getekende gebouwen:
> http://www.openstreetmap.org/#map=17/51.21814/4.40740

Ik denk dat Ben Ben Abelshausen met zelfde idee zit om Antwerpen
compleet te maken.

> 
> Op de Meir tussen nr. 41 en 83 ontbreekt gewoon alles..
> Aangezien er nu de mogelijkheid is om via het GRB deze gebouwen te 
> importeren, lijkt het mij aangewezen dit te doen ipv alles nog manueel te 
> tekenen. 

Yup.  Niet zo moeilijk als wat er staat 1 grote polygoon is, dat zijn de
makkelijke migraties.

> 
> Het zou leuk zijn als dit binnen afzienbare tijd (een paar maanden) zou 
> gebeuren:
> * zodat ik kan verder werken
> * zodat shoppers gemakkelijker de weg vinden met OSM/OsmAnd/andere apps die 
> OSM gebruiken

Feel free om het te doen: http://grbtiles.byteless.net/

Glenn



> 
> Mvg,
> btrs 
> 
> www.openstreetmap.org/user/btrs
> 
> 
> ___
> 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] wide berm tagged as forest

[Glenn Plas]

Morning,


That should probably be:

natural=tree_row

https://wiki.openstreetmap.org/wiki/Tag:natural%3Dtree_row

It has to be a way, not an area

Glenn



On 12-10-16 21:58, Pieter Brusselman wrote:
> Hi,
> 
> How do you deal with a wide berms that are tagged as landuse=forest? 
> Eg. https://www.openstreetmap.org/way/179156184#map=17/51.07858/3.53635
> or https://www.openstreetmap.org/way/179488443.
> 
> The first example is a tree row, The second one is more like brushwood.
> 
> Can I just delete it and add new geometry and tags?
> 
> Grtz,
> Pieter
> 
> 
> ___
> 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] Vernieuwde Wiki .... is die te gebruiken voor België ? Nouveau Wiki compatible pour Belgique ...

[Glenn Plas]

https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_in_oneway_motor_car_roads
 &&

https://wiki.openstreetmap.org/wiki/Bicycle#Cycle_lanes_in_bidirectional_motor_car_roads

Use those please, not Ulamm's...

Glenn


On 04-10-16 20:25, Jakka wrote:
> https://wiki.openstreetmap.org/wiki/User:Ulamm/Tables_of_street_layouts#Cars_and_cycling_in_both_directions
> 
> 
> The old one does this still exist?
> 
> 
> ___
> 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