Re: [OSM-talk-nl] Tagging laadpalen auto in Nederland

[Sebastiaan Couwenberg]

On 5/18/23 11:51, Hugo hölscher wrote:

Is hier al eerder over gedacht, ik heb in deze mail list niets gevonden.


De Nederlandse community is hier niet echt actief meer, de activiteit is 
tegenwoordig op het forum:


 https://community.openstreetmap.org/c/communities/nl/43

Mvg,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Letter to the OSM Community in The Netherlands

[Sebastiaan Couwenberg]

On 11/21/22 08:55, Diana-Ioana Danciu via Talk-nl wrote:

Hello OSM community in The Netherlands,


You'll reach more of the OSM community in the Netherlands via:

 https://community.openstreetmap.org/c/communities/nl/43

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] V3 to V4 Mapillary image id migration

[Sebastiaan Couwenberg]

You'll reach more member of the Dutch community via the forum:

 https://forum.openstreetmap.org/viewforum.php?id=12

Kind Regards,

Bas

--
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Milestones are public domain but not in OpenStreetMap

[Sebastiaan Couwenberg]

On 9/15/21 12:01 PM, dktue wrote:
> Hello dutch openstreetmap community,

You'll have much luch reaching the Dutch community on the forum:

 https://forum.openstreetmap.org/viewforum.php?id=12

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Importing trees in Utrecht

[Sebastiaan Couwenberg]

On 9/27/20 6:44 PM, Pieter van Mill via Talk-nl wrote:
> If there are any comments I would love to hear them,

More mappers are active on the forum, you'll get more feedback there.

 https://forum.openstreetmap.org/viewforum.php?id=12

Since you only talk about importing, also think about how the data will
be updated.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Even voorstellen

[Sebastiaan Couwenberg]

Op het forum zijn meer mappers actief:

 https://forum.openstreetmap.org/viewtopic.php?id=151=9

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] BAG straatnamen (ook?) in OSM

[Sebastiaan Couwenberg]

On 4/14/20 5:08 PM, Richard Duivenvoorde wrote:
> Is er dan een andere mogelijkheid om, gegeven een officieel adres of
> straatnaam, een koppeling te maken met een OSM straat of pand?

Op basis van de coordinaten in de BAG kan de node of way met dat adres
in OSM gevonden worden, en op basis daarvan kan de dichtsbijzijnde
straat met die naam gevonden bijvoorbeeld met een algoritme zoals
geimplementeerd in de FixAddresses plugin:

 https://wiki.openstreetmap.org/wiki/JOSM/Plugins/FixAddresses

De meeste mappers zijn actief op het forum, daar zal je vraag meer
mensen berijken:

 https://forum.openstreetmap.org/viewforum.php?id=12

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Issues with diffs

[Sebastiaan Couwenberg]

On 05/09/2018 08:21 PM, Andrzej Kępys wrote:
> OsmosisRuntimeException: The replication state doesn't contain a
> timestamp property.
> Any idea where can I post/report this?

You need to get a different planet with all data, see:

 https://lists.openstreetmap.org/pipermail/dev/2018-May/030233.html

Kind Regards,

Bas


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

Re: [OSM-talk] Responding to vandalism

[Sebastiaan Couwenberg]

On 03/16/2017 06:13 PM, James wrote:
> People can't even be bothered to review osmcha, you think people will want
> to approve changesets?

Eventually, yes. It will become part of a responsible and thriving local
community. Debian managed to transition from a free-for-all (just
mailing the project leader) to a new-maintainer process and sponsors in
teams to assist new contributors.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Responding to vandalism

[Sebastiaan Couwenberg]

On 03/16/2017 05:30 PM, James wrote:
> and maintainers privileges, would be determined by whom? Other maintainers?

Yes, the local community grants that privilege.

When the local community is dysfunctional there is the overriding
authority of OSMF WGs like DWG. Like we have the Technical Commitee in
Debian or General Resolutions (project wide votes).

> Then you have whats going on on Wikipedia Fr where it's controlled by a
> small group of close friends that refuse anything outside their norms,
> which is bad.

Wikipedia is not a model that one should choose to model, Linux
distributions are a much better role model.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Fixing broken multipolygons

[Sebastiaan Couwenberg]

On 03/03/2017 05:10 PM, m...@rtijn.org wrote:
> Since the ‘self-intersecting’ challenge is now complete I featured the ‘Wrong 
> role’ challenge in MapRoulette. Happy fixing!

Are there plans to make these challenges permanent or periodically
re-introduce them when a new batch of issues has been prepared?

These are very common issues that will be introduced by mappers in the
future.

Having Maproulette challeges to fix the issues also visualized by the
OSMI Area maps is a great way to help fix these QA issues.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Fixing broken multipolygons

[Sebastiaan Couwenberg]

On 02/21/2017 05:40 PM, Jochen Topf wrote:
> Find all challenges and instructions here:
> http://area.jochentopf.com/fixing.html

My OCD complains about the typo before the challenge links, please do

 sed -i 's/Got to /Go to/g' fixing.html

Also the Maproulette paragraph is no longer accurate now that more than
one challenge has been created.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Luchtfoto's 2016 beschikbaar voor tracen in OSM

[Sebastiaan Couwenberg]

On 02/10/2017 07:33 PM, Maarten Deen wrote:
> On 2017-02-10 12:09, Sebastiaan Couwenberg wrote:
>> On 02/10/2017 11:58 AM, Maarten Deen wrote:
>>> Hoe kun je deze beelden in JOSM krijgen?
>>
>> Via Imagery Preferences, en dan de WMS of WMTS toevoegen m.b.v. de URLs
>> die op NGR staan.
> 
> Er staan een flink aantal URLs op op die site en ik heb er ook veel van
> geprobeerd, maar nog geen succes. Kun je wat uitgebreider zijn
> misschien? Welke url moet ik exact nemen?

Klik op de 'Luchtfoto 2016 25cm RGB open data' link die je vind op de
NGR pagina uit Johans post, op die pagina staan een WMS & WMTS link.

Als je daar niet uit komt, moet je Commodoortjes instructies voor
noobies maar volgen:

 https://forum.openstreetmap.org/viewtopic.php?pid=631054#p631054

Als de CA store in Java actueel genoeg is hoef je het slechte advies om
de HTTPS URL naar HTTP om te zetten niet te volgen.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Luchtfoto's 2016 beschikbaar voor tracen in OSM

[Sebastiaan Couwenberg]

On 02/10/2017 11:58 AM, Maarten Deen wrote:
> Hoe kun je deze beelden in JOSM krijgen?

Via Imagery Preferences, en dan de WMS of WMTS toevoegen m.b.v. de URLs
die op NGR staan.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Update nieuwbouw in Aerdenhout

[Sebastiaan Couwenberg]

On 10/06/2016 11:53 AM, Hugo Holscher wrote:
> In Aerdenhout bij de Gezina van de Molenlaan en Mies Noltenlaan 
> (http://www.openstreetmap.org/?mlat=52.36121=4.60237#map=19/52.36121/4.60237)
>  zijn nieuwe woningen gebouwd.
> Ze zijn deels al sinds begin dit jaar bewoond. Ze staan echter nog
niet op de kaart.
> Ik kan me niet voorstellen dat er geen kadaster gegevens zijn (na 2 jaar).
> Kan iemand nagaan of er iets mis is met de up-loads van de kadaster
gegevens?

In de BAG staan er al wel panden (met status in gebruik), zoek maar op
de straatnamen in de BAGViewer:

 https://bagviewer.kadaster.nl/

Op het forum is een topic voor BAG update verzoeken:

 http://forum.openstreetmap.org/viewtopic.php?id=52973

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] postkantoren in Nederland

[Sebastiaan Couwenberg]

On 09/11/2016 10:45 AM, Ronald Stroethoff wrote:
> Op de website "http://overpass-turbo.eu; kan je zoeken op 
> "amenity"="post_office".
> Er wordt dan gezocht in het dan geopende venster.
> Ik was een beetje verrast door de hoeveelheid postkantoren in Nederland die 
> vervolgens zichtbaar werden.
> Ik denk dat het geen goede indruk maakt als er nog zoveel postkantoren 
> zichtbaar zijn.
> Hoe gaan we daarmee om?

Gebruik de overpass resultaten als basis voor je surveys waarbij je on
the ground controleerd wat er in plaats van het postkantoor is gekomen.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] combinatie POI over winkel met adres (afkomstig uit BAG)

[Sebastiaan Couwenberg]

On 08/03/2016 09:40 PM, Ronald Stroethoff wrote:
> Ik las enige tijd geleden een discussie over het intekenen van winkels als 
> POI.
> Sommige mensen gaven toen aan dat ze de POI van een winkel combineerde met 
> het uit de BAG verkregen adres, ze zagen het als een voordeel dat de POI van 
> de winkel dan ook een adres aangaf.
> Helaas blijkt dat dit oplettendheid vereist bij het verwijderen van gesloten 
> of verhuisde winkels.
> Men kan dan namelijk niet De POI zomaar weggooien, men moet alleen de 
> gegevens van de winkels verwijderen en de rest laten staan.
> Op deze locatie is dat denk ik vandaag niet goed gegaan:
> http://www.openstreetmap.org/changeset/41208474#map=18/52.20496/4.39686

Dat is een veel voorkomend probleem, en op te lossen door de adressen in
de BAG te vergelijken met die in OSM. Het niet afkorten van straatnamen
is daarbij wel een complicerende factor.

Zolang iedereen een account kan aanmaken en direct toegang krijgt tot de
productie database zal de data in OSM altijd veel QA vereisen. Het
onbedoeld slopen van OSM data is immers veel te eenvoudig.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] Uithoorn

[Sebastiaan Couwenberg]

On 07/25/2016 01:32 PM, Ante Wessels wrote:
> Ik reed laatst het dorpje binnen waar ik geboren ben, Uithoorn, en merkte dat 
> de rondweg waar tientallen jaren over gepraat is warempel aangelegd is 
> (N201+).
> 
> Hij staat als ontwerp in OSM. Nu heb ik al tien jaar geen OSM editor meer 
> gebruikt, dus als iemand anders de status wil veranderen, dank. 

De N201+ is al sinds 2014 klaar en in gebruik, zo ook in OSM.

Waar zie je nog stukken N201+ in de oude staat?

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-talk] OSGeo-Live team needs help: Someone who looks after OSM data, tools and writes documentation is needed

[Sebastiaan Couwenberg]

 Forwarded Message 
Subject: [Live-demo] OSGeo-Live team needs help: Someone who looks after
OSM data, tools and writes documentation is needed
Date: Sat, 11 Jun 2016 13:06:11 +0200
From: Astrid Emde 
To: Live Demo 

Hello OSM enthusiasts,

this is a mail from the OSGeo-Live team [1]. OSGeo-Live is a linux based
distribution of open source geospatial software which is handed out at
conferences around the world, and used as the foundation for open source
geospatial training courses.

We use OSGeo-Live to teach enthusiasts how to create geospatial data
with free tools.

At the moment, we include an extract of OSM data, and how to use Mapnik,
but we'd love to be doing a better job of promoting OSM which in turn
should attract motivated geospatial people into the OSM community.

The catch is that we need some help understanding OSM tools, and keeping
these tools and docs up to date, which is where you (the OSM community)
comes in.

We are hoping to find one or two people who can help us write
Application Overview [2] and 10-15 min Quickstart docs, and act as a
point of contact to advise on OSM as we build each release.

This is what we are looking for. Are you interested to help? It could be
a single person or a team. And the OSGeo-Live team is also supporting,
when help is needed.

This is what you have to do - don't worry, it should not be too much work ;)
* provide the up-to-date software every half a year when a new version
of OSGeo-Live is coming out
* check the documentation (Overview and Quickstart)  -> is there
anything to update
* provide new up-to-date OSM data (f.e. for version 10.0 we will provide
data from Bonn where FOSS4G 2016 will be in august)
* provide a quickstart (tutorial to help people to get to know OSM and
make the first steps) - this quickstart does not exist at the moment and
has to be written
* OSM covers data and OSM tools (like JOSM) which are not documented yet
** we only have a documentation for Mapnik
http://live.osgeo.org/en/overview/mapnik_overview.html

Are you interested? If yes - please let us know. (subscribe to the
OSGeo-Live (Live-demo) mailing list [4] or write to astrid_e...@osgeo.org)

Regards

Astrid from OSGeo-Live PSC

[1] http://live.osgeo.org
[2] OSM Overview http://live.osgeo.org/en/overview/osm_dataset_overview.html
[3] OSGeo-Live Dokumentation in the OSGeo wiki
http://wiki.osgeo.org/wiki/Live_GIS_Disc
[4] Live-demo mailing list
https://lists.osgeo.org/mailman/listinfo/live-demo

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

Re: [OSM-talk-nl] BAG update

[Sebastiaan Couwenberg]

On 08-01-16 15:01, Éric Piel wrote:
> Are there any recommended ways to update the BAG imported building data?
> I had a look at these pages in the wiki, but they appear to not have
> been updated for a while:
> http://wiki.openstreetmap.org/wiki/BAGimport
> http://wiki.openstreetmap.org/wiki/BAGimport_via_ODS_plugin
> 
> I'm fairly experienced with JOSM, and I have done some building imports
> previously.
> 
> Thanks for any pointer or help!

The new version is JOSM plugin is not widely available yet, in the mean
time we coordinate BAG updates on the forum:

http://forum.openstreetmap.org/viewtopic.php?id=52973

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting

[Sebastiaan Couwenberg]

On 03-01-16 19:35, Skyler F wrote:
> So is there another way I can install this without the configure and
> autogen?

Use the packages included in Ubuntu itself. wily includes osm2pgsql
0.88.1 which is current enough.

https://launchpad.net/ubuntu/+source/osm2pgsql

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting

[Sebastiaan Couwenberg]

On 03-01-16 17:48, Graham Jones wrote:
> if you type "sudo apt-cache search libtiff" it lists all the packages that
> are available with 'libtiff' in the title.  On my system it lists
> libtiff5-dev, so I would suggest installing that.

Just install libtiff-dev, it is the virtual package provided by both
libtiff4-dev & libtiff5-dev, it will pull in the relevant libtiffN-dev
package for the distribution in question.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] Tile Server manual build 15.10 troubleshooting

[Sebastiaan Couwenberg]

On 03-01-16 18:27, Skyler F wrote:
>>  sudo apt-get install postgresql postgresql-contrib postgis
>> postgresql-9.3-postgis-2.1
> 
> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> E: Unable to locate package postgresql-9.3-postgis-2.1

Ubuntu vivid and later have postgresql-9.4 for which the postgis
packages is:

 postgresql-9.4-postgis-2.1

https://launchpad.net/ubuntu/+source/postgis

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

[OSM-talk] Call For papers Geospatial devroom @FOSDEM 2016

[Sebastiaan Couwenberg]

 Forwarded Message 
Subject: [OSGeo-Discuss] Call For papers Geospatial devroom @FOSDEM 2016
Date: Mon, 2 Nov 2015 08:22:03 +0100
From: Johan Van de Wauw 
To: OSGeo Discussions , LocationTech Working
Group discussion list 

Please forward!

FOSDEM is a free and non-commercial event bringing together about 5000
developers in Brussels, Belgium. The goal is to provide open source
software developers and communities a place to meet and share
thoughts. The participation is free of charge, although donations are
welcome. The next edition will take place the last weekend ofJanuary
30 - 31 2016. This year for the second time there will be a Geospatial
devroomon Sunday 31/1/2016, organised by members of the OSGeo,
Locationtech and OpenStreetMap communities.

Geospatial technology is becoming rapidly mainstream. The idea
underpinning the geospatial devroom is bringing together developers
with different backgrounds to disclosethe opportunities offered by
cutting-edge open source geospatial technologies. Due to the success
of last years devroom, a Belgium local chapter of OSGeo, OSGeo.be was
founded, and is now taking part of the organisation of the devroom as
driving community.

The Geospatial devroom is the place to talk about the state of the art
of open, geo-related data, free and open source geospatial software
and its ecosystem. This includes standards and tools, e.g. spatial
databases, online mapping tools, geospatial services, used for
collecting, storing, delivering, analysing, and visualizing geodata.
We welcome submissions about:

* Web and desktop GIS applications
* Interoperable geospatial web services and specifications
* Collection of data using sensors/drones/satellites
* Open hardware for geospatial applications
* Geo-analytic algorithms/libraries
* Geospatial extensions for classical databases (indexes, operations)
and dedicated databases
* Collaborative editing/versioning of geodata
* Big geodata, scalable GIS applications
* Volunteered Geograpic information - Crowdsourced data

HOW TO SUBMIT YOUR PROPOSAL FOR A TALK

Are you thrilled to present your work to other open source developers?
Would you like to run a discussion? Any other ideas? Please submit
your proposal using the Pentabarf event planning tool at:

https://penta.fosdem.org/submission/FOSDEM16

Make sure to select the 'Geospatial devroom' as  'Track'. Please,
specify in the notes if you prefer for your presentation either a
short timeslot (lightning talks ~10 minutes) or along timeslot (20
minutes presentation + discussion). However, note that time slots are
indicative and will be assigned according to the needs of the session.

The DEADLINE for submissions is Tuesday **1st December 2015**.
Notification of acceptance will be sent to the Authors by Friday
11/12/2015 at the latest.

Should you have any questions, please do not hesitate to get in touch
with the organisers of the devroom at fosdem-geospat...@gisky.be!

Johan Van de Wauw
Margherita Di Leo
Astrid Emde
Anne Ghisla
Martin Hammitzsch
Andy Petrella
Dirk Frigne
Olivier Courtin
Thomas Gratier

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

Re: [OSM-talk] open question about boundaries sharing nodes with ways or nodes

[Sebastiaan Couwenberg]

On 14-10-15 09:49, Badita Florin wrote:
> Our task is to delete all the existing admin_level=6 boundaries and start
> fresh, but this seems much more things needs to happen before you do this.

Don't delete the existing boundaries, update them to match the new
reality using the ReplaceGeometry feature in JOSM for example. When the
data for shared nodes is available, it will disconnect the other ways
from the boundary way being replaced leaving the other ways as they were.

> This way is a highway and at the same time is part of the relation of a
> boundary. This seems invalid since it merges two types of features on the
> same way instead of keeping a logical separation between two different
> things. Is this a valid way? What if the highway is modified ? since the
> highway is not a legal boundary and just happens to overlap the real
> boundary, so if the highway  is changed for any reason, it will modify the
> boundary along with it. So what's the valid thing to do here? Duplicate the
> way to save the highway way and keep a way for the boundary separated?,

In the Americas people seem to be fond of using natural features as
boundary ways, in The Netherlands we keep these strictly separate. The
administrative boundary may follow a river for example, but these are
two distinct features that happen to share a similar geometry. At the
highest zoom level in JOSM you'll see that the river way doesn't share
the nodes from the boundary and if they do that's an issue to be fixed
by disconnecting the shared node(s), each feature has its own way and
nodes. Because natural features tend to change when the administrative
boundaries do not, we have to keep them separate.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] FOSDEM 2016, 30th and 31st January 2016, Brussels

[Sebastiaan Couwenberg]

On 13-10-15 21:04, Stefan Keller wrote:
> There's a upcoming deadline for first batch of main track proposals:
> 16 October 2015.
> And there's a Proposal for a Geospatial devroomː 
> https://titanpad.com/VCAR6DZfHG

I'd love to see a bigger OSM presence in the Geospatial track, OSM was a
bit under-represented last year.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk] "Enclosing feature" on osm.org broken ?

[Sebastiaan Couwenberg]

On 12-09-15 10:39, Marc Gemis wrote:
> I recently saw two independent reports [1][2] from people that complain
> that the list of "Enclosing Features" is returning a number of
> North-African towns for features in The Netherlands.
> 
> An example is when you first go to [3] and then click with the question
> mark on the cycle road "Titus Brandsmalaan"
> 
> I checked the boundaries of those administrative units in e.g. Algeria and
> did not notice anything suspicious. They were unaltered for 9 months or
> longer.
> 
> Anyone knows what is going on ?

I suspect the unclosed boundary rings in the neighborhood Souk El Tenine
are part of the problem.

See OSMI:

http://tools.geofabrik.de/osmi/?view=multipolygon=5.33976=52.15100=8=invalid_geometry_hull,duplicate_ways,intersections,intersection_lines,ring_not_closed_hull,ring_not_closed,unconnected_end_nodes,ways,role_markers,way_end_nodes,way_nodes


Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] BAG en Top10NL PostGIS dumps van april 2015

[Sebastiaan Couwenberg]

 De fouten heb ik aan dit bericht toegevoegd. Het zijn fouten in 179
 adressen die voorkomen uit maar 7 fouten in straatnamen. Wie kan dat
 doorzetten?

Je bent zelf de meeste aangewezen persoon om deze fouten terug te melden.

https://www.kadaster.nl/web/formulier/BAG-formulieren/BAG-terugmeldingsformulier.htm

Lees ook het BAG processenhandboek waarin de verschillende velden
beschreven zijn, zo kan je duidelijk geformuleerde terugmeldingen doen.

http://www.kadaster.nl/web/artikel/download/BAG-processenhandboek-2013-1.htm

Mvg,

Bas


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

Re: [OSM-talk-nl] Uitnodiging voor brainstormsessie samenwerking OSM-RWS.

[Sebastiaan Couwenberg]

 Wat ik een hele leuke toevoeging van Rijkswaterstaat zou vinden, en
 volgens
 mij sluit dit aan op wat Hendrikklaas bedoelt, is wanneer terreinen die
 normaal niet publiek toegankelijk zijn op afspraak open zouden kunnen
 worden gesteld voor geinteresseerde openstreetmappers zoals Hendrikklaas.
 Zou dat eventueel tot de mogelijkheden behoren? Het zou een leuke
 aanvulling en prikkel kunnen zijn!

Ik wil dit voorstel graag onderstrepen.

Nederlandse Mapping Parties waarbij daadwerkelijk gemapped wordt zijn
alweer een flinke tijd geleden, het gezamelijk mappen van RWS terreinen
lijkt mij een geweldige gelegenheid om met OSM mappers en RWS personeel
samen te werken.

Mvg,

Bas


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

Re: [OSM-talk-nl] BAG vs On-The-Ground (Was: Groenlandsekade/Groenlandse Kade, Vinkeveen)

[Sebastiaan Couwenberg]

On 05/31/2015 12:14 PM, Colin Smale wrote:
 Ook in Woerden doet zich dit voor. Botnische golf, Middelandse zee,
 Finse golf hebben een afwijking tussen de schrijfwijze volgens BAG en
 de schrijfwijze op de borden ter plaatse. De conventie in Nederland is
 dat alle woorden in een straatnaam een hoofdletter krijgen, dus beschouw
 ik in deze gevallen de borden als correcter dan de BAG. Degene die de
 BAG-import heeft gedaan heeft de import-regels netjes opgevolgd en deze
 straatnamen verbeterd zodat ze nu wel overeenstemmen met de BAG, maar
 niet langer met de borden en de conventies. 
 
 Dus hebben we een situatie geschapen waarbij een officieel register
 zwaarder wordt gewogen dan de werkelijkheid ter plaatse. Hiermee
 overschrijden we één van de basisbeginselen van OSM. 
 
 Wat vindt men hier zoal van? 

Het on-the-ground principe voor de extacte schrijfwijze van borden weegt
wat mij betreft niet zo zwaar.

De borden horen ook de BAG aan te houden, maar stammen waarschijnlijk
van voor de tijd dat dit een wettelijk plicht was. Of wijken hier van af
ivm beperkte ruimte op de borden.

Geen van de schijfwijzen is wat mij betreft fout, dus beide zijn prima
acceptabel voor OSM. Het komt uit eindelijke neer een kwestie van smaak
en estetische waarde.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] luchtfotos 2014 via PDOK: licentie?

[Sebastiaan Couwenberg]

 Vraag: is het de moeite waard/is er ervaring mee om deze luchtfoto
 specifiek
 voor OSM-overtekendoeleinden van een bredere licentie te voorzien?

De licentie voorwaarden zijn te beperkend om bruikbaar te zijn voor OSM en
de bredere open geo community, dus ja het is de moeite waard om een andere
licentie te vragen.

Mvg,

Bas


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

Re: [OSM-talk-nl] Fwd: [Bug 531285] Use OpenStreetmap for maps (even allow the user to choose from list of map services)

[Sebastiaan Couwenberg]

 Hoe ze het oplossen is natuurlijk hun zaak ;)

Mozilla heeft genoeg resources om zelf een tileserver te hosten.


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

Re: [OSM-talk-nl] Juridische eisen aan data voor import

[Sebastiaan Couwenberg]

On 03/11/2015 08:23 PM, Willy Bakker wrote:
 Stel je wilt data die beschikbaar is gesteld door een partij overnemen in
 OpenStreetMap. Wat zijn dan de juridische eisen aan de data?
 Als de data zich in het publieke domein bevinden (m.a.w. gepubliceerd zijn
 met een 'public domain mark') of beschikbaar zijn gesteld onder een
 Creative Commons Zero (CC0) licentie, lijkt het me geen probleem.

Het opnemen van public-domain  CC0 data in OSM is geen probleem, want
de data is expliciet vijgesteld van copyright.

 Maar hoe zit dat met data waarvan niet duidelijk is wat de licentie voor
 hergebruik is? Ik neem aan dat het overnemen van de data in OpenStreetMap
 dan uitgesloten is.

Als er geen duidelijke licentie voor de data is gelden automatisch de
copyright regels waarbij alle rechten zijn voorbehouden aan de auteur.

De auteur/copyright houder moet expliciet afstand nemen van deze
exclusieve rechten door de werken onder een bepaalde licentie uit te
brengen.

 En wat als de data een CC-BY, CC-NC of CC-SA licentie hebben? Dan voorzie
 ik toch ook problemen of heb ik het mis?

De licentie van de werken die je in OSM wilt opnemen moeten
herlicensering onder de ODbL toestaan zoals gebruikt voor de OSM database.

Er is geen duidelijke compatibility matrix voor de ODbL en andere
licenties zoals voor open source licenties wel het geval is.

CC-BY is in principe wel mogelijk, maar je moet dan wel aan de
attribution eis van de CC-BY licentie voldoen door de attribution toe te
voegen aan de OSM copyright pagina.

http://www.openstreetmap.org/copyright

Voordat je die wijziging er door hebt ben je een flamewar verder. Dit is
een belangrijke reden waarom CBS wijken  buurten niet in OSM zijn
opgenomen, ondanks dat het wel mogelijk is met attribution.

De ODbL staat commercieel gebruik toe, dus CC-NC werken zijn daarmee
niet compatible.

CC-SA werken zijn ook problematisch, omdat de ODbL niet share-alike
genoeg is waardoor de CC-SA licentie het herlicenseren onder de ODbL
niet toe staat.

 Graag jullie mening.

Ik ben geen jurist, dus bovenstaande heeft geen juridische waarde. Door
mijn werkzaamheden voor Debian ben ik echter wel bekend met typische
licentie periekelen als deze. Op de legal-talk lijst zal je meer OSM
specifieke kennis vinden:

https://lists.openstreetmap.org/pipermail/legal-talk/

Mvg,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1

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

Re: [OSM-talk-nl] URL of Website

[Sebastiaan Couwenberg]

 In oudere gegevens van scholen, winkels enz. zijn er bij een behoorlijk
 aantal de website toegevoegd in de vorm van URL:AH.nl
 Josm is nu aan het klagen en wil graag dat het nu gebeurt in de vorm van
 website:http://AH.nl
 Na enig zoeken vond ik deze webpagina:
 http://wiki.openstreetmap.org/wiki/Key:url

 Hoe gaan we hier mee om?

De oplossing lijkt voor de hand te liggen:

De URL aanpassen naar het valide format, dus inclusief schema (http:// of
https://).

Mvg,

Bas


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

Re: [OSM-talk-nl] URL of Website

[Sebastiaan Couwenberg]

 Gaan we dit handmatig doen?

we? Volgens mij heb jij de wens om dit aan te passen, dus als het is aan
jou om te kiezen tussen handmatig aanpassen of dit proces te
automatiseren.

Handmatige verwerking heeft de voorkeur omdat je dan geen mechanical edit
hoeft goed te laten keuren. Ook heb je meer controle over edge cases die
je snel over het hoofd ziet als je alles geautomatiseerd aanpast. Met
mechanische edits is het eenvoudig veel data in een keer foutief te
bewerken, wat het belangrijkste argument is om mechanische edits eerst met
de community te bespreken.

 Ik zie regelmatig scripts voorbij komen die wereldwijd van alles en nog
 wat
 aanpassen.
 Ik kan me voorstellen dat dit een aardig klusje daarvoor is.

Als je het meer dan een handvol objecten wilt aanpassen ligt automatiseren
voor de hand, maar daarvoor moet je wel door het politieke process heen.
M.i. is het een betere besteding van je tijd om de objecten die je
tegenkomt bij het mappen aan te passen en de rest te laten voor wat het
is.

Als dit probleem door QA tools als Osmose getoont word is het voor andere
mappers makkelijker om te helpen bij het corrigeren van de url tags als
zij dat ook als een probleem ervaren.

Voor data consumers is het een gegeven dat ze met verschillende formats
overweg moeten kunnen. Veel daarvan zullen de ontbrekende schemas zelf
toevoegen waardoor het niet veel uit maakt dat het in de OSM data
ontbreekt.

Mvg,

Bas


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

Re: [OSM-talk-nl] Gemeentelijke herindeling

[Sebastiaan Couwenberg]

On 12/27/2014 07:06 PM, Stefan de Konink wrote:
 On Saturday, December 27, 2014 4:24:16 PM CEST, Sebastiaan Couwenberg
 wrote:
 De belangrijkste reden om de gemeentelijk indeling nu nog niet te
 uploaden is de ingangsdatum van 1 januari. Het is erg voorbarig om het
 daarvoor al te uploaden.
 
 Geef even een seintje wanneer het er doorheen is. Dan gooi ik
 tile.openstreetmap.nl even helemaal leeg. Als het goed is is exporteer
 functie om bestanden te wissen weer gerepareerd, kunnen we op 1-1 weer
 mooi beginnen.

Done: http://www.openstreetmap.org/changeset/27832460

Met de beste wensen voor 2015!

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Gemeentelijke herindeling

[Sebastiaan Couwenberg]

On 12/27/2014 02:54 PM, wouter van der plas wrote:
 het is al bijna 2015.
 
 op 1 jan gaan de Gemeentelijke herindeling van krach dus ik dacht ze nu
 maar alvast in osm te zetten.

Doe nog maar even niet!

 maar ik weet niet of dat andere hier al mee bezig waren.
 ik zelf woon in Bernisse die samengevoegd word met Spijkenisse. maar ik
 vind het ook niet erg om de anderen ook te doen.
 
 mijn vraag is kan ik Bernisse en Spijkenisse samen voegen en wat gaan we
 doen met de andere gemeenten die worden samengevoegd

Ik heb de gehele gemeentelijke indeling 2015 al weken klaar staat om op
1 januari 2015 om 00:00 te uploaden naar OSM.

Het liefst hoef ik dan de conflicten met jou of andersmans edits niet op
te lossen.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Gemeentelijke herindeling

[Sebastiaan Couwenberg]

On 12/27/2014 03:20 PM, wouter van der plas wrote:
 ok dat is begrepen en ik zie het vanzelf verschijnen

Hartelijk dank daarvoor.

De belangrijkste reden om de gemeentelijk indeling nu nog niet te
uploaden is de ingangsdatum van 1 januari. Het is erg voorbarig om het
daarvoor al te uploaden.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Gemeentelijke herindeling

[Sebastiaan Couwenberg]

On 12/27/2014 07:06 PM, Stefan de Konink wrote:
 Geef even een seintje wanneer het er doorheen is.

Will do.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Maandelijkse PostGIS en CSV dumps BAG beschikbaar op data.nlextract.nl/bag

[Sebastiaan Couwenberg]

 Een autonoom (cron) proces checkt dagelijks of er op de PDOK site een
 nieuw BAG bronbestand beschikbaar is, gebruikmakend van de zgn PDOK BAG
 Atomfeed. Als de Atomfile (via datum veld) aangeeft dat de BAG vernieuwd
 is, wordt deze gedownload en met NLExtract-BAG ingelezen en verrijkt
 (provincies, gemeenten, adres tabel) in PostGIS. Vervolgens worden
 PostGIS en CSV dumps aangemaakt en ter download neergezet.

Voor mijn eigen BAG database doe ik nagenoeg hetzelfde. Voor het
automatisch kunnen importeren van de inspireadressen moest ik wel een
argument toevoegen aan NLExtract om niet te prompten, hoe hebben jullie
dat opgelost zodat er geen interactie nodig is?

 Normaal gesproken zal er op iedere 8e/9e van de maand een verse BAG
 zijn, hoewel PDOK recentelijk wat storingen daarin had...

De updates van oktober en november zijn dit jaar net als vorig jaar
overgeslagen. Dat vorige jaar dezelfde maanden zijn overgeslagen is
opvallend, ik vermoed een structureel probleem.

Mvg,

Bas


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

Re: [OSM-talk-nl] [Dutch] Maandelijkse PostGIS en CSV dumps BAG beschikbaar op data.nlextract.nl/bag

[Sebastiaan Couwenberg]

 On 23-12-14 13:17, Sebastiaan Couwenberg wrote:
 Een autonoom (cron) proces checkt dagelijks of er op de PDOK site een
 nieuw BAG bronbestand beschikbaar is, gebruikmakend van de zgn PDOK BAG
 Atomfeed. Als de Atomfile (via datum veld) aangeeft dat de BAG
 vernieuwd
 is, wordt deze gedownload en met NLExtract-BAG ingelezen en verrijkt
 (provincies, gemeenten, adres tabel) in PostGIS. Vervolgens worden
 PostGIS en CSV dumps aangemaakt en ter download neergezet.

 Voor mijn eigen BAG database doe ik nagenoeg hetzelfde. Voor het
 automatisch kunnen importeren van de inspireadressen moest ik wel een
 argument toevoegen aan NLExtract om niet te prompten, hoe hebben jullie
 dat opgelost zodat er geen interactie nodig is?
 Ja daar moet een override-optie komen.
 Voorlopig zo opgelost:

 ./bag-extract.sh -c  ja.txt
 en in ja.txt staat alleen 'j' ;-)

Ik heb mijn change hiervoor geforward in een pull request:

https://github.com/opengeogroep/NLExtract/pull/135

Mvg,

Bas


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

Re: [OSM-talk-nl] Privacy van deze mailinglijst?

[Sebastiaan Couwenberg]

On 12/24/2014 08:39 AM, Léon Tebbens wrote:
 Hoe kunnen we ervoor zorgen dat emailadressen onzichtbaar gemaakt worden?

Door de mailinglist administrators aan te schrijven en niet de lijst. :)

Talk-nl list run by henk at toffehoff.nl, mvexel at gmail.com

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

Re: [OSM-talk-nl] Toevoegen aan adres-node?

[Sebastiaan Couwenberg]

On 12/11/2014 08:34 PM, Marc Zoutendijk wrote:
 Bij de BAG import zijn ook alle adrestags meegekomen, en mijn vraag is of ik 
 aan zo'n adrestag wat mag toevoegen?

Waarom denk je hier toestemming voor nodig te hebben?

 Nu ik bezig ben (zie links hieronder) met al die amenity en shop tags, zou 
 het praktisch zijn om aan zo'n adrestag ook de overige eigenschappen van dat 
 adres toe te voegen.
 Dus als ik het adres van de bakker weet, mag ik dan aan die adrestag ook 
 shop=bakery vastmaken?

Zolang er niet meerdere features zijn op het zelfde adres is het prima
om de tags aan de adres node te hangen.

Als er verschillende features op hetzelfde adres zitten is het beter de
adres node te dupliceren voor elke afzonderlijke feature en deze binnen
de pandcontour te verdelen.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Wikipedia

[Sebastiaan Couwenberg]

On 11/16/2014 12:08 PM, Gertjan Idema wrote:
 Waar ik zelf nog niet helemaal uit ben, is hoe je de wikipedia pagina's
 van plaatsen in Friesland zou moeten taggen. Zelf heb ik voor de
 gemeentes wikipedia=nl:... gebruikt en ik zag dat Bas dat voor de
 woonplaatsen ook doet. Maar als je de regels strikt zou naleven, zou je
 misschien wikipedia:fy moeten gebruiken. In België gebruiken ze
 wikipedia:fr voor Luik, wikipedia:de voor Eupen en wikipedia:nl voor
 Antwerpen.

Ik laat het aan de Friezen over om wikipedia:fy tags toe te voegen zoals
ze ook doen met name:fy :)

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Wikipedia

[Sebastiaan Couwenberg]

On 11/16/2014 07:03 AM, Ronald Stroethoff wrote:
 Sebastiaan Couwenberg wrote:
 
 On 11/15/2014 05:09 PM, Ronald Stroethoff wrote:
 Ik zie dat iemand druk bezig is met het maken van links naar wikipedia.

 Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij
 het beoordelen van de wijzigingen.

 http://www.openstreetmap.org/changeset/26768915

Dit is een changeset van mij, daarin heb ik alleen wikipedia tags
toegevoegd.

Deze changeset komt niet overeen met je klacht over wereldwijde edits
waar meerdere wikipedia tags worden vervangen met een enkele.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Wikipedia

[Sebastiaan Couwenberg]

On 11/16/2014 07:06 AM, Ronald Stroethoff wrote:
 Sebastiaan Couwenberg wrote:
 
 On 11/15/2014 05:09 PM, Ronald Stroethoff wrote:
 Ik zie dat iemand druk bezig is met het maken van links naar wikipedia.

 Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij
 het beoordelen van de wijzigingen.

 http://www.openstreetmap.org/changeset/26714979

In deze changeset worden wel meerdere wikipedia tags verwijdert om
alleen de primaire taal over te houden.

Als ik even snel kijk naar de andere talen hebben die artikelen geen
meerwaarde over het artikel in de primaire taal. Maar ik ben niet alle
talen machtig om het inhoudelijk goed te kunnen beoordelen.

In principe zie ik ook geen probleem met deze changeset.

Mocht je van mening zijn dat de extra wikipedia tags toch wel meerwaarde
bieden, ze dan gerust terug en ga in discussie met Jake Strine over het
verwijderen van de tags.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Wikipedia

[Sebastiaan Couwenberg]

On 11/15/2014 05:09 PM, Ronald Stroethoff wrote:
 Ik zie dat iemand druk bezig is met het maken van links naar wikipedia.

Heb je expliciete voorbeeld, links naar een of meer changesets helpt bij
het beoordelen van de wijzigingen.

Ik heb zelf bijvoorbeeld recent wikipedia tags toegevoegd voor alle
woonplaatsgrenzen.

 De gebruikte manier is:
 wikipedia=nl:Warmond
 Op de website:
 http://wiki.openstreetmap.org/wiki/Key:wikipedia
 worden twee manieren genoemd:
 wikipedia=en:St Paul's Cathedral
 en
 wikipedia:en=Museums in Paris
 
 vooral bij grotere plaatsen en toeristische plekken is de kans groot dat er 
 wikipedia-pagina´s in meerdere talen zijn.

In principe is een wikipedia tag genoeg, via de interwiki links kan met
bij de andere talen komen.

Voor het geval een object in een andere taal beter beschreven word
kunnen de taal specifieke (wikipedia:lang=*) tags ook toegevoegd
worden. Voor het toevoegen van extra wikipedia tags moet de extra taal
meerwaarde bieden boven het artikel in de taal van het betreffende land.

 Ik heb al wereldwijde edits gezien waarbij een locatie een hele rits pagina
 ´s had, en die dus vervangen door 1 pagina.

Als er geen meerwaarde zit in de andere talen is een wikipedia tag
voldoende. Dus er is niet per se een probleem met deze edits als door
jou beschreven.

 Graag hoor ik hoe we hiermee moeten omgaan?

Tot dusver zie ik geen probleem, dus lekker zo laten.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Sites met OSM zonder attribution

[Sebastiaan Couwenberg]

 Maar o.a. om het OSM project meer bekendheid te geven, vragen we steeds
 dat er een copyright notice op de kaartjes staat.

Wanneer OSM data gebruikt worden en niet alleen tiles (die onder CC-BY-SA
licentie vallen), is de belangrijkste reden dat de ODbL licentie
attribution vereist zoals in duidelijke taal beschreven in de summary:

http://opendatacommons.org/licenses/odbl/summary/

De OSM legal FAQ is ook een goede resource om naar te verwijzen:

http://wiki.openstreetmap.org/wiki/Legal_FAQ/CC-BY-SA_Archive#I_would_like_to_use_OpenStreetMap_maps._How_should_I_credit_you.3F

In het schrijven zou ik deze links opnemen zodat men de achtergrond
informatie eenvoudig kan raadplegen.

Mvg,

Bas


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

Re: [OSM-talk-nl] OSM verjaardagsfeestje

[Sebastiaan Couwenberg]

Er is nog weinig gebruikt gemaakt van de Doodle ondanks het overnemen
van het bericht op het forum.

Wat de locatie betreft zijn er in de buurt van de Onze-Lieve-Vrouwetoren
diverse kroegen te vinden. Dat lijkt me de aangewezen locatie als de
keus op Amersfoort valt.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] BAG import nacontrole

[Sebastiaan Couwenberg]

On 07/25/2014 12:11 PM, Maarten Deen wrote:
 Kan iemand dit ook even op het forum wil posten?

Done: http://forum.openstreetmap.org/viewtopic.php?id=26440

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Mapping party Friesland

[Sebastiaan Couwenberg]

On 07/25/2014 08:57 PM, Harry van der Wolf wrote:
 Goed, en nu?
 
 Friesland is ondertussen gedaan door rivw en Mapping_Fryslan.
 
 Annuleren of ..?

Volgens mij is het stuk dat Johan had gereserveerd nog niet gedaan door
rivw noch Mapping_Fryslan, dus in dat opzicht hoeft er niets te
veranderen aan het plan.

Verder is de import nog klaar voor heel Nederland, er zijn nog
ongeclaimde gemeentes op de intekenlijst en gaten zichtbaar in jouw
polygons pagina.

Die vullen met behulp van de aanwezige mappers lijkt mij een goede optie
als ook de gereserveerde gemeentes intussen toch worden geimporteerd.

Mvg,

Bas

-- 
 GPG Key ID: 4096R/E88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1


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

Re: [OSM-talk-nl] Eems-Dollardgebied

[Sebastiaan Couwenberg]

 Weet iemand hoe de uiteindelijke grens komt te liggen in het
 Eems-Dollardgebied?

Dit is nog niet duidelijk. Maar gezien er slechts gesproken word over
afspraken over wie waarvoor verantwoordelijk is, vermoed ik dat er geen
grens aanpassing komt. De NL grens is al volgens de internationale
afspraken, de nieuwe Duitse grens is dit echter niet.

Duitsland moet het akkoord nog goedkeuren waarna het in een officieel
verdrag omgezet kan worden. Voordat verdrag er is hoeven we iig nog niets
te verwachten.

Zie ook het draadje duitse grensverovering op het forum over dit issue:
http://forum.openstreetmap.org/viewtopic.php?id=25074

Mvg,

Bas


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

Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?

[Sebastiaan Couwenberg]

On 05/04/2014 07:30 PM, webmind wrote:
 On 27/04/14 13:52, Sebastiaan Couwenberg wrote:
 On 04/27/2014 01:34 PM, ekes wrote:
 On 27/04/14 12:09, Sebastiaan Couwenberg wrote:
 Het grote verschil is dat jou huisnummers de hele range in 1 node
 zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn.

 De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in
 de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst.

 Als ik kijk naar grote, meer complex, gebouwen, waar ik de panden van
 binnen ken. Er lijkt geen correlatie tussen de positie van kamers binnen
 de gebouw en de plaats waar de BAG import het node plaatst.

 Wat vinden mensen van zo een panden die zij kennen?

 Zodra er veel adressen binnen een pand vallen laat de plaatsing in de
 BAG wat te wensen over.

 De wolk adres nodes nodigt uit om deze te mergen tot een of een klein
 aantal nodes met meedere adressen. Dit breekt alleen met de BAG
 conventie die 1 adres per node gebruikt.
 
 Is dit een probleem? de semi willekeurige verdeling maakt er nu meer een
 zooitje van.

De BAG plugin ondersteunt nog geen interpolated address ways, dat is een
beperkende factor op dit moment.

Nu we veel Nederlandse adressen in OSM hebben moeten we de richtlijnen
hoe daarmee om te gaan uitwerken.

Wat doen we bijvoorbeeld met adressen over meerdere verdiepingen?

 Wat ik me vooral practisch afvraag is, of ik nu de overbodige bag-nodes
 kan verwijderen of dat Nominatim dan huizen niet meer kan vinden. Kan
 als je tagged als 60-70 Nominatim daar huisnummer 62 in vinden?

Nominatim ondersteunt interpolated address ways. Dus als je de
addr:interpolation gebruikt kunnen de tussenliggende huisnummers ook
gevonden worden.

Zie bijvoorbeeld Amstelvlietstraat 351-571:
http://www.openstreetmap.org/way/217536721

En bijvoorbeeld huisnummer 375:
http://nominatim.openstreetmap.org/details.php?place_id=9177282248

Mvg,

Bas

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

Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?

[Sebastiaan Couwenberg]

On 05/04/2014 08:21 PM, Sebastiaan Couwenberg wrote:
 On 05/04/2014 07:30 PM, webmind wrote:
 Wat ik me vooral practisch afvraag is, of ik nu de overbodige bag-nodes
 kan verwijderen of dat Nominatim dan huizen niet meer kan vinden. Kan
 als je tagged als 60-70 Nominatim daar huisnummer 62 in vinden?
 
 Nominatim ondersteunt interpolated address ways. Dus als je de
 addr:interpolation gebruikt kunnen de tussenliggende huisnummers ook
 gevonden worden.
 
 Zie bijvoorbeeld Amstelvlietstraat 351-571:
 http://www.openstreetmap.org/way/217536721
 
 En bijvoorbeeld huisnummer 375:
 http://nominatim.openstreetmap.org/details.php?place_id=9177282248

Nominatim ondersteunt geen address interpolation op nodes, Ambulance
Amsterdam op Karperweg 19-25 kan niet gevonden worden, met geen van de
huisnummers noch de hele range.

http://www.openstreetmap.org/node/2412984307

Of Rijtuigenhof 6-10, Amsterdam, de individuele adres nodes uit de BAG
worden wel door Nominatim gevonden, maar de node met address
interpolation niet.

http://www.openstreetmap.org/node/565552584

Het samen voegen van adres nodes in een node m.b.v. interpolation is dus
niet aan te raden.

Mvg,

Bas

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

Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?

[Sebastiaan Couwenberg]

On 04/26/2014 08:37 PM, clara wrote:
 Ik wilde het beste van allebeide: de goede huisnummers én de goed BAG
 informatie :)
 
 Zolang de HOT layer nog niet opnieuw gerendered is, heb je daar trouwens
 nog de correcte versie van huisnummers in het WG-Terrein..
 Mischien iets om te verglijken.

Op het moment van je eerste mail was de HOT rendering al gelijk aan de
standaard OSM rendering. Ik gebruik die nooit, dus had een schone cache.

Als ik de oude situatie vergelijk met behulp van de Geofabrik extract
van 2014-02-01, zie ik eerlijk gezegd niet veel verschillen.

Het grote verschil is dat jou huisnummers de hele range in 1 node
zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn.

De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in
de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst.

Ik heb jouw adres nodes uit de oude Geofrabrik extract gecopieeerd, en
nu op de building way met entrance=yes gezet. Dit lijkt mij de best of
both worlds. We hebben de adressen zoals ze in de BAG staan, en die
hebben we in OSM nog eens verfijnt door de ingangen voor die adressen
ook op te nemen.

Is deze situatie voor jou ook goed nu? En mis je nog meer adressen bij
ingangen die met de import verwijderd zijn?

Mvg,

Bas

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

Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?

[Sebastiaan Couwenberg]

On 04/27/2014 01:34 PM, ekes wrote:
 On 27/04/14 12:09, Sebastiaan Couwenberg wrote:
 Het grote verschil is dat jou huisnummers de hele range in 1 node
 zetten, en de adressen vanuit de BAG allen afzonderlijke nodes zijn.

 De plaatsing van de huisnummers is vrijwel gelijk. De BAG plaatst ze in
 de verschillende verblijfsobjecten, en jij hebt ze bij de ingang geplaatst.
 
 Als ik kijk naar grote, meer complex, gebouwen, waar ik de panden van
 binnen ken. Er lijkt geen correlatie tussen de positie van kamers binnen
 de gebouw en de plaats waar de BAG import het node plaatst.
 
 Wat vinden mensen van zo een panden die zij kennen?

Zodra er veel adressen binnen een pand vallen laat de plaatsing in de
BAG wat te wensen over.

De wolk adres nodes nodigt uit om deze te mergen tot een of een klein
aantal nodes met meedere adressen. Dit breekt alleen met de BAG
conventie die 1 adres per node gebruikt.

 Ook er is geen indicatie van hoogte (level=)? Veel nodes binnen een
 complex pand liggen nu naast elkaar, terwijl ze beter boven op elkaar
 kunnen liggen als de bedoeling is om de binnenkant van de pand in kaart
 te brengen.

De plugin verschuift de nodes die op exact dezelfde positie liggen een
klein stukje om JOSM Validator waarschuwingen voor
nodes-at-same-position te vermijden.

Als de van de verblijfsobjecten hoogte informatie is af te leiden,
zouden we de plugin aan kunnen passen om automatisch level=n tags toe
te voegen.

 Ik zie dit anders, maar ook interessant, is met gesplitste huizen.
 Nummers 123-H, 123-1, 123-2 komen op elkaar, zonder level, en het lijkt
 toevallig welke gerenderd is.
 
 ekes

Mvg,

Bas

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

Re: [OSM-talk-nl] huisnummers in Amsterdam-West terug-draaien?

[Sebastiaan Couwenberg]

On 04/26/2014 05:08 PM, clara wrote:
 Verglijk bijvoorbeeld
 http://www.openstreetmap.org/?mlat=52.36320mlon=4.86989#map=18/52.36271/4.87015
 
 en de nog niet nieuw gerenderde versie in de Humanitarian layer.
 
 http://www.openstreetmap.org/?mlat=52.36320mlon=4.86989#map=18/52.36300/4.86973layers=H
 
 Wat is de beste manier dat terug te draaien, zonder ook alle panden weer

Waarom terug draaien als we de nieuwe situatie ook kunnen corrigeren?

Gezien ik de BAG import in Amsterdam West heb gedaan, zal ik die taak op
mij nemen.

Mvg,

Bas

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

Re: [OSM-talk-nl] Donderdag mappersbabbel Amsterdam

[Sebastiaan Couwenberg]

 Beetje late aankondiging maar morgen (donderdag de 20e) is er weer een
 Mappersbabbel in Amsterdam.

 [...]

 Vaste tijd en plaats: 19:00 bij Kaptein Zeppo's aan het 'Gebed Zonder End'
 in het centrum van Amsterdam.

Ik ben in principe van de partij, maar ik ga 19:00 niet halen vrees ik.

Gaat zaterdag 15 maart ook nog door op een andere locatie?

Mvg,

Bas


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

Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import

[Sebastiaan Couwenberg]

 En waarom niet gemeente ipv gem.? Of zijn er daar edelstenen te vinden?

Omdat de naam in de BAG 'Spaarndam gem. Haarlem' is. Deze naam moet in een
name tag terug te vinden zijn.

Voor display doeleinden heeft Spaarndam de voorkeur tenzij op de borden
iets anders staat, voor matching met de BAG data is diens benaming nodig.

official_name was in principe alleen voor land namen zoals beschreven in
de wiki, dus is maar voor alt_name gekozen.

http://wiki.openstreetmap.org/wiki/Key:name

Mvg,

Bas


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

Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import

[Sebastiaan Couwenberg]

On 01/14/2014 07:34 PM, Léon Tebbens wrote:
 De gemeentegrens tussen Haarlem en Spaardam geeft foutmeldingen in Keepright: 
 http://keepright.ipax.at/report_map.php?schema=90error=45475266 . Ik kom er 
 niet achter wat het probleem is. Lijkt te komen door de BAG import.
 
 Iemand een idee wat hier mis is?

KeepRight kan niet goed overweg met boundaries, wanneer KeepRight klaagt
over een boundary is het verstandig om OSMI te raadplegen of de
multipolygon ook invalid is of dat er een invalid geometry gerapporteerd
word.

999 van de 1000 keer zijn de boundary split warnings in KeepRight
onterecht, en is de boundary correct.

Op het punt in kwestie komen 3 woonplaatsen en 3 gemeenten samen, alle 6
deze relaties zijn gewoon valid. Haal ze maar eens door de JOSM
validator en relation anaylizer.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Fout in gemeentegrens bij Haarlem door BAG import

[Sebastiaan Couwenberg]

On 01/14/2014 11:16 PM, Gertjan Idema wrote:
 Blijkbaar kan Keepright niet goed tegen twee administratieve gebieden
 met de zelfde naam op het zelfde level die aan elkaar grenzen.

Volgens mij is het nog simpeler dan dat, in de KeepRight code waar deze
warning vandaan komt staat het volgende:

// degenerated loops are not rings. for example:
//
//   +---+
//   |   |
//   |   |
//   +---+-
//
// they can be found because the invalid junction node
// belongs to three ways. The algorithm of ordering ways
// assigns one sequence_id twice

KeepRight staat vol met The boundary of $1 splits here warnings, voor
elke node die deel is van meer dan 2 boundary relaties.

Ik zie niet zo snel een fix voor dit probleem. En het helpt ook niet dat
KeepRight niet meer actief onderhouden word, waardoor het erg
onwaarschijnlijk is dat de originele developer het op kan lossen.

We doen er waarschijnlijk goed aan dit issue te documenteren, zodat het
feit dat dit false positives zijn makkelijker te vinden is.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] OSGeo.nl + OSM-NL Nieuwjaarsborrel 12 januari *5-min per Spreker*

[Sebastiaan Couwenberg]

Hi Just,

Ik heb geen spreektijd nodig, mijn vorige mail was slechts bedoeld om te
bevestigen dat ik van plan ben om te komen.

En om aan te geven dat geintreseerden mij aan de broek kunnen trekken
voor een praatje over Debian GIS en OSGeo-Live of de BAG woonplaats
grenzen tools als daar behoefte voor is.

In het uitzonderlijke geval dat daar veel animo voor was zou ik bereid
zijn mijn podiumvrees te trotseren en toch een praatje voor de hele zaal
te houden, maar dat lijkt niet nodig gelukkig :-)

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] OSGeo.nl + OSM-NL Nieuwjaarsborrel 12 januari

[Sebastiaan Couwenberg]

Hi Just,

Ook ik ben van de partij in Hilversum. Ik ben echter niet erg
comfortabel met public speaking, maar wil wel ter plekke iets
vertellen/demoen over het Debian GIS project en wat het voor OSGeo Live
kan betekenen en/of mijn BAG woonplaats grenzen tools, als daar
interesse in is.

Mvg,

Bas

On 12/19/2013 06:16 PM, Frank Steggink wrote:
 Hoi Just,
 
 Ik wil wel een praatje houden over mijn visualisatieprojectjes o.b.v.
 NLExtract en TileMill. Het zal vnl. een beetje demoën/showen worden.
 
 Groeten,
 
 Frank
 
 On 19-12-2013 15:22, Just van den Broecke wrote:
 Klinkt goed! We hebben nog geen echte invulling voor een programma. We
 gaan in ieder geval ook ruimte houden voor ter-plekke lightning
 praatjes, bijv. aankondiging project waar je mensen voor zoekt, een
 aktiviteit die je zou willen starten (geconverteerde BAG data
 hosting?), ik noem maar iets. Zang, dans en/of gitaar?, ook prima.

 Ik neem aan dat vertegenwoordigers van OSGeo.nl en OSM-NL/OSMF een
 verlichtend praatje gaan houden. Als er meer bekend is over BAGImport
 praatje (wie?) laat mij weten dan zet ik dat ook op de site/Meetup.
 Voor we het weten hebben we een mini-conferentie :-).

 groet,

 Just
 On 19-12-13 09:34, Johan C wrote:
 Er is een idee om een presentatie te geven over de BAGimport. Maar ik
 heb dat (vanwege andere verplichtingen eerder die middag) dan liever aan
 het begin tussen 3 en 4. Het is nl. interessant genoeg voor alle
 aanwezigen (denk ik)

 Gr. Johan

 Op woensdag 18 december 2013 schreef Just van den Broecke
 (j...@justobjects.nl mailto:j...@justobjects.nl):
   Beste Mensen,
  
   Op zondag 12 januari 2014 vanaf 15:00 geven OSGeo.nl en OpenStreetMap
 de alweer bijna traditionele Nieuwjaarsborrel. Dit jaar is de locatie
 Cafe Dudok (bovenzaal) in Hilversum. Tegenover Station NS en met goede
 parkeergelegenheid. Dit is je kans om iedereen weer te ontmoeten en
 plannen te maken voor het nieuwe jaar.
  
   Als je van plan bent te komen, laat weten via de Meetup:
   http://www.meetup.com/OSGeoNL/events/156113292 of mail mij direct.
  
   We hopen jullie daar te zien!
  
   Hartelijke groet,
  
   --Just, Gert-Jan, Barend, Steven, Henk en Floris
  
   PS de plek is een leuke bovenzaal
 http://www.cafedudokhilversum.nl/135260732 met beamer en Wifi. Laat mij
 weten of je voor 15:00 nog met een werkgroep (BAG?) o.i.d. bijeen wilt
 komen, dan reserveren we vanaf eerder tijdstip.
  
  
  
  
  
  
   ___
   Talk-nl mailing list
   Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
   https://lists.openstreetmap.org/listinfo/talk-nl
  


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







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

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


-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Binnenkort ieder DAG een verse BAG!

[Sebastiaan Couwenberg]

Elke dag verse BAG data is erg fijn.

On 01/03/2014 03:05 PM, Gert-Jan van der Weijden wrote:
 De downloadservice
 (http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen
 .xml), waarmee je de gehele dataset in een keer kunt downloaden en bijv. in
 NL-extract kunt verwerken blijft een maandelijkse updatefrequentie houden.

Daadwerkelijk elke maand een nieuwe release in de ATOM service is nog
veel fijner.

Hopelijk zijn de FME issues nu opgelost waardoor dit weer mogelijk word.

En maakt de aanstaande BAG update gebruik van de gemeentelijk indeling
2014, en is het niet nog de data van december 2013.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] nationaalgeoregister WFS service query

[Sebastiaan Couwenberg]

On 10/17/2013 12:36 AM, nouwsfam wrote:
 Ik heb nog twee wensen: 
 
 a) bepaalde gemeenten uitfilteren. Dat kan waarschijnlijk niet aan de
 kant van de WFS server. Dus ik zal een filter in openlayers moeten
 aanbrengen, nietwaar? 
 
 b) de data gemeenten_2012 kan ik voor deze toepassing net zo goed lokaal
 opslaan (xml) en lokaal laden. Op welke manier moet ik deze data dan
 inlezen via OpenLayers? 

Ik zou beide wensen combineren door de TOPgrenzen zelf in een PostGIS
database te laden en met MapServer of Geoserver via WFS/WMS te serveren.
Zoals ik in het topic op het forum eerder had gepost. Het is wel wat
meer werk, maar daardoor heb je wel alles in eigen hand om naar
hartenlust aan te passen.

In mijn OpenLayers site heb ik naast de PDOK BAG WFS ook mijn eigen BAG
WFS (momenteel alleen woonplaatsgrenzen), omdat de PDOK BAG WFS niet
genoeg metadata bevat voor wat ik ermee wil doen.

Wederom is de OpenLayers route weer laagdrempeliger. Filteren van WFS
requests is mogelijk. Dit voorbeeld heb je vast al gevonden:

http://dev.openlayers.org/releases/OpenLayers-2.13.1/examples/wfs-filter.html

Dit is voor wens a, voor wens b moet je toch echt met OGC servers aan de
slag. Hoewel je misschien af kan met een caching proxy als zoiets
bestaat voor WFS services.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] nationaalgeoregister WFS service query

[Sebastiaan Couwenberg]

On 10/15/2013 11:49 PM, nouwsfam wrote:
 Is er iemand die mij een voorbeeld kan geven van hoe ik de
 gemeentegrenzen_2012 uit de WFS service van
 geodata.nationaalgeoregister.nl kan krijgen?

In mijn OpenLayers site gebruik ik jQuery om m.b.v. de GetCapabilities
requests dynamisch WFS layers toe te voegen.

Voor de bestuurlijke grenzen WFS word uiteindelijk een Vector Layer als
deze gegenereerd:

wfs_layers[key][i] = new OpenLayers.Layer.Vector(layer_name, {
strategies: [new OpenLayers.Strategy.BBOX()],
protocol: new OpenLayers.Protocol.WFS({
version: 1.0.0,
srsName: 'EPSG:28992',
url:
'http://geodata.nationaalgeoregister.nl/bestuurlijkegrenzen/wfs',
featurePrefix: 'bestuurlijkegrenzen',
featureType: 'gemeenten_2012',
featureNS: 'http://bestuurlijkegrenzen.geonovum.nl',
geometryName: 'geom',
}),
projection: new OpenLayers.Projection('EPSG:28992'),
styleMap: wfs_stylemap[key],
});
map.addLayer(wfs_layers[key][i]);

Het verschil met jou versie is het specificeren van andere geometryName,
en de featureType en featurePrefix worden afzonderlijk gespecifieerd,
evenals het gebruik van versie 1.0.0 van het WFS protocol.

Het is mij niet helemaal duidelijk wat er mis is met jouw Vector Layer.
Ik vermoed extra vereisten in versie 1.1.0 WFS requests.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Tweede Coentunnel

[Sebastiaan Couwenberg]

 Klopt het dat er momenteel geen verbinding van de tunnelbuis richting
 noorden naar de A8 is? Je wordt via de S118 en de Verlengde Stellingweg
 gestuurd.
 http://osrm.at/3ex

Volgens mij klopt dat niet. Ik ben gister over de A5 van Schiphol naar het
Coenplein gereden, en aan de andere kant van de tunnel kan je gewoon door
over de A8.

Op het moment word het verkeer door de nieuwe tunnelbuizen gestuurd, en
zijn de oude voorlopig gesloten voor onderhoud. Dat moet nog gereflecteerd
worden in OSM.

 En de terugweg wordt ook niet via de Coentunnel gestuurd, maar ik hoop
 dat dat is omdat way 115021650 de verkeerde kant op ging. De westelijke
 nieuwe tunnelbuis is als oneway:reversible aangeduid, ik hoop dat de
 routeplanners daarmee om kunnen gaan (en klopt dit met de
 werkelijkheid?).

Ik heb helaas geen beeldmateriaal van de rit bij gebrek aan een dashcam,
maar op Youtube staan wel wat fimpjes van iemand anders:

https://www.youtube.com/watch?v=WxMYT4sLFMw
https://www.youtube.com/watch?v=0cHhsVmyoVg
https://www.youtube.com/watch?v=VVJaPLXf6Y0

Mvg,

Bas


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

Re: [OSM-talk-nl] Tweede Coentunnel

[Sebastiaan Couwenberg]

On 05/14/2013 10:08 PM, Johan C wrote:
 Heeft iemand al een foto genomen van de verkeersborden ter plaatse zodat de
 destination en destination:ref tags ingevoerd kunnen worden?

Gezien we niet stil mogen staan op de snelweg zal foto's maken lastig
worden. Op de rit videos op Youtube zijn de borden niet altijd evengoed
leesbaar.

Op de animatie videos van Rijkswaterstaat over de Westrandweg staan de
borden duidelijk aangegeven.

Mvg,

Bas

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

Re: [OSM-talk-nl] Tweede Coentunnel

[Sebastiaan Couwenberg]

On 05/14/2013 11:24 PM, Johan C wrote:
 Met de betere dashcam of als bijrijder met een compactcamera werkt ook
 goed. Het hoeven niet per se statieportretten te zijn :-)

Heb je deze al gezien?

https://www.youtube.com/watch?v=2G1ZcCpJ_Ec

Elk bord word individueel gehighlight, veel duidelijker ga je het niet
krijgen denk ik.

De andere videos in deze playlist zijn ook de moeite waard:

https://www.youtube.com/watch?v=xVlPJhNpv_olist=PL0A5728D0E79CF904

Mvg,

Bas

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

Re: [OSM-talk-nl] Tweede Coentunnel

[Sebastiaan Couwenberg]

Meer details zijn in het bestemmingsplan 'Westrandweg-2e Coentunnel' te
vinden:

http://www.ruimtelijkeplannen.nl/documents/NL.IMRO.0363.B0902BPGST-OH01/t_NL.IMRO.0363.B0902BPGST-OH01_4.1.html

Of zijn dat niet de details waar je naar zocht?

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Multi poligons

[Sebastiaan Couwenberg]

Beste Ronald,

Het is mij ook niet helemaal duidelijk wat het probleem met de
multipolygons zijn.

On 04/04/2013 09:23 PM, Ronald Stroethoff wrote:
 Op deze plek:
 http://www.openstreetmap.org/?lat=52.2113lon=4.57431zoom=17layers=M

Er is hier een MP voor de Kager Plassen met een outer member voor het
water en meerdere inner members voor de eilanden daarin. Maar deze zijn
niet compleet, het eiland net over de grens in de Kaag is geen member
van de MP.

 Wilde ik enige verbeteringen aanbrengen, namelijk een stukje water bleek een 
 passantenhaventje te zijn en een ander stuk water heeft een eigen naam.
 
 Hiervoor moest ik dus het water in stukken knippen.

De haven had je ook zonder knippen als nieuwe way kunnen taggen die
gebruik maakt van de bestaande nodes die het stuk water en grass met
elkaar verbinden.

 Ik kwam daar meerdere problemen tegen
 
 1) stukken weiland lagen met de punten op de punten van het water waardoor 
 ze niet apart te selecteren zijn.

Middelklik in JOSM om de diverse objecten op dat punt individueel te
kunnen selecteren (met Ctrl+Klik).

 2) bij het knippen begonnen verschillende relaties te protesteren.

Als je de way selecteerd kan je in JOSM de relaties waar deze onderdeel
van zien in de Properties, rechtklik en download de incomplete members
van alle relaties voordat je hem opknipt. Dan past JOSM de relaties
automatisch voor je aan.

 ronald

Mvg,

Bas

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

Re: [OSM-talk-nl] Bussen van De Lijn in Maastricht/Tilburg

[Sebastiaan Couwenberg]

On 03/13/2013 06:56 PM, Jo wrote:
 Is deze mailing list dood en had ik m'n ei elders moeten leggen?

Deze ML is niet dood, maar wel dun bevolkt. Op het forum is meer
activiteit van mappers, hier zitten de techneuten heb ik het idee.

Om te beginnen zou ik dit issue op het forum aankaarten, de kans dat
seat ibiza daar meeleest is groter. Maar het is geen garantie, het geeft
wel een breder publiek inzicht in jou motivatie en werkzaamheden.

Een bericht aan seat ibiza sturen kan je daarna doen en verwijzen naar
de draadjes op de ML en het forum.

Niemand staat in een positie om anderen te vertellen wat ze moeten doen,
maar met wat peer pressure kan je het waarschijnlijk wel de juiste
richting op sturen.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 03/03/2013 09:52 PM, Minko wrote:
 
 Ok, ik heb de situatie daar weer hersteld.
 
 
 Die zaten kennelijk aan de grenzen vastgeklikt?

 Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik
 heb
 aangepast te controleren op dit soort zaken.

Even nadat de database weer read/write was gemaakt heb ik mijn laatste
changeset geupload met niet-boundary verbonden aan boundary fixes.

Hiermee zou alle vreemde knikken veroorzaakt met het verplaatsen van
boundaries weer in order gemaakt moeten zijn.

Later dit weekend moet ik mijn rappotage script nog eens draaien over
een verse OSM extract voor Nederland ter controle van alles wat ik
eventueel gemist heb en de nieuw geïntroduceerde verbindingen.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 03/03/2013 06:04 PM, Gertjan Idema wrote:
 Eén puntje wil ik wel in overweging geven: Als iemand netjes de
 officiële naam opgeeft in bijvoorbeeld nominatum, dan zou het wel zo
 prettig zijn als de bijbehorende plaats dan ook wordt gevonden. 

Op het moment word zelfs zonder het gebruik van de official_name tag
voor beide namen vrijwel dezelfde resultaten getoont. Dus daar hoeven we
het niet voor te doen.

On 03/03/2013 06:04 PM, Gertjan Idema wrote:
 On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote:
 Huidige status:

 done: 2000, TODO: 484, Total: 2484 (complete: 80.5152979066023%)
 
 Als ik het goed heb, zouden het er 2500 moeten zijn. (2505
 woonplaatscodes als je de 'dubbelen' mee telt).

Klopt. Ik was Flevoland vergeten in het overzicht.

Zuid Holland heb ik vandaag afgemaakt, en daarmee is de huidige status:

done: 2152, TODO: 349, Total: 2501 (complete: 86.0455817672931%)

On 03/03/2013 06:04 PM, Gertjan Idema wrote:
 On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote:
 Maar hiermee heb je niet de waterway=river wegen die vaak over grenzen
 getrokken zijn, en de verschillende highways, buildings e.d. Als je alle
 mogelijkheden wilt afvangen moet je alle data binnen de boundingbox
 ophalen en dat is al snel teveel voor een grote stad laat staan een hele
 gemeente of provincie.
 
 Als de rivier de officiële grens is, betwijfel ik of je grens en de
 rivier moet loskoppelen.

Valt wat voor te zeggen. Maar het maakt het editten van boundaries
buiten de volledige dataset om wel nodeloos meer werk.

Idealiter leven de boundaries in hun eigen layer, omdat ze niet
interacteren met de andere data. Ze hoeven niet gekoppeld te zijn voor
routing of iets dergelijks. Hekken en degelijke barriers kunnen overlap
hebben met boundaries en zouden van dezelfde ways en/of nodes gebruik
kunnen maken als een hekwerk is geplaatst om de grens op locatie aan te
duiden. Maar kunnen net zo goed los van elkaar staan.

In mijn ogen is een administratieve grens een virtuele feature die per
definitie losstaat van de features die op de grond kunnen bestaan.
Zodoende dient de logische scheiding tussen de features behouden te
worden door diens nodes en ways niet te combineren.

Wanneer een rivier of andere niet-virtuele feature gebruikt word ter
bepaling van een grens dient de logisch scheiding gerespecteerd te
worden. Zo kunnen de ways over elkaar getekend worden maar geen nodes te
sharen, of mijn voorkeur, teken de waterway en boundary vlak naast elkaar.

On 03/03/2013 06:04 PM, Gertjan Idema wrote:
 On Thu, 2013-02-28 at 01:46 +0100, Sebastiaan Couwenberg wrote:
 On 02/27/2013 09:34 PM, Gertjan Idema wrote:
 On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:
 Andere klussen:
 Het gebruik van type=boundary/type=multipolygon nog niet consequent.
 Volgens de Nederlandse conventie gebruiken we type=multipolygon. Op de
 internationale site staat echter dat type=multipolygon verouderd is. Dat
 is nogal verwarrend. Huidige status: multipolygon=2173x, boundary=327x

 Een van de JOSM ontwikkelaars pushed de standaardisatie naar
 type=boundary. En als je op basis van de wiki of taginfo beslist hoe te
 taggen zal type=boundary altijd de voorkeur hebben.

 Ik kan op zich leven met 'type=boundary' als dit overal behalve in Nederland
 en Duitsland de standaard is. Dan is het wel zaak om de Nederlandse 
 documentatie
 hier op aan te passen. Eerst maar eens uitzoeken wat destijds de argumenten 
 voor 
 type=multipolygon waren.

 Het enige nadeel aan type=boundary is wat mij betreft dat hier standaard
 een warning voor getoond word in OSMI. Maar omdat deze super eenvoudig
 uitschakelen is, het dat redelijk een non-argument.
 
 Als type=boundary de officiële standaard is, is dat in mijn ogen een bug
 in OSMI die binnenkort wel verleden tijd zal zijn.

Dat zou mooi zijn, maar ik weet het nog niet zo zeker. Het belangrijkste
is dat wij documenteren welk type we gebruiken en waarom, en hoe dat
afwijkt van bepaalde documentatie, QA tools, e.d.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 03/03/2013 07:47 PM, Minko wrote:
 Bas,
 Bij het editten van de grenzen heb je hier een aantal (fiets)paden mede 
 verplaatst:
 http://www.openstreetmap.org/?lat=52.06349lon=6.07858zoom=17layers=M
 
 Die zaten kennelijk aan de grenzen vastgeklikt?

Dat klopt. Ik ben er nog niet aan toegekomen om alle grenzen die ik heb
aangepast te controleren op dit soort zaken.

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

[OSM-talk-nl] Nederland op de Best of OSM poster

[Sebastiaan Couwenberg]

Via de Weekly OSM Summary [1] kwam het nieuws tot mij dat de nieuwe Best
Of OSM was gereleased. [2]

Op de nieuwe poster [3] heeft Nederland ook een plekje gekregen dankzij
het prachtige werk van JanFi om Paleis Het Loo, en voornamelijk de
tuinen op de kaart te zetten. [4]

Ook dank aan Lambertus voor de nominatie. [5]

Dikke pluim voor JanFi!

Nu aan ons de uitdaging om voor de volgende poster heel Nederland erop
te krijgen als eerste land met volledige adres dekking dankzij de BAG!

[1] http://opengeodata.org/weekly-osm-summary-63
[2] http://bestofosm.org/
[3] http://bestofosm.org/poster/
[4] http://bestofosm.org/#interesting-het-loo-garden
[5] http://lists.openstreetmap.org/pipermail/talk/2012-December/065393.html

Mvg,

Bas

-- 
GnuPG: 0xE88D4AF1 (new) / 0x77A975AD (old)

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

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 02/27/2013 09:34 PM, Gertjan Idema wrote:
 On Sun, 2013-02-24 at 17:09 +0100, Sebastiaan Couwenberg wrote:
 
 Het is niet handig dat de ref:woonplaatscode van Putten is aangepast
 naar de code in de meest recente BAG zonder ook de geometrie aan te
 passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het
 record in bag:extract WPL08082012, bij de aangepaste woonplaatscode
 zit ook een nieuwe geometrie van de woonplaats in bag:extract
 WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
 aangepast met de versie uit bag:extract WPL08012013.

 
 Ik was me er niet van bewust dat je al zo ver was met de BAG
 woonplaatsgrenzen. 

Dat is ook deels mijn schuld, ik heb er geen openbare progress report
oid van bijgehouden zoals voor het Woonplaatsbesluiten project is gedaan.

http://wiki.openstreetmap.org/wiki/Bestaande_geodata_hergebruiken_woonplaatsbesluiten

Het is mijn bedoeling om een dergelijk overzicht te genereren met
bijbehorende interactieve kaart voor de grenzen die in OSM geupdate
kunnen worden met de meeste recente versie in de BAG.

Hier wil ik pas echt goed voor gaan zitten als ik klaar ben met alle
woonplaatsgrenzen gelijk trekken met de inmiddels wat oude BAG, maar
gezien de woonplaatsen niet zoveel aan verandering onderhevig zijn als
de panden vind ik dat niet zo'n probleem. Voordat de grenzen met BAG
data geupdate werden was er tijden weinig tot niets aangepast, we zijn
er dus op vooruit gegaan qua actualiteit, maar nog niet helemaal
volledig up-to-date.

In eerste instantie had ik mij ook voorgenomen om de procedure die ik
volg bij het toevoegen en updaten van grenzen aan de BAGimport wiki
pagina toe te voegen, maar ik twijfelde over het nut ervan. Het
toevoegen van grenzen is een redelijk eenmalig proces, daarna zullen de
bestaande grenzen aangepast worden. Tenzij er nog nieuwe woonplaatsen in
het leven geroepen worden zal al het werk het updaten van bestaande
grenzen omvatten. Het is leek mij nuttiger om dat proces te gaan
documenteren wanneer alle ontbrekende grenzen waren toegevoegd. Daar is
het nu dus wel tijd voor aan het worden, maar ik zal hoogst
waarschijnlijk nog even procastinaten. Want ik wil mijn tijd nu nog even
in de laatste 484 woonplaatsen steken.

 2. 'Onlogische' woonplaatsnamen in de BAG:
 Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
 aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
 BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
 denk ik wel te zien waarom. (de tweede naam is de BAG naam):
 AlteveerAlteveer gem Hoogeveen
 BotlekBotlek Rotterdam
 De Hoefde Hoef
 De Luttede Lutte
 Den Haag's-Gravenhage
 De Woudede Woude
 ElstElst Ut
 EuropoortEuropoort Rotterdam
 HoogvlietHoogvliet Rotterdam
 MaasvlakteMaasvlakte Rotterdam
 PernisPernis Rotterdam
 's-HertogenboschDen Bosch
 UrsemUrsem gem. S
 VondelingenplaatVondelingenplaat Rotterdam

 Ik twijfelde welke tag hiervoor te gebruiken, official_name was
 misschien ook een optie gezien de Woonplaats als zodanig in de officiele
 bron staat. Maar alt_name is waarschijnlijk beter.
 
 Bij http://wiki.openstreetmap.org/wiki/Key:official_name staat 'It has
 been created for country names'. Er staat dus niet bij dat het niet voor
 andere namen gebruikt mag worden. Ik neig er nu toch meer naar om
 'official_name' te gaan gebruiken. Zodra we het er over eens zijn,
 kunnen we dit vermelden in de Nederlandse wiki.

Tsja, interpretatie van tags blijft een lastig issue.

Wat is de officiële naam van een woonplaats? Dat lijkt mij de naam die
op officiële documenten gebruikt word, ik denk niet dat gemeente of
provincie hints in de woonplaats naam onderdeel zijn van de officiële
naam zoals op briefpapier van het stadsbestuur word gebruikt, op de
plaatsnaamborden staat, en wat men in het postadres zou gebruiken. Het
lijkt mij deze deze in het verleden zijn toegevoegd zodat om unique
contraints in een database gewerkt kon worden, of om simpelweg in de
oude kaartenbakken op basis van de naam het onderscheid te kunnen zien.

Het hergebruiken van bestaande tags maar deze anders interpreteren voor
een nieuw project zorgt voor nodeloze verwarring bij diegenen die bekent
zijn met de originele insteek. Om dit te voorkomen kunnen we misschien
beter onze eigen tag introduceren zodat we vrij zijn deze te definiëren.
Zodoende voel ik er ook wel wat voor om bag:name of bag:woonplaatsnaam
te gebruiken voor de naam zoals het in de BAG staat. Deze namespace is
vrij voor ons om invulling te geven, en zullen minder snel aangepast
worden als de name tag. Ik zie ook liever Alteveer op de kaart dan
Alteveer gem Hoogeveen, de toevoeging tbv de uniekheid heeft geen
meerwaarde ter rendering op de kaart.

Ik wil hier niet al te veel tijd aan spenderen. Het belangrijkste is dat
we een tag kiezen en deze consistent gebruiken zodat de tools er gebruik
van kunnen maken. alt_name is lekker breed gedefinieerd en

Re: [OSM-talk-nl] Woonplaatsgrenzen: ze staan er nu allemaal in! (maar niet allemaal even accuraat)

[Sebastiaan Couwenberg]

On 02/24/2013 02:56 PM, Gertjan Idema wrote:
 Dankzij veel werk van vooral 'Sebastic' en 'It's so Funny', staan alle
 officiële woonplaatsen nu in de OSM database. Dit zijn de boundaries met
 admin_level=10.

Naar aanleiding van een bericht van It's so funny had ik ook een mail
over deze aangelegenheid in de pijpleiding zitten, maar daarvoor wij ik
mijn grenzen rapportage compleet hebben. Je bent me weer eens te snel af. :)

 Zelf heb ik de ontbrekende woonplaatscodes toegevoegd en de
 woonplaatsnamen vergeleken met de BAG data van 8-1-2013. In twee
 situaties kan er een afwijking zijn t.o.v. de BAG:
 
 1. Dubbele woonplaatscodes in de BAG:
  In overgangssituaties kan het voorkomen dat woonplaatsen in de BAG
 tijdelijk met oude en nieuwe woonplaatscodes voorkomen. Tijdelijk is
 hier een ruim begrip, want het kan meer dan een jaar zijn. In deze
 gevallen heb ik de nieuwste woonplaatscode in OSM gezet. 
 Het gaat hier om: Apeldoorn, Leimuiden, Oudkarspel, Putten en
 Rijpwetering.

Ik werk in principe nog op basis van de BAG van 08082012, maar ik heb
ook de meeste recente van 08012013 in een aparte PostGIS DB staan. Van
beide heb ik OSM files met de woonplaatsgrenzen met behulp van jouw
bag4osm osmosis plugin (nog wel

Putten had ik al gelijkgetrokken met de BAG van augustus vorig jaar,
vandaar de oude woonplaatscode 2007. Bij de borrel afgelopen donderdag
werd ik door Steven gewezen op de aangepaste grenzen per 1 januari 2013,
Putten  Nijkerk. Deze heb ik niet direct aangepast omdat ik ze als
testcase voor mijn script wilde gebruiken.

Het is niet handig dat de ref:woonplaatscode van Putten is aangepast
naar de code in de meest recente BAG zonder ook de geometrie aan te
passen. De ref:woonplaatscode/name tuple hoorde bij de geometrie van het
record in bag:extract WPL08082012, bij de aangepaste woonplaatscode
zit ook een nieuwe geometrie van de woonplaats in bag:extract
WPL08012013. Voor Putten er Nijkerk heb ik net ook de geometrie
aangepast met de versie uit bag:extract WPL08012013.

 2. 'Onlogische' woonplaatsnamen in de BAG:
 Bij een aantal plaatsen heb ik er voor gekozen om de naam in OSM niet
 aan te passen aan de officiële BAG namen. In plaats daarvan heb ik de
 BAG namen in de 'alt_name' tag geplaatst. Aan het lijstje hieronder is
 denk ik wel te zien waarom. (de tweede naam is de BAG naam):
 AlteveerAlteveer gem Hoogeveen
 BotlekBotlek Rotterdam
 De Hoefde Hoef
 De Luttede Lutte
 Den Haag's-Gravenhage
 De Woudede Woude
 ElstElst Ut
 EuropoortEuropoort Rotterdam
 HoogvlietHoogvliet Rotterdam
 MaasvlakteMaasvlakte Rotterdam
 PernisPernis Rotterdam
 's-HertogenboschDen Bosch
 UrsemUrsem gem. S
 VondelingenplaatVondelingenplaat Rotterdam

Ik twijfelde welke tag hiervoor te gebruiken, official_name was
misschien ook een optie gezien de Woonplaats als zodanig in de officiele
bron staat. Maar alt_name is waarschijnlijk beter.

Zien de OSM relations voor woonplaatsgrenzen met behulp van de
ref:woonplaatscode en diens naam (name of alt_name) tag gekoppeld worden
aan de records in de BAG is het van belang dat een van de twee tags
(name of alt_name) overeen komen met de woonplaatsnaam in de BAG.

Alteveer is trouwens een leuke, daarvan bestaan woonplaatsgrenzen in
meerdere gemeentes, en in meerdere provincies. Gelukkig hebben we nu de
ref:woonplaatscode om de 4 verschillende Alteveers te kunnen onderscheiden.

 Zoals ik in het onderwerp al vermeldde, betekent dit nog niet dat alle
 woonplaatsgrenzen nu netjes op de zelfde plek liggen als in de BAG. Dat
 is nog wel even werk.

Alleen de provincies Zuid-Holland, Utrecht, Flevoland en Noord-Holland
moeten nog gelijkgetrokken worden met de BAG, de overige provincies heb
ik reeds voltooid. Wel moet ik alles nog eens met de meest recente BAG
vergeleken worden wanneer alle admin_level=10 grenzen in OSM op basis
van de BAG zijn. Deze vergelijking zal geautomatiseerd worden, het
gelijk trekken van de overige provincies is nog wat handwerk in JOSM.
Maar met de Replace Geometry functie is het minder tijdrovend dan het
volledig handmatig mergen van alle nodes wat ik voorheen deed.

Het nadeel is wel dat met het verschuiven van de nodes deze niet
losgekoppeld worden van eventueel daaraan verbonden niet-boundary wegen.
Hier heb ik nu ook een controle script voor die met behulp van een
lokale OSM DB een rapportage maakt van alle niet-boundary wegen die
verbonden zijn met een boundary. Het handmatig losknopen hiervan is ook
nog best wat handwerk.

De Replace Geometry functie in JOSM koppelt verbonden wegen automatisch
los, maar dat kan alleen als de OSM data ervan beschikbaar is. Op zich
niet zo'n probleem, want met wat Overpass Queries is deze data ook zo op
te halen, alleen kost het uitvoeren hiervan meer tijd dan ik op het
downloaden van alle grenzen binnen een provincie wil wachten.

Nu doe ik een controle achter af. Na het updaten van alle grenzen binnen
een gemeente check of er nog niet-boundary ways 

Re: [OSM-talk-nl] Bot-wars

[Sebastiaan Couwenberg]

 Geef nou even een concreet voorbeeld.

Ik gok dat ze het hebben over de geautomatiseerde edits van pschonmann, bv:

http://www.openstreetmap.org/browse/changeset/14217588

Die vervolgens gerevert werden door woodpeck_repair, bv:

http://www.openstreetmap.org/browse/changeset/14229400

Deze wereldwijde edits zag je voorbij komen in de History tab.

Mvg,

Bas


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

Re: [OSM-talk-nl] Het taggen van BAG data.

[Sebastiaan Couwenberg]

On 10/21/2012 11:52 AM, Frank Steggink wrote:

Als een bouwvergunning verleend is, hoeft nog niet te betekenen dat al
met de bouw gestart is. Ik wist trouwens niet dat deze status ook in de
BAG aanwezig kan zijn. Geldt dit ook voor sloopvergunningen?


Sloopvergunning verleent is ook een status die ik in de BAG ben tegen 
gekomen.


Bijvoorbeeld ref:bagid=18951227
Burgemeester Schonfeldplein 2B, Winschoten

De volgende statussen kom ik in de BAG tegen:

  count   |pandstatus
--+--
   135090 | Pand gesloopt
   109979 | Bouw gestart
   330795 | Pand in gebruik (niet ingemeten)
52579 | Sloopvergunning verleend
 11109687 | Pand in gebruik
   239848 | Bouwvergunning verleend
 1656 | Pand buiten gebruik
41025 | Niet gerealiseerd pand
(8 rows)

Mvg,

Bas

--
GnuPG: 0x77A975AD

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

Re: [OSM-talk-nl] changeset terugdraaien

[Sebastiaan Couwenberg]

 Met de BAG zijn we een van de weinige landen waar de adressen open data
 is. Voorzover ik kan zien is de BAG PD, zie:
 http://www.kadaster.nl/bag/over/nieuws-bericht.asp?Id=1326Id_Categorie=23
 .

Ook volgens de open data portal is het PD:

https://data.overheid.nl/data/dataset/basisregistratie-adressen-en-gebouwen-bag-

 Ik denk dat als we de BAG of delen daarvan, willen (her)importeren, er
 bepaalde conventies moeten worden aangehouden. Er is natuurlijk al veel
 discussie geweest, en heb zelf niet alles kunnen volgen:
 http://wiki.openstreetmap.org/wiki/BAG . Ik zou die conventies daar
 opnemen. Een goed begin is de conventie in de changeset:
 http://www.openstreetmap.org/browse/way/185580580. E.e.a. dan
 uitproberen op een proefgebied als er automatisch geimporteerd wordt.

 De BAG is een 2-koppig monster: zowel adressen als gebouwen in een N-M
 relatie. Hoe hier in OSM mee om te gaan, bijv. adressen apart als
 virtuele nodes en via relations aan house-ways koppelen, of redundant?
 Goed, ik wil alleen zeggen: probeer een strategie te bedenken, voor
 herhaalbare imports, die ook rekening houdt met bestaande, hand-made
 adressen, eventuele exports tbv geocoding en probeer die eerst uit.

Op het forum loopt ook een draadje waarin we de workflow voor BAG data
proberen uit te werken:

http://forum.openstreetmap.org/viewtopic.php?id=18311

Voorals nog zijn we niet op het punt om een importer te ontwikkelen, en de
vraag is of dat wenselijk is. Op met moment werken we met de BAG data in
een aparte laag in JOSM om deze handmatig te mergen in de actieve editting
laag.

Persoonlijk denk ik dat dit ook de workflow moet worden ipv dat we het
werk uit de handen van mappers nemen en aan een geautomatiseerd proces
over laten, moeten we tools ontwikkelen die het voor mappers makkelijk
maakt om de BAG data in OSM te integreren.

Zo wil ik met MapServer een WFS layer maken voor de BAG data, zodat je de
data voor het stuk wat je aan het editten bent kunt ophalen direct in JOSM
zoals je ook de OSM en GPS data kunt ophalen.

Mvg,

Bas


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

Re: [OSM-talk-nl] Fwd: [OSM-talk] Licence redaction ready to begin

[Sebastiaan Couwenberg]

 Naar aanleiding van deze e-mail vraag ik mij af waarom het proces nu
 pas in gang gezet wordt, terwijl er nu maanden over de deadline is
 heen gegaan.

Dat vroeg ik mij ook af, en vond het volgende in het archief van de
Rebuild lijst:

The work with the license change bot have almost halted the last month,
with only around 10 commits and no real progress on the main algorithms.
This is partly because people have been occupied with other stuff (work,
life, mapping, final exams, etc) and partly because the problems with the
algorithms are really hard.

http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000244.html

I am finally done with my final exams for this semester and have turned
my attention to the redaction bot. You have asked for updates and now I
finally have some.

http://lists.openstreetmap.org/pipermail/rebuild/2012-June/000252.html

 Het is natuurlijk goed dat een recente CC-BY-SA set (eindelijk) is
 gepubliceerd. Misschien een erg belangrijke vraag: is het proces van
 de bot door gebruikers te volgen? Wat is de gebruikersnaam van de bot?
 En hoe opereert de bot, maakt deze gebruik van de API?

Wat ik uit de Rebuild lijst opmaak is er nog geen definitieve
gebruikersnaam voor de bot gekozen, op dev gebruikt het momenteel de
username 'nobody'. Zie hiervoor de berichten van de Andy Allen in de draad
die begint bij:

http://lists.openstreetmap.org/pipermail/rebuild/2012-July/000295.html

In die draad is een link gepost naar de GitHub repo waar de bot code leeft:

https://github.com/gravitystorm/openstreetmap-license-change/

Het maakt gebruik van de redaction features in de API die voorheen nog
niet gebruikt werden.

Dit is wat ik tot dusver over de status van de license change heb kunnen
vinden. Ik vermoed dat in IRC logs nog wat details te vinden zijn die de
maillinglist nog niet bereikt hebben.

Mvg,

Bas


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