Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe a MapRoulette challenge might even not be necessary. Yesterday I 
started to clean up a bit in Québec, but since it was already past 
midnight for me, I wanted to continue this morning. To my surprise 
Pierre has done a lot of work and now the entire province of Québec 
looks to be free from these errors. I just could find three errors, and 
fixed them. Bon travail, Pierre!


The OSM inspector will still be a good idea, in order to spot future errors.

To all, this is the procedure I used yesterday, and probably something 
similar also by Pierre.

* Not sure if it is a requirement, but it's better to use 64 bit Java.
* You'll need JOSM with the remote control plugin. You'll also need to 
start JOSM.
* Use Pierre's Overpass query (http://overpass-turbo.eu/s/q5K), and 
zoom/pan to the area of interest.
* Press Run and let Overpass do its work. Don't be afraid when Overpass 
mentions that the result is huge if you have a modern computer. Last 
night I wasn't experiencing any problems with 30MB data.
* Press Export, and choose JOSM. Press "Repair query" when Overpass asks 
you to decide.
* JOSM starts downloading the data. Note that you're only getting the 
outer rings.
* Go to these rings one by one, and load data (at least you'll need the 
relationship itself).

* Remove the natural=wood tag from the outer ring.
* Eventually JOSM starts looking cluttered, because of all the extra 
data. You can use the search query "type:way natural=wood role:outer" to 
see if there are still rings needing work.
* Upload your changes. Be prepared to handle conflicts if someone else 
is working near you on this issue as well.

* After a while, check Overpass Turbo again.

I'm not sure what the update frequency is, but Pierre's changes from 4 
hours ago were already processed.


Good luck!

Frank


On 01-07-2017 09:52, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 11:47:36PM +0200, Frank Steggink wrote:

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.

Ah, ok, now I understand. Since there was a lot of discussion about old
style multipolygon tagging, and since this type of problem hasn't been added
to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821

How difficult would it be to add this to OSM inspector? Not everybody has
Postgres running, and is able to use osm2pgsql. Yes, there is documentation,
but it requires some technical skills. Also, it would be very convenient to
have this updated daily.

It is not that difficult to add to the OSM Inspector and if I have the
time I'll work on that together with the Geofabrik people.


When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
 Canada and
b) most of these problems are probably caused by one little program, the
 program used to convert/import the CanVec data.

As you might have noticed, later imports, like the example I provided, don't
have that issue anymore. I'm mentioning this to express that not _all_
Canvec data is at fault! Only the first couple of versions. However, for
some reason this was never noticed up until a point that collabo

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

llly oldwas it possible that was a way of tagging
back in the days? Or was it created initially as a polygon and was
later converted to a relation?

Canvec 10.0 doesnt have the issues of double tagging, just overlapping

On Jun 30, 2017 3:22 PM, "Jochen Topf" <joc...@remote.org
<mailto:joc...@remote.org>> wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:
> Maybe I'm not understanding it, but in the OSM inspector [1]
I just see one
> case of old style multipolygon, in Manitoba. Last week, when
you posted your
> original message, I just saw one case in New Brunswick.
IIRC, it was a park,
> not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are
on the
outer ways and not on the relation), but multipolygons where
the tags
are on the relation AND on the ways.

> In the OSM inspector other errors can be seen, but the most
prevalent one is
> "Touching rings". Maybe indeed a case of suboptimal mapping,
but nothing
> which seems urgent to me.
>
> Here is an example of a forest multipolygon, imported by me
> (canvec_fsteggink). It is still version 1, but it has tags
on the relation,
> not on the rings (except for the quarries): [2]
> This is from Canvec v7.0. IIRC, we started at v6.0, and the
last version I
> know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not
seeing any such
> cases in the OSM inspector.
>
> So, I'd like to ask you to give a couple of examples where
data imported
> from Canvec is clearly wrong with regard to old style
multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954 226a3acab882d28d8500ddef8203d/
same-tags-ca.pbf

<https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf>

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/r elation/541821
<http://www.openstreetmap.org/relation/541821>

> When we have clear examples, then it might be easier to come
up with a plan
> how to fix it. But so far, I see absolutely no reason why
Canada stands out
> in a negative way. Yes, we all acknowledge that Canvec data
is suboptimal,
> but as others already have pointed out, mapping everything
by hand in
> especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases
worldwide are in
   Canada and
b) most of these problems are probably caused by one little
program, the
   program used to convert/import the CanVec data.

Mapping Canada "by hand" might be difficult because it is such
a huge
country and there aren't that many mappers. But the same
arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually.
And, yes,
errors do happen. And if we find them, we fix them and move
on. But
errors from imports can be so huge there aren't enough people
there to
fix them manually. So I think it is the job of those who did
the import
in the first place, to fix their work. If you add data to OSM
you take
on a certain responsibility. If you add more data, you have a
larger
responsibility. But saying: We don't have the manpower, so we
are taking
a shortcut and then, when it turns out the shortcut wasn't so
short
after all, whining that you don't have the manpower to fix it.
That
can't be the excuse.

Jochen
--
Jochen Topf joc...@remote.org <mailto:joc...@remote.org>
https://www.jochentopf.com/ +49-351-31778688

__ _
Talk-ca mailing list
Talk-ca@openstreetmap.org <mailto:Talk-ca@openstreetmap.org>
https://lists.openstreetmap.or g/listinfo/talk-ca
<https://lists.openstreetmap.org/listinfo/talk-ca>

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




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




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

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

On 30-06-2017 21:21, Jochen Topf wrote:

On Fri, Jun 30, 2017 at 08:16:40PM +0200, Frank Steggink wrote:

Maybe I'm not understanding it, but in the OSM inspector [1] I just see one
case of old style multipolygon, in Manitoba. Last week, when you posted your
original message, I just saw one case in New Brunswick. IIRC, it was a park,
not even from the Canvec import.

The types of problems I am talking about don't show up in the OSM
inspector. This is not old-style multipolygons (where tags are on the
outer ways and not on the relation), but multipolygons where the tags
are on the relation AND on the ways.
Ah, ok, now I understand. Since there was a lot of discussion about old 
style multipolygon tagging, and since this type of problem hasn't been 
added to OSM inspector,  this wasn't immediately obvious.

In the OSM inspector other errors can be seen, but the most prevalent one is
"Touching rings". Maybe indeed a case of suboptimal mapping, but nothing
which seems urgent to me.

Here is an example of a forest multipolygon, imported by me
(canvec_fsteggink). It is still version 1, but it has tags on the relation,
not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version I
know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any such
cases in the OSM inspector.

So, I'd like to ask you to give a couple of examples where data imported
from Canvec is clearly wrong with regard to old style multipolygon tagging.

Here are all cases in Canada (not only those from the imports):
https://tmp.jochentopf.com/954226a3acab882d28d8500ddef8203d/same-tags-ca.pbf

Here is one example where you can clearly see the problem:
http://www.openstreetmap.org/relation/541821
How difficult would it be to add this to OSM inspector? Not everybody 
has Postgres running, and is able to use osm2pgsql. Yes, there is 
documentation, but it requires some technical skills. Also, it would be 
very convenient to have this updated daily.

When we have clear examples, then it might be easier to come up with a plan
how to fix it. But so far, I see absolutely no reason why Canada stands out
in a negative way. Yes, we all acknowledge that Canvec data is suboptimal,
but as others already have pointed out, mapping everything by hand in
especially remote areas is nearly impossible.

Canada stands out in a negative way, because
a) there are so many problems. Nearly a third of the cases worldwide are in
Canada and
b) most of these problems are probably caused by one little program, the
program used to convert/import the CanVec data.
As you might have noticed, later imports, like the example I provided, 
don't have that issue anymore. I'm mentioning this to express that not 
_all_ Canvec data is at fault! Only the first couple of versions. 
However, for some reason this was never noticed up until a point that 
collaborative action was done to have it fixed. Probably because the 
rendering pipeline of the slippy map was accepting this kind of tagging 
up until recently.

Mapping Canada "by hand" might be difficult because it is such a huge
country and there aren't that many mappers. But the same arguments goes
for why you have to be extra careful importing data. If you break
something, there are not enough people to fix it manually. And, yes,
errors do happen. And if we find them, we fix them and move on. But
errors from imports can be so huge there aren't enough people there to
fix them manually.
The world is so huge that there aren't enough people to create and 
maintain a global world map. However, OSM exists. Fixing errors can also 
be crowdsourced. Martijn van Exel is really doing a great job with 
MapRoulette, for instance. Although fixing errors (cleaning up the mess 
left behind by others) is not nearly as rewarding as mapping, it might 
be easier to do, especially since there is no need for a lot of 
creativity when fixing the same kind of errors.

So I think it is the job of those who did the import
in the first place, to fix their work. If you add data to OSM you take
on a certain responsibility. If you add more data, you have a larger
responsibility.
The person who did most work initially on the Canvec import has already 
left OSM about five years ago. This was during the license change. He 
joined one of the forks, from which we hear nothing nowadays. So, don't 
count on him, and possibly not on others who were working on the Canvec 
import at that time. I'm sure he and others who were involved at that 
time regret certain decisions being made and actions being done.


However, the import was supported by the majority of the community at 
that time, and although there are people who have criticized the import 
(and also of the Geobase roads) they still exist in OSM and are 
gradually being improved by others.

But saying: We don't have the manpower, so we are taking
a shortcut and then, when it turns out the shortcut wasn't so shor

Re: [Talk-ca] Multipolygon problems

[Frank Steggink]

Hi Jochen,

Maybe I'm not understanding it, but in the OSM inspector [1] I just see 
one case of old style multipolygon, in Manitoba. Last week, when you 
posted your original message, I just saw one case in New Brunswick. 
IIRC, it was a park, not even from the Canvec import.


In the OSM inspector other errors can be seen, but the most prevalent 
one is "Touching rings". Maybe indeed a case of suboptimal mapping, but 
nothing which seems urgent to me.


Here is an example of a forest multipolygon, imported by me 
(canvec_fsteggink). It is still version 1, but it has tags on the 
relation, not on the rings (except for the quarries): [2]
This is from Canvec v7.0. IIRC, we started at v6.0, and the last version 
I know of is v10.0. Maybe v6.0 had wrong tagging, but I'm not seeing any 
such cases in the OSM inspector.


So, I'd like to ask you to give a couple of examples where data imported 
from Canvec is clearly wrong with regard to old style multipolygon 
tagging. When we have clear examples, then it might be easier to come up 
with a plan how to fix it. But so far, I see absolutely no reason why 
Canada stands out in a negative way. Yes, we all acknowledge that Canvec 
data is suboptimal, but as others already have pointed out, mapping 
everything by hand in especially remote areas is nearly impossible.


Regards,

Frank

[1] http://tools.geofabrik.de/osmi/?view=areas
[2] https://www.openstreetmap.org/relation/1481163/history

On 30-06-2017 09:52, Jochen Topf wrote:

Hi!

A week ago I wrote this email and nobody answered it yet. Does that
mean that nobody feels responsible for the import that created this data
and nobody here cares for this data?

I see three ways forward:
* We do nothing. The broken data stays in OSM. Not a good solution,
   because every user of the data has to work around this or handle the
   complaints.
* The Canadian community steps up and fixes the data, automatically or
   manually.
* We ask the Data Working Group to remove the broken import.

Jochen

On Thu, Jun 22, 2017 at 11:38:15AM +0200, Jochen Topf wrote:

Date: Thu, 22 Jun 2017 11:38:15 +0200
From: Jochen Topf 
To: talk-ca@openstreetmap.org
Subject: [Talk-ca] Multipolygon problems

Hi!

In the last days the OpenStreetMap Carto Style 4.0 is being deployed on
the OSMF tile servers. This new version of the style doesn't take
old-style multipolygons (where the tags are on the outer ways instead of
on the relation) into account any more. In a huge effort in the last
months we have converted all old-style multipolygons to the modern
tagging, so this is a good step!

Unfortunately, as a side-effect of this change, many multipolygon
relations now appear wrong on the map. This is the case for multipolygon
relations that have the same tags on the relation as well as on (some of
the) outer or inner ways. This is *wrong* tagging, and needs to be
fixed. (Note that this always was wrong tagging, even before we
deprecated old-style multipolygons, but the way the software worked with
old-style multipolygons, this problem was not visible on the map. But
now it is.)

Here is an example: http://www.openstreetmap.org/relation/1330741 . As
you can see (unless somebody fixes this :-) the clearing in the forest
that should just have grass, also has tree symbols on it. In many other
cases it is not this obvious, there are just islands in a river missing
or so.

There are about 50,000 cases like this worldwide, forests, waterways,
all sorts of areas. But the worst problem is in Canada. There are about
15,000 affected relations, most from the CanVec imports.

First, we have to make sure that there are no further imports of broken
data. I hope the people who have done those imports (and might still
continue) are here on this mailing list. If not please make them aware
of this issue and/or put me in touch with them. Second, somebody needs
to clean up the broken data, either automatically or manually. 99% of
the data has not been changed since the import, so it might be feasible
to do an automatic cleanup, but somebody has to do this. Otherwise we'll
have to do a manual cleanup, through tools such as Maproulette and the
OSM Inspector. I am currently in the process of creating Maproulette
challenges for other areas of the planet, but will not do this for
Canada at this time. Lets discuss this here first.

I can provide OSM data extracts, statistics, etc. if somebody wants to
look at the data.

All of this is part of a larger effort to fix areas in OSM. See
http://area.jochentopf.com/ for more information. There is also a thread
on the talk mailinglist at
https://lists.openstreetmap.org/pipermail/talk/2017-June/078203.html
and this issue
https://github.com/osmlab/fixing-polygons-in-osm/issues/36 .
News of the effort are posted regularly to
https://github.com/osmlab/fixing-polygons-in-osm/issues/15 .

Jochen
--
Jochen Topf  joc...@remote.org  https://www.jochentopf.com/  +49-351-31778688

[OSM-talk-nl] Aankondiging mini-seminar RD en Open Source Software

[Frank Steggink]

Hoi,

Wellicht is dit voor een aantal van jullie ook interessant, ondanks dat 
je niet op de OSGeo-mailinglijst zit. De aanleiding is een recente 
discussie (zie [1]) over de juiste RD-parameters.


Op donderdag 20 oktober a.s. organiseert OSGeo.nl het mini-seminar "RD 
en Open Source Software". Het doel is tweeledig: allereerst om de 
bezoeker kennis bij te brengen over coördinatenstelsels in het algemeen 
en het Rijksdriehoeksstelsel in het bijzonder. Het tweede doel is om 
coördinatenstelsels op een juiste manier toe te passen binnen software, 
waarbij de focus natuurlijk ligt op open source software.


Het voorlopige programma is als volgt:
* vanaf 16:00 uur: verzamelen / koffie
* 16:30: start
* 16:30 - 18:00: 1e deel
  * Erik Meerburg, GeoAcademie: introductie coördinatenstelsels en 
-transformaties
  * Jan Hartmann, Universiteit van Amsterdam / Thomas Vermaut, Fryske 
Akademy georeferentie historische kaarten (incl. triangulaties 1810 en 
1930, alsmede transformatie naar WGS84)
  * Lennard Huisman, Kadaster: relatie RD, ETRS89 en WGS84, 
moeilijkheden, overstap naar ETRS89

* 18:00 - 19:00: pauze
* 19:00 - 20:00: 2e deel
  * Edward Mac Gillavry, Webmapper: gebruik Proj.4 met OSGeo-software
  * Discussie
* 20:00: afsluiting

Het mini-seminar zal worden gehouden in de bovenzaal van Café Dudok, 
Larenseweg 1A te Hilversum (zie [2]). Tijdens de pauze is het mogelijk 
om gebruik te maken van een warme maaltijd. De kosten hiervan bedragen 
€10,- (dagmenu). Geef bij je aanmelding aan of je hiervan gebruik maakt 
of niet. Geef s.v.p. ook aan of je gebruik wilt maken van een 
vegetarische maaltijd.


Aanmelden kan door je op te geven op MeetUp (zie [3]) of door een mail 
te sturen naar Frank Steggink. Laat in je aanmelding weten of je mee 
wilt eten of niet. Geef jezelf uiterlijk zo. 16 oktober op als je mee 
wilt eten. Wie mee wil eten wordt verzocht gepast geld mee te nemen of 
€10,- over te maken op rekening NL72 INGB 0006276370 t.n.v. Stichting 
OSGEO.nl o.v.v. "RD-eten".


Mocht iemand ervaring hebben met het opnemen van presentaties en 
gemakkelijk over de juiste apparatuur kan beschikken, laat het ons 
s.v.p. weten.


Mede namens het OSGeo.nl-bestuur,

Frank Steggink

[1] http://lists.osgeo.org/pipermail/dutch/2016-August/001465.html

[2] http://www.cafedudok.com/

[3] https://www.meetup.com/OSGeoNL/events/234546607/


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

Re: [OSM-talk-nl] Luchtfoto's 2014 CycloMedia

[Frank Steggink]

Beste lijstgenoten,

Vanochtend heb ik een e-mail gekregen van Cyclomedia met de URL van de 
endpoint + inloggegevens. Je kunt de WMS op de normale manier toevoegen. 
Wanneer je de lagen opvraagt, krijg je eerst een popup waar je de 
inloggegevens moet invullen. Kies vervolgens de laag 
NL_aerial_2014_50cm, wijzig eventueel de naam voor gebruik in JOSM en 
sla de laag op.


De WMS ondersteunt geen EPSG:3857 (World Mercator), maar wel EPSG:4326 
(WGS84). Op zich is dat niet erg, want er zijn geen verschilen die door 
rotatie ontstaan tussen WM en WGS84. Op kleine schaal (landelijk niveau) 
zul je wel verschil zien, maar op het schaalniveau waarop we de 
luchtfoto's gebruiken (dus ingezoomd op buurtniveau) niet.


Een eerste indruk is dat deze laag goed ligt. Ik had ook niet anders 
verwacht, tenzij e.e.a. verschoven ligt vanwege offset-instellingen. De 
BAG-panden in Papendorp (blokkendozen) liggen perfect, maar bijv. bij 
mijn huis elders in Utrecht lijkt op het eerste gezicht een kleine 
afwijking te zijn. Bij nadere inspectie blijkt dit door de parallax te 
komen, dus het verschijnsel waarbij gebouwen gaan overhellen.


De kwaliteit van de luchtfoto's vind ik tegenvallen. Ik had er meer van 
verwacht. 50cm is dus toch erg weinig. Niet genoeg voor het tekenen van 
features als je een hele hoge kwaliteit nastreeft (bijv. BGT-niveau), 
maar nog wel bruikbaar voor het alignen van wegen, e.d. Ook is de 
schaduw hinderlijk, terwijl het contrast van de lichte delen matig is. 
Misschien is de kwaliteit beter bij gebruik van het RD stelsel in JOSM.


De gebruikte JOSM-versie is 9329, dus de laatste stabiele release (met 
RD-ondersteuning).


Groeten,

Frank

On 10-1-2016 21:43, Frank Steggink wrote:
Ik ben me nu aan het registreren. Ik vind wel dat er erg veel gegevens 
ingevuld moeten worden, bijv. geboortedatum. Ik mis dan ook een 
privacy-statement. (De link op de site gaat over de 360 graden-foto's.)


Groeten,

Frank

On 10-1-2016 21:40, Frank Steggink wrote:

Maarten,

Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet 
is toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. 
Het enige wat is toegestaan, is om ze te gebruiken voor het bijwerken 
van OSM. Je mag niet de key die je ontvangen zou moeten hebben (of 
gaat ontvangen) delen.


De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen 
dezelfde resolutie. In ieder geval is de kwaliteit van de 
Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via 
een satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 
5 à 6 oud.


Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de 
bespreking de meest recente dataset was. (De 2015 foto's werden nog 
verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, 
moet nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze 
foto's wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben 
zelf ook belang bij deze samenwerkeign.


@Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU?

Groeten,

Frank

On 10-1-2016 20:49, Maarten Deen wrote:

On 2016-01-10 20:38, Johan C wrote:

We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS
luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan
OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een
licentie aangaan met CycloMedia. Dat kun je hier doen:
http://www.cyclomedia.com/nl/openstreetmap/


Dat is goed nieuws.

Ik heb wel wat vraagjes:
Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde 
luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is.
Wat betekent precies de bewoording "I shall not integrate and/or 
visualize parts of the AerialNL50cm imagery in the OSM". Betekent 
dat soms dat ze ook niet getoond kunnen worden in JOSM?
Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen 
worden en hoe?


Maarten

___
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



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

Re: [OSM-talk-nl] Luchtfoto's 2014 CycloMedia

[Frank Steggink]

Ik ben me nu aan het registreren. Ik vind wel dat er erg veel gegevens 
ingevuld moeten worden, bijv. geboortedatum. Ik mis dan ook een 
privacy-statement. (De link op de site gaat over de 360 graden-foto's.)


Groeten,

Frank

On 10-1-2016 21:40, Frank Steggink wrote:

Maarten,

Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet is 
toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. Het 
enige wat is toegestaan, is om ze te gebruiken voor het bijwerken van 
OSM. Je mag niet de key die je ontvangen zou moeten hebben (of gaat 
ontvangen) delen.


De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen 
dezelfde resolutie. In ieder geval is de kwaliteit van de 
Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via 
een satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 
5 à 6 oud.


Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de 
bespreking de meest recente dataset was. (De 2015 foto's werden nog 
verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, 
moet nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze 
foto's wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben 
zelf ook belang bij deze samenwerkeign.


@Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU?

Groeten,

Frank

On 10-1-2016 20:49, Maarten Deen wrote:

On 2016-01-10 20:38, Johan C wrote:

We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS
luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan
OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een
licentie aangaan met CycloMedia. Dat kun je hier doen:
http://www.cyclomedia.com/nl/openstreetmap/


Dat is goed nieuws.

Ik heb wel wat vraagjes:
Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde 
luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is.
Wat betekent precies de bewoording "I shall not integrate and/or 
visualize parts of the AerialNL50cm imagery in the OSM". Betekent dat 
soms dat ze ook niet getoond kunnen worden in JOSM?
Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen 
worden en hoe?


Maarten

___
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

Re: [OSM-talk-nl] Luchtfoto's 2014 CycloMedia

[Frank Steggink]

Maarten,

Zoals ik artikel 1.3.4 interpreteer van de ToU denk ik dat het niet is 
toegestaan om deze luchtfoto's tezamen met OSM te visualiseren. Het 
enige wat is toegestaan, is om ze te gebruiken voor het bijwerken van 
OSM. Je mag niet de key die je ontvangen zou moeten hebben (of gaat 
ontvangen) delen.


De meest gedetailleerde luchtfoto's van Bing hebbne in het algemeen 
dezelfde resolutie. In ieder geval is de kwaliteit van de 
Bing-luchtfoto's vaak niet denderend, omdat ze voor een deel ook via een 
satelliet genoemn zijn. Verder zijn de Bing-foto's al een jaar of 5 à 6 oud.


Er is hier gekozen voor de 2014-foto's, omdat dat ten tijde van de 
bespreking de meest recente dataset was. (De 2015 foto's werden nog 
verwerkt.) Of en wanneer de 2015-foto's beschikbaar worden gesteld, moet 
nog worden bekeken. Dat hangt ervan af hoe het gebruik van deze foto's 
wordt ervaren. Cyclomedia gebruikt OSM zelf ook, dus ze hebben zelf ook 
belang bij deze samenwerkeign.


@Johan/Gert-Jan: waarom is er gekozen voor een engelstalige ToU?

Groeten,

Frank

On 10-1-2016 20:49, Maarten Deen wrote:

On 2016-01-10 20:38, Johan C wrote:

We zijn erg verheugd om aan te kondigen dat CycloMedia via WMS
luchtfoto's 2014 in een resolutie van 50 cm. ter beschikking stelt aan
OpenStreetMap. Om toegang te krijgen tot de luchtfoto's moet je een
licentie aangaan met CycloMedia. Dat kun je hier doen:
http://www.cyclomedia.com/nl/openstreetmap/


Dat is goed nieuws.

Ik heb wel wat vraagjes:
Hoe verhoudt 50cm resolutie zich tot de meest gedetailleerde 
luchtfoto's van Bing? Ik heb geen idee wat daar de resolutie van is.
Wat betekent precies de bewoording "I shall not integrate and/or 
visualize parts of the AerialNL50cm imagery in the OSM". Betekent dat 
soms dat ze ook niet getoond kunnen worden in JOSM?
Als dat wel kan, kunnen de foto's dan als WMS layer in JOSM geladen 
worden en hoe?


Maarten

___
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

Re: [OSM-talk-nl] Nieuwjaarsborrel zo 10 jan 2016, Dudok Hilversum

[Frank Steggink]

Hoi,

DIt is de huidige stand van zaken m.b.t. de presentaties:
* Jan-Willem van Aalst: OpenTopo en BGT --> met name interessant voor de 
BGT-geïnteresseerden;
* Johan de Ruiter en Gert-Jan van der Weijden: laatste stand van zaken 
Nederlandse luchtfotos;

* Matthijs Melissen: laatste standv an zaken OpenStreetMap carto;
* Just van den Broecke: terugblik OSGeo.nl over 2015 en vooruitblik over 
2016.


Aanmelden kan nog steeds, bij voorkeur via de link die Just heeft 
gemeld. Je kunt je ook bij Just melden als je zelf nog een praatje wilt 
houden.


Groeten,

Frank

On 30-12-2015 11:09, Just van den Broecke wrote:

Beste Mensen,

Voor het vijfde achtereenvolgende jaar (lustrum) de traditionele 
OSGeo.nl+OSM-NL Nieuwjaarsborrel voor iedereen die open source 
geo-software en OpenStreetmap een warm hart toedraagt.


Ook dit jaar weer in bovenzaal Cafe Dudok, Hilversum (t/o station NS), 
op zondag 10 jan 2016, vanaf 15:00.


Er is ruimte voor "talks". Jan-Willem van Aalst zal bijv 
vertellen over de gloednieuwe BGT-visualisatie voor de geplande 
OpenTopo 3200pix/km.


Opgeven, ook voor "talks", via OSGeo.nl Meetup:
http://www.meetup.com/OSGeoNL/events/227097392

Hartelijke groet,

--Just

PS voor wie het gemist had, het verslag van NJ-Borrel 2015:
http://osgeo.nl/2015/01/nieuwjaarsborrel-2015-de-presentaties



___
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

Re: [OSM-talk] Belgium/Netherlands Boundary Change

[Frank Steggink]

On 5-1-2016 12:54, Steve Doerr wrote:
Just read this article about a territory-swap between The Netherlands 
and Belgium: http://actualite24.info/post/316916


I wonder if this has taken effect yet? It's not reflected in OSM 
currently. I think I'll leave it for the local communities to action.


For those interested, and especially for the Dutch and Belgian (Flemish) 
communities: here is an article in Dutch:

http://www.rtlnieuws.nl/nieuws/binnenland/een-stukje-belgie-straks-van-nederland-en-dat-zonder-bloedvergieten

Note that the swap is located on the (very small) boundary between the 
Netherlands and Wallonia, not Flandres, but the article posted by Steve 
is in French already.


It appears that the swap hasn't occurred yet, but is slated for later 
this year. The article doesn't mention a date however.


I've contacted "our" (Dutch) guy already, who is responsible for 
maintaining administrative boundaries in the Netherlands.


Regards,

Frank

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

Re: [OSM-talk] What3words

[steggink]

Citeren Colin Smale :


Correct, but the accuracy issue is a weakness in lat/lon based
coordinates as well. If you use your consumer GPS or phone to find your
lat/lon, you might indeed be a long way adrift and you might get
different values on different occasions. Imagine that you were relying
on that to get your shopping delivered...



It isn't the same issue. There isn't a weakness in the lat/lon system  
itself (unless you're not using enough digits), but the weakness is in  
consumer GPS devices as you say. When using w3w in combination with  
GPS, you have to convert it to lat/lon first, so you have to deal with  
both the 3x3m inaccuracy AND the inaccuracy of consumer GPS devices.


Frank


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

[OSM-talk-nl] Samenwerking OSM en Rijkswaterstaat: de follow-up

[Frank Steggink]

Hoi,

Zoals de meesten weten, was er op 19 september jl. een bijeenkomst bij 
Rijkswaterstaat in Utrecht met als doel om kennis te maken met de OSM 
community en om te kijken of wij (OSM en RWS) op een aantal vlakken 
nader kunnen samenwerken. Dit omdat er, ondanks de verschillen, ook 
gezamenlijke doelen zijn, nl. het beschikbaar stellen van open geodata. 
Naast Rijkswaterstaat waren er ook mensen van andere 
overheidsorganisaties aanwezig, zoals het Ministerie van Infrastructuur 
en Milieu en het Kadaster. Van deze bijeenkomst is een artikel 
beschikbaar: 
https://bgtweb.pleio.nl/blog/view/34894162/de-bgt-en-openstreetmap-samenwerkingskansen-in-beeld


Uit deze bijeenkomst zijn een aantal ideeën voortgekomen om de mogelijke 
samenwerking nader uit te werken. Bij ieder initiatief zijn twee 
contactpersonen, namelijk één vanuit de overheid en één vanuit de 
community. Natuurlijk is iedereen van harte uitgenodigd om hieraan bij 
te dragen. Hier volgt een overzicht met korte toelichting van de 
initiatieven, tezamen met de namen en contactgegevens van de 
contactpersonen. Als je een bijdrage wilt leveren, kun je het beste 
contact zoeken met de contactpersonen.


* OSM.NL voor dummies
  Contact OSM: Gert-Jan van der Weijden (gee...@dds.nl)
  Contact RWS: Ed Ooms (ed.o...@ndw.nu)
Hiervan heb ik geen beschrijving gekregen, maar ik denk dat de titel wel 
voor zichzelf spreekt.


* Echte kansen / meerwaarde van OSM voor RWS uitwerken
  Contact OSM: Henk Hoff (toffeh...@gmail.com)
  Contact RWS: Nelette Verbruggen (nelette.verbrug...@rws.nl)
Doel: In deze groep willen we één echte kans voor Rijkswaterstaat qua 
samenwerking met Open Street Map uitwerken: iets waarin duidelijk en 
relatief snel meerwaarde te zien is van gebruik van de OSM-data voor 
RWS. Het snel laten zien van een concreet resultaat zal namelijk het 
enthousiasme bij RWS voor samenwerking verder aanwakkeren.
Daarbij denken we nu aan de relatie tussen OSM en het nationaal 
wegenbestand (NWB), wat kan leiden tot efficiënter werken en een betere 
kwaliteit van beide bronnen.
Status: Met het groepje 'echte kans/meerwaarde van OSM voor RWS 
uitwerken' hebben we de afgelopen weken via de mail al contact gehad. We 
proberen binnenkort bij elkaar te komen. Dat loopt dus!


* Ontsluiting Basisregistratie Grootschalige Topografie (BGT) binnen OSM 
en v.v.

  Contact OSM: Frank Steggink (fr...@steggink.it)
  Contact RWS: Jaap-Willem Sjoukema (Min I) 
(jaapwillem.sjouk...@minienm.nl)
Doel: Het doel van het BGT-initiatief is om te onderzoeken wat de 
mogelijkheden zijn om de Basisregistratie Grootschalige Topografie (BGT) 
binnen OSM te gebruiken en om te verkennen op welke manieren OSM 
gebruikt kan worden voor verrijking van de BGT. Bij gebruik van de BGT 
binnen OSM moet er verder worden gedacht dan het klakkeloos importeren 
van de BGT. Er zijn waarschijnlijk betere manieren te vinden om 
informatie uit de BGT te gebruiken. Er moet o.a. aandacht worden besteed 
aan een mapping tussen de gebruikte codering van de BGT en het OSM 
tagging-schema. Dit onderwerp leent zich bij uitstek voor het vormen van 
subgroepen die de uitwisseling van een specifieke set features nader 
onderzoeken.
Status: Jaap-Willem en ik hebben beslotem om de discussie hierover op 
het OSM forum te bespreken: 
http://forum.openstreetmap.org/viewtopic.php?id=52338
Verder houdt Jaap-Willem Sjoukema zich bij het Ministerie van 
Infrastructuur en Milieu bezig met de ontwikkeling van een 
terugmeldsysteem voor de BGT, maar dat is niet specifiek op OSM gericht.


* Subonderdeel BGT: kunstwerken in OSM
  Contact OSM kunstwerken: Nick Hoogerbrug (st.nikl...@live.nl)
  Contact RWS kunstwerken: Rob van der Schoot (rob.vander.sch...@rws.nl)
Aangezien de BGT ook kunstwerken bevat, is besloten om dit als een 
subonderdeel van de BGT op te pakken. Eventueel worden andere bronnen, 
zoals het DTB van RWS, hiervoor gebruikt (eigen invulling).


* Nationale bewegwijzering en OSM
  Contact OSM: Marc Zoutendijk (ma...@xs4all.nl)
  Contact RWS: Eric van der Ster (eric.vander.s...@rws.nl)
Doel: in de nationale bewegwijzeringsapplicatie wordt noch OSM, noch RWS 
data gebruikt. Lijkt efficiënter en goedkoper te kunnen. Doel: open data 
als basis gebruiken in nationale bewegwijzeringsapplicatie. Waarom? Alle 
wegbeheerders gebruiken de applicatie, kijk naar de kracht van een 
eventuele terugmeldfunctie naar OSM en RWS!
Status: voorstel heb ik (Eric vd Ster) neergelegd bij de directeur van 
de Nationale Bewegwijzeringsdienst


* Luchtfoto's vrij beschikbaar krijgen
  Contact OSM: Gert-Jan van der Weijden (gee...@dds.nl)
  Contact RWS: Ed Vaessen (ed.vaes...@rws.nl)
Doel: de landsdekkende luchtfoto’s worden jaarlijks door gezamenlijke 
overheden (behalve de gemeenten) aangeschaft. Er is een variant met 10cm 
resolutie die is opgenomen in het bladloze seizoen (voorjaar, tot 23 
april) en een met 25cm resolutie, opgenomen van 15 april t/m 15 juli.
Alleen de laatste variant, gedownsampled naar 50cm, is als open

Re: [OSM-talk-nl] [Dutch] AmsGeoDrinks - Zeppos do 27 aug

[Frank Steggink]

Voor degenen die er niet bij waren: we hebben op een passende wijze 
uitgeleide gedaan van Steven!

Hier de bewijzen:
* http://www.meetup.com/AmsGeoDrinks/photos/26367142/441356154/?a=pu3.2_l
* http://www.meetup.com/AmsGeoDrinks/photos/26367142/441356179/?a=pu3.2_l

Voor wie de tekst op de tweede foto beter wil lezen:
http://lists.osgeo.org/pipermail/dutch/2007-October/00.html

Groeten,

Frank

On 25-8-2015 15:11, Just van den Broecke wrote:
Op 27/8 weer een Amsterdam Geo Drinks ter ere van vertrek ons 
voormalig OSGeo.nl bestuurslid Steven naar USA DC, opgeven op


http://www.meetup.com/AmsGeoDrinks/events/224785253

Hartelijke groet,

Just
___
Dutch mailing list
du...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/dutch




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

Re: [Talk-ca] Highway recoding

[Frank Steggink]

Hi Daniel,

Actually, the part between Quebec City and Beaupré of Route 138 should 
still be tagged as a trunk. Beaupré is not a large population centre, 
but the layout of the road is almost that of a motorway. Except that 
there are traffic lights instead of interchanges.


Regards,

Frank

On 25-7-2015 19:10, Daniel Begin wrote:


I think we are evolving to a consensus that makes sense.

I have received some examples that are quite right in QC context. For 
those who know the area, Route 175 up to Saguenay is obviously a “type 
1” trunk road while Route 138 northeast from Quebec City isn't.


However, I hope everyone concerned will give their “two cents” because 
the context in Manitoba or in Yukon may be (is) quite different, and I 
do not want an Eastern centric solution on the subject :-)


Best regards,

DanielI

*From:*Daniel Begin [mailto:jfd...@hotmail.com]
*Sent:* July-24-15 10:09
*To:* 'Adam Martin'; 'Tristan Anderson'
*Cc:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Highway recoding

“… [TCH] is automatically a trunk route given that it is, at its most 
basic point, the central connection between major settlements …”


Interesting… it is type 2 definition proposed by Tristan but without 
the concept of distance. IMHO, It highlights the fact that, depending 
on how you define central connection, major settlements, or distant 
population centres, you may ends up with the Britain situation – or 
even worst.


Combining two very different objectives (types 1 and 2) in one 
definition leads to confusion. What about a rationale revolving around 
Type 1 definition but considering the TCH as a “special case” as 
suggested by Martin?


-OSM road classes mostly aim toward Type 1 definition, so be it for 
trunks;


-Since TCH could be consider as the only highway connecting most major 
population centres across the country, we could agree to tag it 
whether motorway or trunk depending on the infrastructure. There 
should then be no more confusion with this only one exception.


However, we could also manage all type 2 definitions, such as the ones 
described in document (a) with relation:route (b) but it is a bit more 
complex and less visual when looking at Mapnik.


Other thoughts, comments?

Daniel

a) http://www.comt.ca/english/NHS-report-english.pdf

b) http://wiki.openstreetmap.org/wiki/Relation:route#Road_routes

*From:*Adam Martin [mailto:s.adam.mar...@gmail.com]
*Sent:* July-24-15 07:08
*To:* Tristan Anderson
*Cc:* Daniel Begin; Stewart C. Russell; talk-ca@openstreetmap.org 
mailto:talk-ca@openstreetmap.org

*Subject:* Re: [Talk-ca] Highway recoding

Reviewing the types that you suggest here, the result seems 
reasonable. Major Canadian Highways are generally a blend of the two, 
I find. Type 1 trunks rely on restricted access and the main highways 
in cities are generally limited in this manner. Likewise, these 
restrictions lift, in a sense, outside the city where they switch to 
connecting major settlements together (Type 2).


That said, I think that most would agree that the TransCanada Highway 
is automatically a trunk route given that it is, at it's most basic 
point, the central connection between major settlements, especially 
across provincial borders. I assume that the routes that leave the TCH 
to go to other major settlements would need to be at the same class as 
the TCH, if they are multi-lane highways used to connect settlements. 
Or are we to designate them down a classification and leave Trunk for 
the TCH alone?


On Thu, Jul 23, 2015 at 6:48 PM, Tristan Anderson 
andersontris...@hotmail.com mailto:andersontris...@hotmail.com wrote:


So it seems like we're coming to some agreement.  The current Canadian 
definition based on that 2005 document should be replaced with 
something else that is consistent with the rest of the world.  Once we 
find this new definition, the appropriate wiki pages should be updated.


I took a look around the world and finally saw some consistency in how 
trunk tags are used.  Stewart's guidelines are basically correct, but 
I think I can hammer out a more specific description.  There are two 
types of roads with are both usually tagged highway=trunk:



(1) Limited access highways.  This is a physical description for a 
road that has some of the characteristics of a motorway.  They are 
often dual carriageways of fairly high speed.


(2) Highways connecting distant population centres.  This is a 
functional description for a road where used by cars and heavy trucks 
travelling long distances or between major cities.  Although usually 
two lanes, in more remote areas these roads may have very light 
traffic, be unpaved, or be slow.


In some parts of the world, like Germany, France and the eastern 
United States, all trunk roads are type (1) because long-distance 
travel is generally done on their dense networks of motorways.


Conversely, in large swathes of Australia and Canada, as well as in 
much of the developing world, all trunk roads 

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

[Frank Steggink]

Beste Eric,

Met je goedvinden stuur ik je oproep tevens door naar de OSGeo.nl 
mailinglijst. Daar zitten ook veel mensen die OSM kennen en een goede 
inbreng kunnen leveren, maar die misschien niet OSM talk-nl in de gaten 
houden.


Verder zou ik speciale aandacht willen vragen voor mensen die betrokken 
zijn bij of bijdragen aan OpenSeaMap. Weet iemand of hier ook 
Nederlanders bij betrokken zijn? Dit i.v.m. de schat aan gegevens die 
Rijkswaterstaat heeft over water.


Groeten,

Frank Steggink


On 9-6-2015 11:36, Ster, Eric van der (CIV) wrote:


Beste OSM-ers

Om te beginnen zal ik mij even voorstellen: Eric van der Ster. Ik werk 
bij de Centrale Informatievoorziening van Rijkswaterstaat.


Op de bijeenkomst op het Geofort is het idee ontstaan om een sessie te 
organiseren om de mogelijkheden van samenwerking tussen OSM en RWS te 
verkennen.


Rijkswaterstaat is beheerder van het hoofdwegennet, hoofdvaarwegennet 
en hoofdwatersysteem, de bijbehorende data en een aantal nationale 
basisbestanden. Al langere tijd stelt Rijkswaterstaat data open voor 
hergebruik. Per 1-1-2015 is daar een grote impuls aangegeven door een 
groot deel van de Rijkswaterstaat data open te stellen voor 
hergebruik. Dat hergebruik is voor RWS belangrijk: het helpt RWS de 
kwaliteit van de data te verbeteren én het hergebruik versterkt de 
beleidsdoelstellingen op het gebied van leefomgeving/milieu, 
bereikbaarheid en veiligheid.


De brainstormsessie is op 19 september 2015 van 11:00-17:00. Locatie 
is nog niet definitief (vermoedelijk Utrecht). Op basis van wat heen 
-en weer mailen is het volgende programma ontstaan:


1.thema Community  Organisatie

Doel: Hoe kunnen RWS en OSM Nederland gezamenlijk een omvangrijke en 
actieve community creëren, waar zowel Rijkswaterstaat als OSM van 
profiteren om relevante onderliggende databases zo betrouwbaar 
mogelijk te houden tegen minimale kosten?


2.thema Open data, hergebruik en feedback”

Doel:  Op welke manier creëren we een eco-systeem van data, waarbij 
zowel OSM als Rijkswaterstaat profiteren van de kwaliteit en 
actualiteit van de data van elkaar?


3.thema “Dataproeverij”

Doel: Aan de slag met de data in de praktijk. Aan de hand van concrete 
vraagstukken gezamenlijk werken aan oplossingen.


Suggesties en aanmeldingen zijn uiteraard welkom. (bij 
eric.vander.s...@rws.nl met naam en bij voorkeur met interessegebied ).


Met vriendelijke groet,

Eric van der Ster
Coordinerend/Specialistisch Adviseur
. 


Strategie en Beleid

Rijkswaterstaat Centrale Informatievoorziening
Derde Werelddreef 1 | 2622 HA Delft
Postbus 5023 | 2600 GA Delft
. 


T: +31-15-275 7345
M: +31-6-51435420



___
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

Re: [OSM-talk-nl] irc like chatroom

[Frank Steggink]

Dag Jo,

Op http://irc.openstreetmap.org/ is er een channel #osm-nl. Ik heb geen 
idee of daar nog wel eens mensen opzitten. Vroeger kwam ik er wel eens, 
maar de laatste jaren ben ik er niet meer geweest.


Groeten,

Frank

On 13-1-2015 20:48, Jo wrote:

Hallo,

Wat ik een beetje mis, is zoiets als irc, waar je kon binnenvallen 
wanneer het je uitkomt.


Hier is een experimentje dat dat hiaat wellicht kan opvullen:

https://meet.jit.si/osmbe

't Werkt wel enkel in Chrome/Chromium.

Groeten,

Jo


___
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

Re: [OSM-talk-nl] [Dutch] OSM borrel + AAN-data

[Frank Steggink]

Hoi Paul,

Wat de perceelsgrenzen betreft: deze zitten in OSM, voor zover ze in 
3dShapes aanwezig waren en niet door mensen zijn samengevoegd.
Voor akkerland heeft OSM enige tijd een wijziging in de stylesheet 
doorgevoerd om de grenzen te accentueren, maar voor grasland is dit niet 
gedaan. Dit zie je ook in je screenshot.


V.w.b. de actualiteit zou het zinvol zijn om de data aan OSM toe te 
voegen, mits de data goed te mappen is naar de OSM tags. Maar wat 
betreft de hoeveelheid werk zou ik het sterk afraden. Voor specifieke 
toepassingen kun je veel beter de AAN-data rechtstreeks gebruiken, zoals 
Jan-Willem aangeeft. Een andere factor wat het updaten lastig maakt is 
dat de landgebruik-vlakken allemaal aan elkaar vastzitten, waardoor het 
updaten veel meer inspanning kost dan het toevoegen of verwijderen van 
losse gebouwen.


De enige use case waar ik AAN-data wel geschikt voor zou vinden is in 
gebieden waar OSM sterk outdated is, bijv. in de buurt van 
stadsuitbreidingen en/of nieuwe (rijks)wegen. Landgebruik is lastig te 
editen en de Bing luchtfoto's zijn vaak niet actueel, waardoor de 
landuse niet op een fatsoenlijke manier bijgewerkt kan worden. Maar 
zelfs dan zit je nog met zaken zoals bermen, omdat die geen agrarische 
bestemming hebben. Het is hoe dan ook uitkijken.


Groeten,

Frank Steggink

p.s. Cross-post naar OSM talk-nl, waar deze discussie eigenlijk thuis hoort.

On 5-1-2015 15:11, Paul Meems wrote:

Goedemiddag,

Ik kan jammer genoeg niet bij de komende OpenStreetMap NL 
nieuwsjaarborrel anwezig zijn.


Maar ik heb wel een vraag/opmerking over OSM.

We gebruiken OSM data in onze webapplicatie en daar over heen leggen 
we AAN-data (Agrarisch Areaal Nederland). Deze AAN-data is vrij 
verkrijgbaar bij PDOK en wordt elk jaar opnieuw aangeleverd nadat de 
boeren hun wijzigingen hebben doorgegeven (in april).


Is het zinvol/handig/leuk/nuttig om die data toe te voegen aan de OSM 
data? Je hebt dan de perceelsgrenzen en wat er op verbouwd wordt. Het 
gaat misschien te ver om elk gewas dan een eigen kleur te geven, maar 
je kunt wel een onderscheid maken tussen akkerbouw en grasland.


Visueel wordt het in ieder geval 'mooier'.
ik heb twee plaatjes toegevoegd. Eentje van OSM alleen en eentje met 
de AAN-data als extra laag (in magenta). Zonder AAN heb je grote 
groene vlakken. Met AAN kun je de perceelsgrenzen zien.


Inline afbeelding 1
Inline afbeelding 3

Ik ben benieuwd wat de OSM-editors hiervan vinden. Ik ben zelf enkel 
een gebruiker ;)



Met vriendelijke groet,



Paul Meems

*Paul Meems
*Senior GIS consultant

06-53989481
TopX Geo-ICT http://www.topx-geo-ict.nl

http://topx-group.nl/topx-geo-ictWij bieden ondersteuning

voor MapWindow GIS http://www.mapwindow.org/


De Engelse presentaties van de MapWindow Open Source GIS 2014 
conferentie in Debrecen, Hongarije. 
http://www.slideshare.net/MapWindow/presentations





___
Dutch mailing list
du...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/dutch



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

Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?

[steggink]

Quoting Marc Zoutendijk marczoutend...@mac.com:


Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP van  
dit topic.

Ik ondersteun hem wel.


Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik  
kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed  
voorstellen ;)


Gelukkig is het niet aan hem alleen om een keus te moeten maken tussen  
forum en mailinglijst. Gezien de reacties denk ik dat we deze keus ook  
helemaal niet moeten maken, omdat de een bij het forum zweert en de  
ander bij de mailinglist.


Aangezien er techonologie bestaat om beide te koppelen, moeten we dit  
vooral gaan inzetten om beide werelden (want dat zijn het wel) te  
combineren! Dat is ook de achterliggende vraag van Gert-Jan, waarin ik  
hem juist wel ondersteun.


Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar  
volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen  
zonder account op het forum schijnt automatisch een of ander  
dummy-account aangemaakt te worden.


Groeten,

Frank Steggink




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

Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?

[steggink]

Ik kreeg wel een bericht binnen dat Marc heeft geantwoord in het topic:

marczoutendijk has replied to the topic 'Test' to which you are  
subscribed. There may be more new replies, but this is the only  
notification you will receive until you visit the board again.


The post is located at  
http://forum.openstreetmap.org/viewtopic.php?pid=467158#p467158


The message reads as follows:
---

Ik heb het in ieder geval gelezen!
Welkom!

---

You can unsubscribe by going to  
http://forum.openstreetmap.org/misc.php?action=unsubscribetid=28262


--
OpenStreetMap Forum Mailer
(Do not reply to this message)


Ik kan het bericht lezen, maar ben niet gelukkig met het formaat. De  
forum mailer heeft blijkbaar veel tekst nodig om het antwoord te  
versturen. Ook kan ik niet hierop antwoorden. Ook zie ik niet  
eventuele latere berichten, volgens de tekst There may be more new  
replies, but this is the only notification you will receive until you  
visit the board again.


Conclusie: dit werkt niet.

Op RSS feeds kun je ook niet antwoorden.

Groeten,

Frank Steggink


Quoting stegg...@steggink.org:


Quoting Marc Zoutendijk marczoutend...@mac.com:


Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP  
van dit topic.

Ik ondersteun hem wel.


Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik  
kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed  
voorstellen ;)


Gelukkig is het niet aan hem alleen om een keus te moeten maken  
tussen forum en mailinglijst. Gezien de reacties denk ik dat we deze  
keus ook helemaal niet moeten maken, omdat de een bij het forum  
zweert en de ander bij de mailinglist.


Aangezien er techonologie bestaat om beide te koppelen, moeten we  
dit vooral gaan inzetten om beide werelden (want dat zijn het wel)  
te combineren! Dat is ook de achterliggende vraag van Gert-Jan,  
waarin ik hem juist wel ondersteun.


Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar  
volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen  
zonder account op het forum schijnt automatisch een of ander  
dummy-account aangemaakt te worden.


Groeten,

Frank Steggink




___
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

Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?

[steggink]

Nog een update: aangezien ik ook op het forum ben gesubscribed, zou ik  
verwachten dat ik ook bericht zou krijgen van antwoorden op andere  
topics. Deze heb ik niet gehad, terwijl er wel nieuwe antwoorden zijn  
(bijv. op Huisnummers voor de konijntjes).


Groeten,

Frank Steggink


Quoting stegg...@steggink.org:


Ik kreeg wel een bericht binnen dat Marc heeft geantwoord in het topic:

marczoutendijk has replied to the topic 'Test' to which you are  
subscribed. There may be more new replies, but this is the only  
notification you will receive until you visit the board again.


The post is located at  
http://forum.openstreetmap.org/viewtopic.php?pid=467158#p467158


The message reads as follows:
---

Ik heb het in ieder geval gelezen!
Welkom!

---

You can unsubscribe by going to  
http://forum.openstreetmap.org/misc.php?action=unsubscribetid=28262


--
OpenStreetMap Forum Mailer
(Do not reply to this message)


Ik kan het bericht lezen, maar ben niet gelukkig met het formaat. De  
forum mailer heeft blijkbaar veel tekst nodig om het antwoord te  
versturen. Ook kan ik niet hierop antwoorden. Ook zie ik niet  
eventuele latere berichten, volgens de tekst There may be more new  
replies, but this is the only notification you will receive until  
you visit the board again.


Conclusie: dit werkt niet.

Op RSS feeds kun je ook niet antwoorden.

Groeten,

Frank Steggink


Quoting stegg...@steggink.org:


Quoting Marc Zoutendijk marczoutend...@mac.com:


Tevens wijs ik erop dat niet ik pleit voor opheffing, maar de OP  
van dit topic.

Ik ondersteun hem wel.


Gert-Jan kennende is dit zijn stijl om een discussie te starten. Ik  
kan me de twinkeling in zijn ogen toen hij zijn mail schreef goed  
voorstellen ;)


Gelukkig is het niet aan hem alleen om een keus te moeten maken  
tussen forum en mailinglijst. Gezien de reacties denk ik dat we  
deze keus ook helemaal niet moeten maken, omdat de een bij het  
forum zweert en de ander bij de mailinglist.


Aangezien er techonologie bestaat om beide te koppelen, moeten we  
dit vooral gaan inzetten om beide werelden (want dat zijn het wel)  
te combineren! Dat is ook de achterliggende vraag van Gert-Jan,  
waarin ik hem juist wel ondersteun.


Ik heb de discussie rond het OSMF-forum niet helemaal gevolgd, maar  
volgens mij was er iemand die dit al heeft voorgesteld. Voor mensen  
zonder account op het forum schijnt automatisch een of ander  
dummy-account aangemaakt te worden.


Groeten,

Frank Steggink




___
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

Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?

[steggink]

Quoting Maarten Deen md...@xs4all.nl:


On 2014-11-28 12:02, Paul Smits wrote:

Ik zie het vrij simpel: het forum is voor de discussie met actieve
mappers, de mailinglijst voor vragen van mensen met forumvrees en om
alle mappers te bereiken voor belangrijke zaken. Zoals belangrijke
aankondigingen die voor alle mappers van belang zijn, over imports
bijvoorbeeld, of uitnodigingen voor mapping parties. Of wanneer er
iets goed stuk is, en het niet helemaal duidelijk is wie er schuld aan
heeft ;)


Dat vind ik een stigmatisering waarmee je jezelf eigenlijk al  
buitenspel zet. Ik ben ook een actieve mapper. Ik heb geen  
forumvrees, ik volg genoeg forums.
Ik heb verder nog geen steekhoudende verklaring gezien waarom er een  
forum gemaakt moest worden als er al een functionerende mailinglijst  
bestaat.


Omdat sommige mensen fora gemakkelijker vinden. Ieder zijn ding.
Het forum bestond zeker al in 2007. Ik vind het wel bijzonder dat je  
hier pas 7, bijna 8 jaar later achter komt :)


Het verwondert me alleen zeer dat er blijkbaar twee communities  
kunnen ontstaan: de forumcommunity en de mailinglijstcommunity die  
blijkbaar gescheiden zijn en waar mensen weinig van elkaar afweten.  
Iig geldt dat voor mij. Blijkbaar heb ik nu mijn 3e post op het  
forum gemaakt terwijl ik gisteren nog totaal vergeten was dat het  
forum überhaupt bestond.


Het verwondert mij niet. Blijkbaar is er niet zo veel overlap tussen  
het forum en de mailinglist v.w.b. de actieve leden. De mailinglijst  
is sowieso niet heel erg actief de laatste jaren. Blijkbaar wordt hij  
wel door aardig wat mensen gelezen, wat ik een goede zaak vind. Tevens  
is dit bewijs dat de mailinglist zeker NIET achterhaald is.


Ik vind het wel jammer dat er twee communities zijn. Zo groot is  
Nederland ook niet, dus het zou beter zijn als we beide communities  
kunnen verenigen. Zeker als er technische mogelijkheden zijn.  
Natuurlijk moet het ene medium niet ten koste gaan van het andere  
medium!


Gert-Jan, aangezien jij de knuppel in het hoenderhok hebt gegooid, is  
het tijd om hem er nu maar weer uit te halen?


Frank



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

Re: [OSM-talk-nl] Forum en mailinglijst: 2 kapiteins op hetzelfde schip?

[steggink]

Geachte heer Zoutendijk,

Die koppeling is wel nodig om nieuwe items te posten vanuit je e-mail  
client en om de discussies in het talk-nl archief te krijgen.


Verder vind ik de manier waarop u degenen die de mailinglist  
prefereren bejegent niet prettig. Binnen een community als OSM vind ik  
het zelfs behoorlijk ongepast. Juist de kracht van OSM is dat er een  
behoorlijke mate van vrijheid is. De manier waarop u pleit om de  
mailinglist te sluiten, vind ik een inbreuk van mijn vrijheid,  
namelijk de vrijheid om het door mij gewenste medium te gebruiken.


Hoogachtend,

Frank Steggink

Quoting Marc Zoutendijk marczoutend...@mac.com:

Op 28 nov. 2014, om 07:59 heeft stegg...@steggink.org het volgende  
geschreven:


Als een koppeling tussen de mailinglijst en forum mogelijk is, dan  
denk ik dat dit de beste optie is. Iedereen kan dan het medium  
gebruiken dat hij/zij het prettigst vindt.




Die koppeling is niet nodig.

Persoonlijk ben ik voorstander van de mailinglijst. Reden: gemak.  
Ik hoef alleen maar mijn mail te openen om te zien dat er nieuwe  
discussies zijn. Ze komen in een aparte mailfolder terecht. Bij het  
forum moet ik er uberhaupt eerst aan denken om het te bezoeken en  
als ik ergens op wil reageren moet ik ook nog eens inloggen.


Want je kunt je op het forum abonneren zodat de berichten ook je  
mailbox bereiken.

Je mist helemaal niets.

Bovendien is mijn ervaring dat het forum aanmerkelijk beter bezocht  
is en meer onderwerpen en deelnemers kent dan de mailinglist.


Dus als je het rustig wilt houden dan blijf je op de list.

Maar ik zou zeggen: ga eens kijken op het forum en zie hoe het  
werkt. Het feit dat de meeste reacties hier aangeven dat ze bang  
zijn iets te missen geeft al aan dat ze de werkwijze van het forum  
niet kennen.


Marc.





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

[OSM-talk-nl] Fwd: [Dutch] 13 dec. Missing Maps Mapathon in Antwerpen

[Frank Steggink]

Hoi,

Deze aankondiging hoort natuurlijk ook op OSM talk-nl thuis.
Verder schijnt er op 5 dec. tevens een mapathon in Middelburg te zijn. 
Willy, heb jij hier details over? Ik heb deze aankondiging nog nergens 
langs zien komen.


Vandaag is op de Geobuzz ook een mapathon in het midden van het land 
aangekondigd. Deze zal plaatsvinden op za. 14 feb. op het Geofort bij 
Leerdam. Details volgen later.


Groeten,

Frank Steggink


 Original Message 
Subject:[Dutch] 13 dec. Missing Maps Mapathon in Antwerpen
Date:   Mon, 24 Nov 2014 20:19:25 +0100
From:   Willy Bakker friesewoudlo...@gmail.com
To: du...@lists.osgeo.org du...@lists.osgeo.org



Beste leden van de mailinglijst,

13 december organiseert de Belgische OpenStreetMap community een Missing 
Maps Mapathon. Het Missing Maps project is een samenwerkingsverband 
tussen Artsen Zonder Grenzen, het Amerikaanse en Britse Rode Kruis en 
het Humanitarian OpenStreetMap Team (HOT). Kijk voor meer informatie 
over Missing Maps bijvoorbeeld hier http://www.missingmaps.org of hier 
http://www.radio1.be/programmas/vandaag/%E2%80%9Cmissing-maps%E2%80%9D-brengt-de-wereld-kaart.
Het zou heel leuk zijn wanneer we met een groepje Nederlandse (aspirant) 
mappers afreizen naar Antwerpen. Niet alleen leerzaam en nuttig, maar 
ook gezellig! (We gaan dan 's avonds natuurlijk ook even het 
uitgaansleven in de stad in kaart brengen...) Wellicht doen we dan ook 
inspiratie op om een Missing Maps Mapathon in NL te organiseren.
Hoe dan ook, wil je op 13 dec. meedoen met de mapathon, laat het me 
weten en geef je op via http://osm.be/nl/content/missing-maps-mapthon.


Vriendelijke groet,

Willy Bakker
friesewoudloper

N.B.: Ook al heb je nog nooit iets ingetekend in OpenStreetMap, je bent 
van harte welkom. Voor beginners is er een introductie, waarna ook zij 
aan de slag kunnen.




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

Re: [Talk-ca] Discussion: zones boisées

[Frank Steggink]

Hi Dega,

Sorry, you can't just get away with not creating holes for lakes, 
clearings, etc. What if you get an extract of OSM, and you're only 
interested in the forests, because you want to calculate the percentage 
of forest coverage. You don't get information about lakes, heath and 
other land uses when you don't cut out holes from multipolygons.


A better idea might be cutting the forest polygons along the roads. That 
way they become much more manageable, so forests crossing tile 
boundaries can be merged as well.


For the north this might not work well, because of a lack of roads. Also 
rivers could be used as forest delimiters, but although there are a lot 
of rivers, very large chunks of forests will likely remain.


However, there remains another problem, which is also shown near Lac 
Laporte, namely inconsistent landuse along sheet boundaries. That can't 
be easily fixed, especially not when there is no detailed imagery.


The problem of the lakes which are not merged should be fixed. I know, 
I've imported quite a lot of Canvec data myself, and I haven't always 
followed the best practices myself, but it's pretty an arduous task. 
However, it is doable. Recently I've imported a few sheets, and I took 
attention of merging lakes and avoiding duplicate rings. (As a 
GIS-professional, I still don't see a problem with the latter, but it's 
OSM practice to get rid of them.)


Regards,

Frank

On 19-11-2014 17:06, Ga Delap wrote:

Plusieurs (et j'en suis) ont exprimé leur désir d'avoir une meilleure
couverture de forêt sur la carte OSM. Ces zones de forêt sont venues avec les
importations CanVec mais ne progressent plus depuis un certain temps. Le
présent article propose une façon de réaliser la forêt sans utiliser les abus
de la méthode CanVec.

Voyons un exemple. Dirigez votre éditeur préféré vers -74.375/46.1875 ou
visionnez:
 http://www.openstreetmap.org/#map=16/46.1875/-74.3750
Vous y verrez deux tuiles de forêt. Chacune a été crée avec un rectangle de
type natural:wood. Un simple rectangle de 4 points qu'on peut créer
facilement. Cette tuile peut être vue simplement avec:
 http://openstreetmap.org/way/307466266


Voyons un autre exemple un peu plus à l'ouest (-74.500/46.1875). Dans votre
éditeur, sélectionner la ligne qui délimite la tuile sud-ouest. On peut
constater qu'elle est beaucoup plus complexe. On peut voir l'ensemble de cette
ligne avec:
 http://openstreetmap.org/way/307466267
Elle est composée d'environ 1600 points. Elle est complexe parce qu'elle
utilise l'approche everything but the kitchen sink. La tuile définit non
seulement la forêt mais aussi les lacs, les rivières et les clairières. Pire
encore, ce chemin de 1600 points fait partie d'une relation qui contient
plusieurs dizaines de tels chemins.
Affichez http://www.openstreetmap.org/relation/2368823 et remarquez le temps de
chargement de la page.

Revenons au premier exemple:
 http://www.openstreetmap.org/#map=14/46.1875/-74.3750
La forêt est un simple rectangle mais les lacs, les rivières et les chemins se
superposent à la forêt. Il n'est donc pas nécessaire que le contour de forêt
suive le contour des lacs et des rivières. Il y a un gain énorme en
simplicité.

Voyons un autre problème des tuiles CanVec:
 http://www.openstreetmap.org/#map=17/46.25047/-73.24885
Pour comprendre pourquoi il y a 3 Lac Laporte il faut utiliser l'éditeur:
 http://www.openstreetmap.org/edit?editor=id#map=17/46.25047/-73.24885
Les tuiles CanVec ont divisé le lac en 3 parties et ont créé 3 entités
natual:water, chacune avec le nom Lac Laporte. Pas fort!
Sur la même image, remarquez que le chemin Montée Ouest est fait de 2
segments de couleur différente. C'est parce que ce chemin a été défini de 2
façons différentes et, par conséquent, on ne peut pas fusionner les 2 segments
ensemble. L'un des segments vient de CanVec6 et l'autre de CanVec7. Belle
rigueur!
C'est un non-sens qu'une entité soit séparée en plusieurs parties parce
qu'elle est à cheval sur une tuile.

Le but de mon intervention est d'affirmer qu'il ne faut plus importer de tuile
CanVec dans sa forme actuelle. Elles rend la carte lourde et difficile à éditer
par des humains.
Peut-on remplacer les tuiles de forêt par de simples rectangles? Oui et non.
Les tuiles CanVec sont des multi-polygones et celà permet des trous. Ces trous
sont utilisés (entre autres) pour représenter des clairières. Donc, au lieu
d'un rectangle, on pourrait utiliser un multi-polygone avec des trous. Mais
est-ce bien  la bonne façon?
Un trou (tel qu'uitlisé par CanVec) définit une zone undefined qui apparaît en
blanc sur la carte. Ne serait-il pas mieux de créer une entité heath (ou
autre) pour représenter cette clairière? Une clairière n'est pas un trou dans
une forêt, tout comme une île n'est pas un trou dans un lac.

J'aimerais qu'il y ait une discussion sur les points suivants:
1) est-ce que les tuiles CanVec sont la meilleure façon de représenter la
forêt?
2) si 

Re: [OSM-talk-nl] Oxilion en Stichting OpenGeo gaan openstreetmap.nl upgraden

[Frank Steggink]

On 7-10-2014 0:56, Stefan de Konink wrote:

On Monday, October 6, 2014 5:47:03 PM CEST, Stefan de Konink wrote:
  - De data mirror wordt geplaatst op een server met tenminste 2x 1TB 
aan

SATA in RAID-1, een niet rundante 500GB SSD en 3x 73GB SAS schijven.
Het systeem heeft zelf 128GB aan RAM.


Korte update: een gulle gever heeft zich gemeld. Het wordt nu 5x 2TB. 
In RAID-6 levert dat 6TB aan slow storage op, genoeg om even vooruit 
te kunnen. Voor het betere BAG database werk is er nog een SSD.


Stefan

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


Goed werk Stefan! En een bedankje richting Oxilion is ook zeker op zijn 
plaats!


Groeten,

Frank Steggink

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

Re: [OSM-talk-nl] Netherland mapping for Tourists / Adress nodes move to building etc

[Frank Steggink]

Hi Florian,

The quality issues you mentioned about the imported data is due to the 
rules by which the government has collected this data.


For example: the tiny forests from the 3dShapes import (not the AND 
import) also appear on the topographical maps. I've examined way 
74390172 as an example. Have a look at this map sheet: 
http://geodata.nationaalgeoregister.nl/top25raster/extract/kaartbladen/TOP25raster_67A.zip?formaat=geotiff
There is probably a rule at the Kadaster (the Cadastre, also our 
national mapping agency) saying that a patch like this should be 
interpreted as a forest, even though there are only 5 or 6 trees visible 
on the Bing imagery.


Also the building you described as having been drawn by a 5 year old 
child: unfortunately buildings which have not been finished have not had 
the proper measurements taken by the local government. They will update 
the building after a while the building has been completed. This might 
take several months. It really depends on the processes within the 
municipality. That also explains why you might see quality differences 
between municipalities.


Landuse = farm is not necessarily wrong. There is an entire wiki page 
devoted to this tag: 
http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dfarm. This import 
(3dShapes) was done several years ago, and it is possible that tagging 
best practices now describe that croplands should be tagged as landuse = 
farmland.


Regarding the highway = unclassified tag from the AND import: this was 
before my time, but I believe it was caused by a lack of granularity of 
the highway types in the original data. Regarding the tags: in my 
opinion they can all be deleted. We're not going to receive any updates 
from them anyways.


Regards,

Frank


On 5-10-2014 21:45, Florian Lohoff wrote:

Hi Johan,

On Sun, Oct 05, 2014 at 04:49:15PM +0200, Johan C wrote:

Hi Florian

I invite you to make comments on the OpenStreetMap forum (
http://forum.openstreetmap.org/viewforum.php?id=12) because there's more
Dutch mappers active there. Awaiting your input there, I'll already do a
short reply to you,

Hmm i am not the kind of Forum user. I like my email program which helps me
to get the threads together ;)
  

or a couple of years i have been to Zeeland in Autumn and as always i have
a little time
to spend on mapping.

Great, especially on POI's there's a lot of work left

Not only pois. Most of the map around here hasnt been touched since the 
original AND
import. Still a lot of broken highway=pedestrian etc.  What i found:

- A lot and i really a LOT of landuse topology errors. Layered over each other
   without any method i can find. Mixing of landuse and highway nodes e.g..
   Sometimes single trees as a landuse=forest in the middle of the city.
- Use of landuse=farm where landuse=farmland would be right.
- highway=pedestrian for highway=service or path/foot/bicycle type roads.
- highway=unclassified everywhere - no residential in the citys.
- Strange highway name changes - Sometimes not at the crossing but 10m after 
which
   can not be found on ground.
- A lot of very strange oneways for which some i verified to be non existant.


Are you planning to move the addresses on the appropriate building
outlines?

No. Since the address nodes are in the proximity of the entrance that would
substantially lower the quality

Okay - so i dont move nodes except where it makes sense to an entrance on the
building outline.


There's no special local preference, so the standard OSM practice applies.
In the case of one building/one POI I add all information (including
address info) to the building outline ánd I prefer to put the entrance node
on the building outline. In the case of one building/multiple POI's I put
all POI info in a node.

I am just asking before breaking stuff the NL community has agreed to handle
differently.


What about strange buildings from the BAG import? I have a couple cases
where
the building outline does not at all match the building in a mapbox sat
imagery.

The BAG should contain the correct building outline, since this is
Cadastral information, nowadays updated very often. But as any database,
the BAG might incidentally have errors. Satellite imagery though is at risk
of being well outdated. So in these cases it's possibly best to have groun
truth info to determine the correct building outline.

I have found buildings which have a start_date of 2014 and are not orthogonal
and dont match the sat imagery. Yes - i'll have a look whether its a new 
construction
but the data looks like a 5 year old drew something in EPSG:4326

Example:
http://osm.org/go/0EmBaMKXz--?m=


I also found a BAG imported underground parking which is rendered very
prominent
on the map. From looking at the data i have the feeling that a layer=-1
should
at least be added but.

I agree., all underground buildings should have had layer -x

And in case of parking i am not shure its a wise decision to actually import it.

Example:
   

[OSM-talk] SOTM-EU 2014 visitors by car from outside of Germany: environment stickers

[steggink]

Hi,

For those who are coming by car to SOTM-EU 2014 in Karlsruhe, and  
especially for those who do not come from Germany, please be aware  
that in many cities you need an environmental sticker. See [1] for  
more information, and see [2] for a basic map. It also includes the  
conference area.


Nowadays, you need a green sticker for Karlsruhe, so if you currently  
have a yellow or even a red one, you're out of luck.


My experience is that at a TüV-office it is no problem to get a  
sticker for a foreign car. It took only 15 to 30 minutes or so. If you  
apply for a sticker in your own country, it might take a little  
longer, so your best bet is to look for a TüV-office in Germany.


Regards,

Frank


[1]  
http://www.german-way.com/travel-and-tourism/driving-in-europe/driving/driving-in-germany-green-zones/

[2] http://www.umwelt-plakette.de/umweltzone%20karlsruhe.php




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

[OSM-talk-nl] Vervoer SOTM-EU aanbod

[Frank Steggink]

Hoi,

Over twee weken ga ik naar SOTM-EU in Karlsruhe. Ik ben van plan om met 
de auto te gaan en ik kan dus een aantal mensen meenemen (2, hooguit 3, 
maar dat wordt krap). Ik ga op do. 12 juni rond 09:00 uur weg uit 
Utrecht en ik kom ma. 16 juni weer terug.


Ik ben in ieder geval van plan om bij Venlo de grens over te gaan en dan 
de A-61 te nemen. Afhankelijk van wie zich het eerst meldt, ga ik of 
over Den Bosch/Eindhoven of over Arnhem/Nijmegen.


Stuur me een mail, zodat we kunnen afspreken waar/hoe laat ik je op kan 
halen.


Groeten,

Frank

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

Re: [Talk-ca] coastline between Montreal and Sorel, Quebec

[steggink]

Another option is to tag water as coastline at places where there is  
significant tide. This will include the estuary up until approximately  
Quebec City.


Regarding tagging the Great Lakes as coastline: why would there be an  
exception for them, where as other large lakes (Great Slave Lake,  
Victoria Lake in Africa, Lake Baikal in Russia, etc.) are not? IMO  
this can be considered as tagging for the renderer.


A better approach would be to prepare a lowres, generalized dataset  
for rendering at low zoomlevels, which only include coastlines and a  
couple of large bodies of large water, depending on size. This file  
could be updated once a year or so. It is not as if the coastline is  
changing so dramatically that it needs to be updated every few weeks.  
I think the quality of the current coast lines in OSM is high enough  
that this decision could be made, especially with the work Christoph  
Hormann has done on Antarctica last year.


Apart from the Great Lakes, this would also mean that the IJsselmeer  
in the Netherlands and two lakes in Russia (Ladoga and Onega) need to  
be retagged. It might be inconvenient, but why isn't that a problem  
for other large lakes?


Regards,

Frank


Quoting perso...@charleskiyanda.com:


The basic technical restrictions are detailed here

http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcoastline

It may well be that the person who fixed the coastline (let's call  
him Pierre, he's on the list) didn't respect those  
conventions/missed a detail/etc and so the change was reverted  
pronto to not screw up with the map rendering. Pierre has contacted  
the person who reverted him, so we'll know more in a bit.


The question of where does the coastline end and riverbank start is  
a question that was probably debated at length 4-5 years ago with no  
clear resolution. The page does mention the great lakes as an  
example of lakes wrongly tagged with coastline, but that will  
probably stay like that in the near future. Personally, I think the  
great lakes should stay as coastline not just because it'd be hard  
to change. It might be worth coming to a consensus here first before  
we try to fix the coastline between Montréal and Sorel. Clearly, the  
current situation is suboptimal.


My personal approach is to try to consider different definitions,  
starting from the one that gives me the eastern most boundary and  
then move westward. The options I can identify are:


--all land that is closer to other land than to international waters  
is coastline (that gives a boundary somewhere around Nova Scotia and  
half-way up Newfoundland)
--Name change boundary: all land that touches water where the  
St-lawrence is still called the St-Lawrence is *not* coastline.  
(That gives a boundary around the Gaspésie peninsula.)
--Salt to fresh water change. That occurs where the Saguenay river  
dumps into the St-lawrence. Anything east would be coastline, west  
would not.
--Historical navigation: Quebec city (or around Rivière-du-Loup and  
Rimouski?) is roughly where boats would get stuck over winter before  
we had really good ice breakers.
--West-side name change: coastline extends through the St-lawrence  
river up until it's no longer called the St-Lawrence river.


I could see a point for going even further up the St-Lawrence and  
including the great lakes, just because of their size, though  
technically they're lakes.


This is probably a case where science, common language, semantics,  
and database theory have trouble.


Charles

Quoting Harald Kliems kli...@gmail.com:


Just to add to that: The question of coastline versus riverbank is not just
a mapping/geographical question, but also a technical one. Because of the
length and complexity of the coastline and the requirement to render it at
low zoom levels, there is special pre-processing for converting the
coastline data into shapefiles that only happens every couple weeks (at
least that used to be case). You can see the effects of this when between
z4 and z5 the parts of the St. Lawrence that are not tagged with coastline
disappears on the standard map.

Now this doesn't necessarily explain why the coastline ends and restarts,
but it might have something to do with it. I would also suggest contacting
the person who did the revert directly.

Harald.


On Thu, Apr 3, 2014 at 10:40 AM, Adam Martin s.adam.mar...@gmail.comwrote:


Charles,

I took a look at the area that you describe and I see what you mean - the
coastline designation disappears around Sorel and reappears just past
Montreal. Looking in the area of the gap, the use of Coastline appears to
suddenly switch to Water and Riverbank. The source of the information
also switches, from the NRCAN database to Bing.

I am not aware of a discussion that flagged this area to be left as-is
on the map. I am also not sure why someone would be protecting the area
from corrections / changes.

However, I believe I can see where the confusion came from (at least

Re: [Talk-ca] GNS tag cleanup

[steggink]

Hi Paul,

gns:jog refers to the sheet number of the Joint Operations Graphics  
map series.
gns:mgrs refers to the Military Grid Reference System, which is  
nothing more than an alternate representation of the coordinate system


IMO both these values can be safely removed.

I don't know about the other ones. Perhaps you can find more  
information here: http://earth-info.nga.mil/gns/html/


Regards,

Frank

Quoting Paul Norman penor...@mac.com:


About 6 years ago, a set of data was imported from GNS, consisting of place
names, mainly of place=town.

As an example, see http://www.openstreetmap.org/node/52556192/history

Thy have a few tags, many of which can probably be safely automatically
eliminated by editor software.

Using the example node, I think the following should be added to the
automatic removal list in editors


gns:dms_lat=490200
gns:dms_long=-1224900
gns:lat=49.03
gns:long=-122.816667
gns:n:xx:full_name=White Rock
gns:n:xx:full_name_nd=White Rock
gns:n:xx:modify_date=1993-12-14
gns:n:xx:sort_name=WHITEROCK
gns:cc1=CA

I'm not sure on the following. Anyone know their history, and if they're of
any use to OSM?

gns:adm1=02
gns:dsg=PPL
gns:fc=P
gns:jog=NM10-08
gns:mgrs=10UEV1340031177
gns:n:xx:nt=N
gns:rc=1
gns:ufi=-575923
gns:uni=-812858


Any comments?


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





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

Re: [Talk-ca] GNS tag cleanup

[steggink]

Hi Pierre,

Did you intend to post this link:  
http://earth-info.nga.mil/gns/html/gis_countryfiles.html ?


Frank

Quoting Pierre Béland pierz...@yahoo.fr:

This page gives the variables description. To reconcile with GNS, I  
suggest that only UFI and UNI unique identifiers have to be kept.



 
Pierre




 De : stegg...@steggink.org stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Vendredi 14 février 2014 4h39
Objet : Re: [Talk-ca] GNS tag cleanup


Hi Paul,

gns:jog refers to the sheet number of the Joint Operations Graphics 
map series.
gns:mgrs refers to the Military Grid Reference System, which is 
nothing more than an alternate representation of the coordinate system

IMO both these values can be safely removed.

I don't know about the other ones. Perhaps you can find more 
information here: http://earth-info.nga.mil/gns/html/

Regards,

Frank

Quoting Paul Norman penor...@mac.com:


About 6 years ago, a set of data was imported from GNS, consisting of place
names, mainly of place=town.

As an example, see http://www.openstreetmap.org/node/52556192/history

Thy have a few tags, many of which can probably be safely automatically
eliminated by editor software.

Using the example node, I think the following should be added to the
automatic removal list in editors


gns:dms_lat=490200
gns:dms_long=-1224900
gns:lat=49.03
gns:long=-122.816667
gns:n:xx:full_name=White Rock
gns:n:xx:full_name_nd=White Rock
gns:n:xx:modify_date=1993-12-14
gns:n:xx:sort_name=WHITEROCK
gns:cc1=CA

I'm not sure on the following. Anyone know their history, and if they're of
any use to OSM?

gns:adm1=02
gns:dsg=PPL
gns:fc=P
gns:jog=NM10-08
gns:mgrs=10UEV1340031177
gns:n:xx:nt=N
gns:rc=1
gns:ufi=-575923
gns:uni=-812858


Any comments?


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








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




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

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

[Frank Steggink]

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

Re: [OSM-talk-nl] Mensen die voordracht over OSM geven?

[Frank Steggink]

Raymond, probeer anders het OSM forum: 
http://forum.openstreetmap.org/viewforum.php?id=12

Waarschijnlijk is dat nu wel erg kort dag.

Frank

On 11-11-2013 0:32, Raymond wrote:
Helaas nog geen geïnteresseerden gevonden, sowieso lijkt deze 
mailinglijst een beetje dood.

Dat laatste is wel jammer omdat openstreetmap best awesome is.

On 6-11-2013 13:29, Henk Hoff wrote:

Hoi Raymond,

Zoals het er nu naar uitziet, zou ik wel kunnen. Echter, aangezien 
Delft voor mij wel een beetje aan de andere kant van het land is het 
misschien handiger (wanneer je meerdere gegadigden hebt) om voor 
iemand anders te kiezen :-)

Laat maar even weten.

Gr,
Henk Hoff


2013/11/5 Raymond van Vugt ligfietsraym...@gmail.com 
mailto:ligfietsraym...@gmail.com


Hoi,5/
voor het weekend van de piratenpartij zoek ik eigenlijk een
ervaren OSM'er die duidelijk en vrijblijvend OSM zou willen
presenteren op 15/16 november te Delft.
Zelf ben ik hypergeïnteresseerd, anderen ook, maar verder als
openfietsmap op de garmin installeren en een beetje editten in
potlach kom ik niet echt.

Interesse?  dan houdt ik me aanbevolen

Groet, Raymond van Vugt

___
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

Re: [OSM-talk-nl] Meetup met OSM BE over adressen imports

[Frank Steggink]

On 6-10-2013 12:30, Johan C wrote:
Op zaterdag 16 november zal in het Belgische Hoogstraten een meeting 
plaatsvinden van de Nederlandse en Belgische OSM community met als 
doel het maken van afspraken over het importeren van alle adressen in 
Nederland en Vlaanderen uit openbare databronnen (BAG / CRAB). 
Onderdeel daarvan zijn 1) het opstellen van een address removal policy 
2) een address import policy 3) een address maintenance policy en 4) 
afspraken over de uitvoering van de import. Dit is een ingewikkeld 
vraagstuk waarbij compromissen noodzakelijk zijn, met name als gevolg 
van de beperkt beschikbare tijd van OSM vrijwilligers. Om succesvol te 
zijn zal de meeting in de weken voor 16 november enige 
voorbereidingstijd vergen.
Mocht je interesse hebben om deel te nemen aan de voorbereiding en de 
meeting, laat dat dan s.v.p. uiterlijk 12 oktober weten via 
osm...@gmail.com mailto:osm...@gmail.com. Dit mailadres kun je ook 
gebruiken indien je op 16 november niet aanwezig kunt zijn maar wel 
wilt deelnemen aan de voorbereiding.


Cheers, Johan


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

Hoi Johan,

Gaat dit ondermeer over de BAG-import meeting die Gert Jan Idema en 
Sebastic van plan zijn te organiseren?


Groeten,

Frank

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

Re: [OSM-talk-nl] Talk-nl Digest, Vol 79, Issue 2

[Frank Steggink]

Dag Theo,

De 1:5 kaart is een gegeneraliseerd product. Dat betekent dat er 
data moet worden weggelaten om een goed kaartbeeld te geven. De 
kartografische weergave is belangrijk bij generalisatie, maar dat gaat 
(zoals je ziet) wel ten koste van de nauwkeurigheid. Dit schaalniveau is 
dan ook meer bedoeld voor orientatie. De reden dat ik een gigapan 
hiervan heb gemaakt (en niet van de 1:25000 kaart) is dat afgelopen week 
deze nieuwe versie is vrijgegeven. Het bijzondere hieraan is dat de 
generalisatie (d.w.z. aanpassingen aan de kaarten om dingen weg te laten 
en/of te verschuiven) geheel automatisch is verlopen. Voor een 
landsdekkende serie is dat een unieke presentatie. Mocht iemand toch 
iets met de BRT-data in OSM willen doen, dan zou ik, naast er eerst heel 
goed over nadenken of je het echt moet willen, de TOP10NL vectordata 
gebruiken. De 1:5 kaart en de nog te releasen data is hiervoor veel 
minder geschikt. Ik had misschien beter moeten benadrukken dat de 
instemming van het Kadaster voor hergebruik van de BRT-data niet 
specifiek voor de 1:5 kaart bedoeld is.


Groeten,

Frank

On 11-9-2013 12:30, Theo de Kraker wrote:

Hallo Frank,

Ik ben een complete leek bij openstreetmap maar wel geïnteresseerd.

N.a.v. je mail op 7 september j.l. :


  Talk-nl Digest, Vol 79, Issue 2

reageer ik op het Gigapan Topraster.

Daaarbij heb ik even gekeken naar mij woonplaats Almere, waarbij ik 
zover mogelijk ben ingezoomd.


Wat mij betreft is die kaart maar zeer beperkt bruikbaar, n.l. alleen 
geschikt om in de gewenste wijk te komen. De straten in een wijk 
worden wel aangegeven, echter zo onnauwkeurig, dat je er niet mee kunt 
navigeren, omdat busbanen, fietspaden, etc. vaak hetzelfde worden 
aangegeven als gewone wegen.

De huidige OS-map is beter!

mvg,
Theo de Kraker




Op 7 september 2013 14:00 schreef talk-nl-requ...@openstreetmap.org 
mailto:talk-nl-requ...@openstreetmap.org:


Send Talk-nl mailing list submissions to
talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.openstreetmap.org/listinfo/talk-nl
or, via email, send a message with subject or body 'help' to
talk-nl-requ...@openstreetmap.org
mailto:talk-nl-requ...@openstreetmap.org

You can reach the person managing the list at
talk-nl-ow...@openstreetmap.org
mailto:talk-nl-ow...@openstreetmap.org

When replying, please edit your Subject line so it is more specific
than Re: Contents of Talk-nl digest...


Today's Topics:

   1.  Gebruik data Basisregistratie Topografie (Frank Steggink)


--

Message: 1
Date: Fri, 06 Sep 2013 18:16:41 +0200
From: Frank Steggink stegg...@steggink.org
mailto:stegg...@steggink.org
To: OpenStreetMap NL discussion list talk-nl@openstreetmap.org
mailto:talk-nl@openstreetmap.org
Subject: [OSM-talk-nl] Gebruik data Basisregistratie Topografie
Message-ID: 5229ffe9.7010...@steggink.org
mailto:5229ffe9.7010...@steggink.org
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hoi,

Bij mij en diverse anderen was de indruk aanwezig dat data van de
Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de
licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van
alle BRT-producten (vector ?n raster) blijkt geruime tijd geleden
omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel
compatible is, maar (IANAL) waarschijnlijk is vermelding op de
attribution pagina voldoende. Het Kadaster weet ook dat OSM
geaggregeerd
is uit allerlei bronnen, waaronder de vele duizenden mappers die veel
energie hierin hebben gestoken. Misschien is dit voer voor
legal-talk om
dit helemaal uit te kristalliseren.

Anyways, de onduidelijkheid die nog rest, wordt volledig
weggevaagd door
Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem
betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op
andere
plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een
bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft
gemaakt. Als
hij dat als product manager zegt, dan is dit ongetwijfeld waar.

Let op, ik wil met dit bericht geen discussie opstarten over de import
van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij
monde van Ben Bruns, wordt toegejuicht (mits vermelding op de
attribution pagina). Gegeven de data van eerdere imports (AND,
3dShapes), zal het toevoegen hiervan een zeer grote inspanning
vereisen!
Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel
goed, aangezien het Kadaster erin geslaagd is om de productiecyclus
zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat
betekent dat TOP10NL in het algemeen even oud of nieuwer is dan

[OSM-talk-nl] Gebruik data Basisregistratie Topografie

[Frank Steggink]

Hoi,

Bij mij en diverse anderen was de indruk aanwezig dat data van de 
Basisregistratie Topografie (BRT) in OSM niet toegestaan is, omdat de 
licentie (CC-BY-SA) incompatible zou zijn met ODbL. De licentie van 
alle BRT-producten (vector én raster) blijkt geruime tijd geleden 
omgezet te zijn naar CC-BY [1]. Je zou kunnen twijfelen of dit wel 
compatible is, maar (IANAL) waarschijnlijk is vermelding op de 
attribution pagina voldoende. Het Kadaster weet ook dat OSM geaggregeerd 
is uit allerlei bronnen, waaronder de vele duizenden mappers die veel 
energie hierin hebben gestoken. Misschien is dit voer voor legal-talk om 
dit helemaal uit te kristalliseren.


Anyways, de onduidelijkheid die nog rest, wordt volledig weggevaagd door 
Ben Bruns. Hij heeft op diverse plekken uiting gegeven dat het wat hem 
betreft prima is dat BRT-data wordt hergebruikt binnen OSM of op andere 
plekken. Het Kadaster juicht dat juist toe. Gisteren was ik op een 
bijeenkomst waar hij dit nogmaals expliciet duidelijk heeft gemaakt. Als 
hij dat als product manager zegt, dan is dit ongetwijfeld waar.


Let op, ik wil met dit bericht geen discussie opstarten over de import 
van BRT data in OSM, maar alleen dat hergebruik door het Kadaster, bij 
monde van Ben Bruns, wordt toegejuicht (mits vermelding op de 
attribution pagina). Gegeven de data van eerdere imports (AND, 
3dShapes), zal het toevoegen hiervan een zeer grote inspanning vereisen! 
Dit geldt ook voor kleine gebieden! De actualiteit van TOP10NL is wel 
goed, aangezien het Kadaster erin geslaagd is om de productiecyclus 
zodanig te stroomlijnen dat de oudste bladen 2 jaar oud zijn. Dat 
betekent dat TOP10NL in het algemeen even oud of nieuwer is dan de 
Bing-foto's, die grofweg van 2010 zijn.


Verder een nieuwtje: het Kadaster is ook een paar jaar bezig geweest met 
het automatisch generaliseren van de TOP10NL data naar een schaal van 
1:5. Een belangrijke fase hierin is afgerond, namelijk dat heel 
Nederland is omgezet en de rasterbeelden hiervan zijn vrijgegeven voor 
het publiek (uiteraard ook CC-BY). De data is bij het Kadaster aan te 
vragen, maar staat nog niet op PDOK. Uiteraard heb ik, in goede 
traditie, een aanvraag ingediend en de data ontvangen ;) Voor degenen 
die alvast willen kijken, heb ik alle bladen aan elkaar geplakt en op 
Gigapan gezet: http://gigapan.com/gigapans?query=top50raster. Het 
Kadaster hoort graag feedback, dus fouten kunnen gemeld worden. Het is 
nog niet duidelijk waar, maar hopelijk zal die vraag gauw beantwoord zal 
worden.


Groeten,

Frank

[1] http://www.kadaster.nl/BRT


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

[OSM-talk-nl] Crowdsourcing...

[Frank Steggink]

Het mooie aan crowdsourcing is dat je veranderingen in de werkelijkheid 
binnen een paar dagen in de kaart kunt verwerken.
Het minder mooie aan crowdsourcing is dat deze wijziging een paar dagen 
later weer door iemand anders ongedaan wordt gemaakt...



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

Re: [OSM-talk-nl] Crowdsourcing...

[Frank Steggink]

On 13-6-2013 19:04, Lennard wrote:

On 13-6-2013 19:01, Frank Steggink wrote:

Het mooie aan crowdsourcing is dat je veranderingen in de werkelijkheid
binnen een paar dagen in de kaart kunt verwerken.
Het minder mooie aan crowdsourcing is dat deze wijziging een paar dagen
later weer door iemand anders ongedaan wordt gemaakt...


Gebaseerd op immer achter de feiten aanlopende lufo's ?


Dat weet ik niet. Ik heb hem om uitleg gevraagd. Nu is het wel zo dat 
mijn aanpassing onlogisch voorkomt, maar het geeft wel de huidige 
situatie aan. In ieder geval heb ik de motivatie in het commentaar van 
mijn changeset aangegeven.


Frank

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

Re: [OSM-talk] Revival: Multilingual Country-List

[Frank Steggink]

On 20-2-2013 10:47, Peter Körner wrote:

Hi

I revived the Multilingual Country-List tool. Now with Overpass-API as 
source, it's a useful tool again. If you find the time, head over to 
http://toolserver.org/~mazder/multilingual-country-list/ and look 
for your favorite language.


If you find a low completeness (100%), check out the list of the 
country names. If they are translated well, click the mark ok link 
and your progress rises.


If the translation is bad, use the josm link to update load up the 
respective node and add a name:XX tag with the correct translation. 
Less then 10 minutes later, the update should arrive in the list and 
you can mark the now fixed translation as OK.


Have fun!
Peter

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


Hi Peter,

Great idea :) However, I have the impression that a couple of countries 
is missing. For example, Guernsey is included, but Jersey is not. 
Shouldn't we stick to a list like this: 
http://en.wikipedia.org/wiki/List_of_sovereign_states

Most of it is already there. Or would this be a too sensitive subject?

Frank

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

Re: [OSM-talk-nl] Staat licentie van top10nl importeren toe ?

[Frank Steggink]

On 15-2-2013 20:02, Top10NL Import wrote:
Ik zit er over te denken om top10nl data te importen in Open 
Streetmap. Het gaat dan om wegen, fietspaden, zandwegen, paden, etc.

Is dat toegestaan gezien de licentie van top10nl ?
De licentie van Top10nl is namelijk CC-BY-SA 3.0. Voor Open Streetmap 
is dat ODbL http://opendatacommons.org/licenses/odbl/. Zie ook 
http://forum.openstreetmap.org/viewtopic.php?pid=313299#p313299.

Is er expliciet toestemming nodig van het Kadaster ?


Beste Top10NL Import,

Afgezien van de vraag of de TOP10NL licentie compatible is met OSM (wat 
dus niet zo is), vraag ik me af wat is de meerwaarde van de import?


Bijna alle wegen, die met de auto berijdbaar zijn, zitten er al in. 
Fiets- en voetpaden en zandwegen zitten er ook voor een groot deel in. 
Niet overal, maar wel meer dan genoeg om bruikbaar te zijn. Een ander 
feit is dat TOP10NL data één tot drie jaar achterloopt. De meest recente 
toevoegingen zijn gedaan op basis van luchtfoto's van 2011. TOP10NL 
heeft een herzieningscyclus van twee jaar. Ook kan niemand garanderen 
dat de data in TOP10NL compleet en juist is. Voor de nauwkeurigheid hoef 
je het ook niet te doen. TOP10NL wordt gemaakt voor kaarten op schaal 
1:5000 tot 1:25000. Dat is zo'n beetje ook de nauwkeurigheid van wat nu 
in OSM zit. Misschien niet overal, maar het verschil is te weinig om een 
hele import op je nek te halen. Wat de hoeveelheid werk betreft, het 
wordt een crime om de data goed te integreren. Kortom, ik zou er niet 
eens aan denken.


Verder vind ik het een slechte zet dat je je vraag anoniem stelt. Voor 
mij is dat een reden om je voorstel bij voorbaat niet te steunen. Wat 
heb je te verbergen? Anonimiteit past niet bij een open data project.


Frank


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

Re: [OSM-talk-nl] Staat licentie van top10nl importeren toe ?

[Frank Steggink]

On 15-2-2013 21:52, Frank Steggink wrote:

On 15-2-2013 20:02, Top10NL Import wrote:
Ik zit er over te denken om top10nl data te importen in Open 
Streetmap. Het gaat dan om wegen, fietspaden, zandwegen, paden, etc.

Is dat toegestaan gezien de licentie van top10nl ?
De licentie van Top10nl is namelijk CC-BY-SA 3.0. Voor Open Streetmap 
is dat ODbL http://opendatacommons.org/licenses/odbl/. Zie ook 
http://forum.openstreetmap.org/viewtopic.php?pid=313299#p313299.

Is er expliciet toestemming nodig van het Kadaster ?


Beste Top10NL Import,

Afgezien van de vraag of de TOP10NL licentie compatible is met OSM 
(wat dus niet zo is), vraag ik me af wat is de meerwaarde van de import?


Bijna alle wegen, die met de auto berijdbaar zijn, zitten er al in. 
Fiets- en voetpaden en zandwegen zitten er ook voor een groot deel in. 
Niet overal, maar wel meer dan genoeg om bruikbaar te zijn. Een ander 
feit is dat TOP10NL data één tot drie jaar achterloopt. De meest 
recente toevoegingen zijn gedaan op basis van luchtfoto's van 2011. 
TOP10NL heeft een herzieningscyclus van twee jaar. Ook kan niemand 
garanderen dat de data in TOP10NL compleet en juist is. Voor de 
nauwkeurigheid hoef je het ook niet te doen. TOP10NL wordt gemaakt 
voor kaarten op schaal 1:5000 tot 1:25000. Dat is zo'n beetje ook de 
nauwkeurigheid van wat nu in OSM zit. Misschien niet overal, maar het 
verschil is te weinig om een hele import op je nek te halen. Wat de 
hoeveelheid werk betreft, het wordt een crime om de data goed te 
integreren. Kortom, ik zou er niet eens aan denken.


Verder vind ik het een slechte zet dat je je vraag anoniem stelt. Voor 
mij is dat een reden om je voorstel bij voorbaat niet te steunen. Wat 
heb je te verbergen? Anonimiteit past niet bij een open data project.


Frank


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


Kijk ook even hier, v.w.b. de huidige stand van zaken m.b.t. bospaden:
http://www.kadaster.nl/web/file?uuid=1c8c2665-d016-4893-b0f3-b976d795562eowner=23cbe925-35ce-4a72-ac8c-a33a0c19ae1econtentid=1474
(Waarschuwing: PDF)

Zie op pagina 19:
Voor objecten die vanuit luchtfoto’s moeilijk waarneembaar zijn, 
bijvoorbeeld bospaden, overweegt het
Kadaster om crowdsourcing toe te passen. In dit geval houdt dat in, dat 
vrijwilligers, bijvoorbeeld
boswandelaars, geografische informatie over bepaalde objecten aan het 
Kadaster kunnen aanleveren.


En:
Vanaf 2014 zal de actualisering van de TOP10NL in toenemende mate 
gebaseerd worden op mutatietriggers

vanuit externe bronnen die worden geverifieerd op actuele luchtfotografie.

Dit is wel grappig. Straks gaat het Kadaster OSM in de gaten houden en 
gaan ze o.b.v. onze mutaties TOP10NL bijhouden ;)
Dit is trouwens ook de werkwijze van National Resources Canada, die o.a. 
topografische kaarten maken voor Canada. Overigens kan Canadese 
topografische data wel worden geïmporteerd worden, omdat die PD is.


Frank

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

Re: [Talk-ca] licence et notion de paternité

[Frank Steggink]

Hopefully they'll change the license so it becomes truly open. They 
probably don't have as much experience with open data licenses as we, as 
the OSM community, have. Because we go farther than just visualizing the 
data, these questions were probably beyond their original thoughts about 
how their data would be used.


Frank

On 18-12-2012 14:11, Bruno Remy wrote:


Bonjour Pierre,

Merci pour le suivi. De mon côté j'ai eu quelques échanges avec un des 
principaux membres de Capitale Ouverte, l'équivalent de Québec Ouvert 
à l'échelle de la Ville de Québec.
À première vue, ils sont bien surpris de nos interrogations sur les 
licences et ne voient pas où il y a des blocages ...
Je leur ai soumis un document expliquant les discutions que nous avons 
eu sur la liste-CA et le constat qu'aucune ville au monde n'avait 
exigé qu'on la mentionne sur la MAP, depuis les 8 années d'existance 
d'OSM... Alors pourquoi une exception pour Montréal ou pour la Ville 
de Québec?


Bruno Remy

Le 2012-12-17 20:58, Pierre Béland infosbelas-...@yahoo.fr 
mailto:infosbelas-...@yahoo.fr a écrit :


Bruno,

tiens justement je viens juste d'envoyer un courriel relatif à
Québec Ouvert.

Certaines licences dites libres imposent des restrictions qui ne
sont pas toujours réalisables au niveau de la mention. Mais
normalement une simple mention dans une page ou dans la base de
données suffit.

Quand on regarde les licences des municipalités, on voit toutes
sortes de restrictions au niveau de la mention.
Dans la citation ci-dessous, je ne sais pas comment on peut
l'interpréter. Par exemple, faudrait-il mettre un lien url pour
chaque donnée dans la base? Serait-ce suffisant de fournir cette
info au niveau du changeset?

Pierre


*De :* Bruno Remy bremy.qc...@gmail.com
mailto:bremy.qc...@gmail.com
*À :* talk-ca@openstreetmap.org
mailto:talk-ca@openstreetmap.org talk-ca@openstreetmap.org
mailto:talk-ca@openstreetmap.org
*Envoyé le :* Lundi 17 décembre 2012 20h33
*Objet :* [Talk-ca] licence et notion de paternité

Bonjour,
Une licence qui impose de mentionner la paternité («source»)
des données, ça implique quoi concrètement?
a)Juste un tag source underground dans la BD comme OSM le
fait déjà pour les données de Canvec, Tiger, etc
ou
b)vraiment une mention visible pour les utilisateurs de
l'intreface web, à côté de la mention (c) OpenStreetMap et ses
contributeurs?
Si la réponse est a) on peut l'utiliser. si b) on ne peut
pas incorporer les données.
Voir ci-dessous:

Sous réserve de : Mentionner la paternité de « l’Information »
: sa source (a minima le nom du « Producteur et la date de sa
dernière mise à jour. Le « Réutilisateur » peut notamment
s’acquitter de cette condition en indiquant un ou des liens
hypertextes (URL) renvoyant vers « l’Information » et assurant
une mention effective de sa paternité. Cette mention de
paternité ne doit ni conférer un caractère officiel à la
réutilisation de « l’Information », ni suggérer une quelconque
reconnaissance ou caution par le « Producteur », ou par toute
autre entité publique, du « Réutilisateur » ou de sa
réutilisation.
---
Bruno Remy

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




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



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

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

[Frank Steggink]

On 11-12-2012 17:42, Sebastiaan Couwenberg wrote:

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


Woodpeck-repair is een bot van Frederik Ramm.
Als je zijn comment in de changeset leest, zie je waarom hij deze run 
heeft uitgevoerd:
revert un-discussed world-wide mechanical edits. please note that 
'deprecated' does not mean we want you to auto-edit world-wide (else 
we'd have done that alrady)


Het is not done om automatisch deprecated tags zomaar te editen in wat 
anders. De kans dat een bot fouten maakt is ernstiger dan het vermeende 
probleem dat de auteur meent op te moeten lossen. Dat sommige 
gebruikers zoals pschonmann zich niet aan dat soort richtlijnen 
aantrekt, wil niet zeggen dat er een edit war is.


Ik neem aan dat hij al op zijn gedrag door Frederik, de Data Working 
Group of anderen is aangesproken. Frederik en een aantal anderen hebben 
bewezen genoeg skills te hebben en het vertrouwen van de community in 
het algemeen te hebben om dit soort acties van anderen ongedaan te maken.


Groeten,

Frank


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

[OSM-talk-nl] Bing-update in Duitsland

[Frank Steggink]

Hoi,

Voor wie het nog niet gemerkt heeft: de afgelopen week hebben onze 
oosterburen een update gekregen van de Bing-luchtfoto's. Tot voor kort 
werden grote delen van Duitsland alleen door Landsat bestreken, maar 
gelukkig is dat nu veranderd. Dus goed nieuws voor iedereen die wel eens 
over de grens aan het werk is in OSM. :)


Groeten,

Frank

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

Re: [Talk-ca] Internal CanVec conflicts

[Frank Steggink]

On 14-11-2012 19:37, Pierre Béland wrote:


Pierre Lamoureux***:* Mardi 13 novembre 2012 23h54
**
Je suis un nouveau participant au projet OSM, par contre je ne suis 
pas un débutant en cartographie et je saisis assez bien les termes de 
la discussion en cours


En passant, j’ai un peu d’expérience dans l’utilisation de FME pour 
convertir les données CANVEC pour construire des cartes électroniques 
et je peux contribuer dans cette zone.



Pierre,

Bienvenue sur cette liste de discussion.

Je ne connais pas le FME. Sur un groupe de discussion, on je vois Use 
of FME with CGI for online map-delivery.


Est-ce un serveur de cartes? Est-ce OpenSource?

Pierre


Hi Pierre,

FME is an ETL-tool, which stands for Extract, Transform and Load. It is 
proprietary software, made by the Vancouver-based company Safe Software. 
[1] It supports a couple of hundred geospatial formats, both reading and 
writing. Also the OSM format is supported.


There is also an open source geospatial ETL tool, named GeoKettle, an 
extension of Kettle (a metadata driven ETL tool). [2] It is being 
developed by Québec based company Spatialytics. They don't support OSM 
as an output format, but as it is open source it could be extended with 
anyone with the right skills and time.


Frank

[1] http://www.safe.com/fme/fme-technology/
[2] http://www.spatialytics.org/projects/geokettle/


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

Re: [Talk-ca] Internal CanVec conflicts

[Frank Steggink]

Hi Paul,

It probably won't come to you as a surprise if I would say it is 
acceptable, but to a certain degree. A map with no data is not a map. A 
map with inconsistent data is still a map, but obviously something is 
not right. A map with perfectly consistent data doesn't need to tell the 
truth either. Remember the fantasy city someone added about a month ago? 
Furthermore, a map can become outdated. This is also true for OSM.


Anyways, the reason I've been importing Canvec data is to provide more 
coverage, so others can work with it. OSM is a community project, and I 
think everyone has a share in it. This is one of the main reasons I 
started with OSM, because I believe in the ideals and goals. To you it 
might sound that importers like me are leaving a big mess behind for 
others to deal with. To me, it was a choice. The alternative would be 
either no data, or very sparse and incomplete data. It would take ages 
to complete the map, since there are not nearly as much mappers in 
Canada as there are in Germany. A map which is only half complete 
doesn't have half the value of a complete map, but way less. That's also 
the reason I imported forests in suburban areas. It can still be cleaned 
up later. Leaving the forest out of it leaves an ugly gap, and fixing it 
during the import is so time consuming the import would go on endlessly 
(which it does already...).


Also, many or most people who are mapping with OSM do not have a mapping 
or geospatial background. Let me be clear, I think it is wonderful that 
they join OSM and step upon the learning curve to become a contributor. 
On the other hand, in many cases the quality of their contributions are 
not that great. I also don't like the fact that something is abandoned 
half-way (like the Canvec import). So the choice I made was to provide 
them and the rest of the community with some kind of baseline. With the 
Canvec data imported, it makes it easier for people to add POI's and 
other stuff. And while importing, I also fixed other errors which 
existed in the maps. Of course not all of them, but what would be 
reasonably possible from my armchair. Furthermore, the imports I've done 
about half a year ago were aimed at filling gaps between existing 
imports. It is a pretty daunting task, so it is no surprise many have 
stopped, and I just wanted to get the job done.


However, time is limited, so I eventually decided to stop. The reasons 
which motivated me doing imports are no longer enough to continue. It is 
partially due to the criticism of you and others. If my contributions 
are not accepted / acceptable, there is no reason to continue, so I can 
better stop. I also think that OSM has caused a lot of awareness for 
open data, and governments are opening up much more. For example, also 
in the Netherlands a lot of datasets have become open data, like the 
national road register, buildings, and topography. Of course, with the 
availability of Canvec, this is also true in Canada. So for many 
geospatial professionals there is not much reason to continue OSM, 
except when you're interested in areas for which no other alternative 
exists (cycling routes, historic buildings, etc.).


Frank

On 10-11-2012 12:37, Paul Norman wrote:

CanVec data comes from multiple sources and this can lead to internal
inconsistencies. A common case is a new development where there used to be
trees. The tree data in CanVec might be older and show an area as forested
while there is newer road data indicating that the area has been developed.
An example of this type is
http://www.openstreetmap.org/?lat=45.695lon=-73.905zoom=17 although I have
seen many other cases of it.

Another common case is the trees in water problem frequently found in BC. A
typical example is
http://www.openstreetmap.org/?lat=58.648lon=-123.911zoom=17 where there is
a conflict between the water data and the forest data. You need to view the
data as it doesn't show up on the rendering.

Is it the communities view that it is okay to import CanVec without
reconciling the internal differences between the layers?

My view is that importing data without resolving conflicts of this type
where it conflicts with either existing data or internally is not an
acceptable import and indicates the importer did not sufficiently review
what they were uploading.


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




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

Re: [Talk-ca] Import Canvec : micro-tâches / Canvec imports micro-tasking

[Frank Steggink]

Hi Pierre,

I'm glad to see you're taking a constructive approach towards the 
discussion initiated by Paul :) I definitely agree something needs to be 
done to make imports more manageable, especially the Canvec import. 
There is also an amount of work left behind as I mentioned in my other 
mail. Of course that needs to have some attention as well.


Apart from the inconsistencies, there is for example also the Geobase 
import. In 2009 the available Geobase data didn't contain road names in 
Québec, and by then it was also not clear when it would contain names. 
So there are many areas which have roads without names. Furthermore, 
there have been subsequent Canvec releases in which data / tagging 
issues have been resolved. An example is the use of natural=land tag 
as mentioned by Brian Gamberg, but in one or two releases the 
amenity=school and amenity=prison tags were swapped around as well.


Having some kind of checklist attached to the micro-tasking, combined 
with periodical reviews (which IMHO think are necessary, for example 
with new Canvec releases) and tools like OSM Inspector will also ensure 
that the data quality remains good in the future. For this system to 
work, also areas with existing data (either user-contributed or 
imported), which seem complete should be reviewed.


I'm not familiar with the Linz solution, but perhaps someone like 
Martijn van Exel or the Mapbox guys could help setting up something 
useful and user-friendly.


Frank

On 13-11-2012 21:01, Pierre Béland wrote:

Voir discussion en français / See English discussion below

Paul Norman,sat. november 2012 6h37
** Subject :  Internal CanVec conflicts
 Is it the communities view that it is okay to import CanVec without
 reconciling the internal differences between the layers?

 My view is that importing data without resolving conflicts of this type
 where it conflicts with either existing data or internally is not an
 acceptable import and indicates the importer did not sufficiently review
 what they were uploading.

---

L'import de données est essentiel, si l'on veut couvrir toute la 
surface du Canada. Cependant, il est complexe d'importer des fichiers 
CanVec dans les zones où les données existent déjà. Autant les 
contributeurs inexpérimentés qu'expérimentés sont susceptibles de 
faire des erreurs. Le processus d'importation est souvent trop 
complexe et trop long à réaliser.


Les micro-tâches sont actuellement basées sur les zones géographiques 
,chaquegrille NTS étant subdivisée en plus petites zones. En 
subdivisant par couche thématique, je pense que cela permettrait de 
réduire la complexité des importations CanVec, de réduire les erreurs 
et d'encourager plus de gens à importer.  Si nécessaire en raison de 
la taille, certaines grilles pourraient aussi être subdivisée en zones 
plus petites.


Tout comme pour les fichiers Planet, les fichiers d'import OSM  
pourraient être subsiviés par couches telles que routes, poi, landuse, 
forest, coastlines, limites administratives, autres ...). De cette 
façon, chaque tâche d'importation serait moins complexe à réaliser, 
plus facile à comparer avec ce qui existe déjà. En outre, la tâche 
serait réalisée plus rapidement.


Lorsque une couche telle que les forêts semble moins approprié pour 
une région donnée, il serait facile pour le contributeur d'ignorer 
cette couche. Aussi, les limites administratives et les côtes 
devraient être réservés à des gens plus expérimentés. Les fichiers 
pourraient être regroupés dans un répertoire distinct et couvrir de 
plus grandes zones.


Je pense que nous avons besoin de plus que le fichier Google doc 
actuel pour assurer le suivi des imports.
L'outil linz2osm de Nouvelle-Zélande me semble trop complexe. 
Cependant, il peut nous donner  des idées sur la façon de développer 
un tel outil.


Voir linz2osm New Zealand project.
http://linz2osm.openstreetmap.org.nz/

voir discussion de Glen Barnes, Import list.
http://web.archiveorange.com/archive/v/2u2n5O1bELI3yg2ULjry
---

Data import is essential to cover all of Canada, But it is complex to 
import Canvec files in areas were data already exist. Both 
unexperienced and experienced people may make errors. Import process 
is often too complex and too long to realize.


Micro-tasking presently consist of dividing a a NTS grid area in 
smaller zones. If this micro-tasking was based on layers, I think that 
this would reduce the complexity of Canvec imports, reduce errors and 
encourage more people to import. But if necessary because of size, 
some NTS grids could be subdivided by smaller zones.


The OSM import files would be divided by layers like it is done for 
planet files. There could be layers such as roads, poi, landuse, 
water, forest, coastlines, administrative boundaries, other...). This 

Re: [OSM-talk-nl] wegen in drievoud

[Frank Steggink]

JOSM heeft soms last van deze kuren. Het is mij ook wel eens overkomen. 
Je kunt als je met relaties of andere complexe zaken aan de gang gaat 
beter vaker uploaden. Je kunt in JOSM er ook voor kiezen om de changeset 
niet af te sluiten, dus ook al doe je veel veranderingen, dan komen ze 
in dezelfde changeset. OSM sluit de changeset automatisch nadat een uur 
geen wijzigingen zijn veranderd. Je kunt dat doen in het upload-scherm.


Frank

On 21-10-2012 10:53, Hugo Holscher wrote:
Ik heb ook iets dergelijks meegemaakt. Wat ik er van geleerd heb, is 
een tag mee te geven (in bijvoorbeeld een note als dat kan), waarmee 
je, je eigen wijziging kunt selecteren en veranderen. Maar misschien 
had dat in dit specifieke geval niet geholpen.

Hugo
*From:* dbuss...@goudappel.nl mailto:dbuss...@goudappel.nl
*Sent:* Saturday, October 20, 2012 10:47 PM
*To:* OpenStreetMap NL discussion list mailto:talk-nl@openstreetmap.org
*Subject:* Re: [OSM-talk-nl] wegen in drievoud
Vreemd verhaal.
Ik moest alles handmatig herstellen omdat door de dubbeling de 
relaties (bus en fietsknopen) zo in de war waren dat terugdraaien geen 
optie meer was. Bljikbaar was iemand anders tegelijk of net na mij met 
de buslijnen bezig op mijn drievoudige wegen...

Nu is volgens mij alles weer netjes.
Vervolgens ben ik op zoek gegaan of er elders dubbele wegen zijn maar 
kon er geen vinden.
Het is dus niet zo dat JOSM dit vaker doet maar een idee hoe deze 
changeset kon ontstaan heb ik nog steeds niet.



-Johan C osm...@gmail.com schreef: -
Aan: OpenStreetMap NL discussion list talk-nl@openstreetmap.org
Van: Johan C osm...@gmail.com
Datum: 10/20/2012 04:22PM
Onderwerp: Re: [OSM-talk-nl] wegen in drievoud

Ik zie twee mogelijkheden:
1. terugdraaien
2. checken met de validator en de crossing ways handmatig verwijderen

Op 20 oktober 2012 01:31 schreef dbuss...@goudappel.nl 
mailto:dbuss...@goudappel.nl het volgende:


vandaag iets te enthousiast teveel tegelijk in een changeset gepackt.
JOSM heeft daarop een aantal keren timeout gegeven tot het
uiteindelijk gelukt is.
Effect is nu dat alle objecten die ik geraakt heb drie keer boven
elkaar in OSM staan.
Weet iemand hoe dat komt en of het eenvoudig ongedaan gemaakt kan
worden?

Het gaat om http://www.openstreetmap.org/browse/changeset/13561955

Voorbeeld: de volgende ways (allen behorende tot changeset
13561955) zijn identiek:
http://www.openstreetmap.org/browse/way/186703099
http://www.openstreetmap.org/browse/way/186691521
http://www.openstreetmap.org/browse/way/186693939

Groeten, Dirk





Disclaimer

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en
is uitsluitend bestemd voor de geadresseerde. Indien u dit bericht
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken
en de afzender direct te informeren door het bericht te
retourneren. De afzender sluit iedere aansprakelijkheid uit die
voortvloeit uit elektronische verzending.
___
Talk-nl mailing list
Talk-nl@openstreetmap.org mailto:Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl

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

 


Disclaimer

De informatie opgenomen in dit bericht kan vertrouwelijk zijn en is 
uitsluitend bestemd voor de geadresseerde. Indien u dit bericht 
onterecht ontvangt, wordt u verzocht de inhoud niet te gebruiken en de 
afzender direct te informeren door het bericht te retourneren. De 
afzender sluit iedere aansprakelijkheid uit die voortvloeit uit 
elektronische verzending.



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


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



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

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

[Frank Steggink]

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?


Groeten,

Frank

On 21-10-2012 11:36, Hugo Hölscher wrote:


Lijkt me de goede benadering. Hugo

Op 21 okt. 2012 11:07 schreef Gertjan Idema g.id...@zonnet.nl 
mailto:g.id...@zonnet.nl het volgende:


On Sun, 2012-10-21 at 10:49 +0200, Hugo Holscher wrote:

Het viel mij op dat de gegevens van het BAG (tenminste zo als ik
ze in de BAG viewer zie), data bevat die nog niet bestaan. Als je
deze id zoekt: 039710014064, vind je een huis en adres in
Heemstede waarvan de bouw nog niet eens begonnen is. Verder weet
ik dat de bouw vergunning aan verandering onderhevig is. Gaan we
met bulk up-loads nu de mogelijk toekomstige kaart van Nederland
maken of is het wijsheid om de locaties waarvan de status is:
“bouwvergunning verleend” er nog uit laten? 
Hugo 


Mijn insteek op dit moment is om gebouwen met status Bouw
gestart te taggen als building=construction. Voor Bouwvergunning
verleend kan je overwegen om dat ook te doen, om wat meer
informatie te geven aan een mapper die ziet dat er wat gaande is
op een stukje grond. Daarnaast voeg ik een tag bag:status toe.

Gertjan
*From:*Gertjan Idema mailto:g.id...@zonnet.nl 
*Sent:*Saturday, October 20, 2012 8:54 PM 
*To:*talk-nl@openstreetmap.org mailto:talk-nl@openstreetmap.org 
*Subject:*Re: [OSM-talk-nl] Het taggen van BAG data. 
On Sat, 2012-10-20 at 13:21 +0200, Just van den Broecke wrote:

Beste Gertjan e.a,

Een goed plan, ik wil wel meedenken. btw: De BAG is net deze week
ververst met versie 8 sept en 8 okt:

Fijn dat je meedenkt :-)
http://geodata.nationaalgeoregister.nl/inspireadressen/atom/inspireadressen.xml  
(Atom).

e.e.a. moet ook simpeler worden in de toekomst:
http://drupal.pdokloket.nl/nl/producten/pdok-downloads/atomfeeds

Ik probeer wat aan te vullen onder...het blijft een taai onderwerp.


On 17-10-12 13:11, Gertjan Idema wrote:
 Er is een aantal initiatieven gaande voor het opnemen van BAG data in
 Openstreetmap.
 - ruudblank heeft veel werk verricht in Gorinchem.
 - rullzer in de omgeving Purmerend
 - mijn eigen initiatief op basis waarvan Minko (Amersfoort), PeeWee
 (Leusden) en Sebastiaan (Oldambt) nu  kleinschalig
aan het testen zijn.
 - en ongetwijfeld nog meer.

 Helaas is er nog geen standaard voor het taggen van BAG data. Mijn idee
 van deze discussie is om hier samen te vatten wat er tot nu toe gedaan
 en besproken is over het taggen van data afkomstig uit de BAG.
 Vervolgens hoop ik dat we het samen eens kunnen worden over een
 standaard. Deze kan dan opgenomen worden op de Wiki pagina en
 geïntegreerd in tools en scripts. Het doel hierbij is niet om zoveel
 mogelijk BAG dat in openstreetmap te krijgen, maar om te zorgen dat dit
 consistent gebeurt.

 Eerst maar eens een inventarisatie:

 Adres tags op pand of losse nodes
 =
 De BAG maakt onderscheid tussen panden, verblijfsobjecten en
 nummeraanduidingen. Een pand kan meerdere verblijfsobjecten bevatten.
Ja het meestvoorkomende, maar ook omgekeerd (meerdere Panden bij VBO),
maar moet daarvan nog voorbeeld zien.

Hier is een mooi voorbeeld: VBO 034401091735 (Ambachtsweg 52,
Utrecht) ik heb ook nog even geen
idee hoe we dit het beste in OSM zouden kunnen mappen.
Een ander voorbeeld is VBO 034410054743 (Hoogravenseweg
140A). Hier zijn 2 panden samengevoegd en vervolgens opgedeeld in
7 verblijfsobjecten.
Ik kom 161 VBO's met meerdere panden tegen in Utrecht stad, de
meesten met 2 panden per VBO.

 Tot nu toe heb ik de adressen als volgt getagd:
 Voor panden met een enkel verblijfsobject heb ik de adres tags
 (addr:housenumber, addr:postcode, addr:street) aan het pand gekoppeld
 met in tag ref:bagid het BAG id van het pand.
 Voor panden met meerdere verblijfsobjecten heb ik aan het pand geen
 adres tags gekoppeld, dit kunnen immers verschillende straten zijn. De
 adres tags heb ik aan losse nodes gekoppeld met in tag ref:bagid het
 BAG id van de nummeraanduiding.

 ruudblank heeft er in Gorinchem voor gekozen om alle adressen los te
 koppelen van het pand. Als BAG referentie gebruikt hij het BAG id van
 het verblijfsobject in de tag bag:vbo_id en op de panden het BAG id
 van het pand in bag:pand_id.

 rullzer maakt hetzelfde onderscheid als ik tussen panden met 1 of met
 meer verblijfsobjecten, maar gebruikt geen BAG id op de adres nodes.
Een lastige, ik zou in ieder geval zo dicht mogelijk bij het BAG model
blijven...Bijv. kunnen VBOs en (LIG/STA) niet gewoon zelf OSM punt-nodes
zijn (plm 9 miljoen in NL!)? En 

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

[Frank Steggink]

Dat zou je kunnen melden via het terugmeldformulier.

Frank

On 21-10-2012 11:51, Minko wrote:

Het omgekeerde komt ook voor, panden die wel bestaan maar niet in de BAG 
voorkomen.
Bv restaurant Dara (uit 2009): http://www.openstreetmap.org/?way=186870059
Is dat een bekend fenomeen?


Het viel mij op dat de gegevens van het BAG (tenminste zo als ik ze in
de BAG viewer zie), data bevat die nog niet bestaan.

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




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

Re: [OSM-talk-nl] BAG data en de Import Guidelines

[Frank Steggink]

On 21-10-2012 16:04, Sebastiaan Couwenberg wrote:
Nu de discussies over het importeren van BAG data goed op gang komen 
heb ik eens gekeken hoe hiervoor rekening te houden met de Import 
Guidelines [1]. We zijn al een heel eind op weg wat dat betreft, maar 
nog niet aan alle details is al invulling gegeven.


[1] http://wiki.openstreetmap.org/wiki/Import/Guidelines

De checklist noemt acht punten om rekening mee te houden.

1.  Gain familiarity with the basics of OpenStreetMap, including 
editing, such as adding details of your neighbourhood. Consider 
following the beginners' guide.


Ieder van ons voldoet aan dit criterium. Het is inderdaad niet 
verstandig als nieuwe mappers direct aan de slag gaan met BAG data 
voordat we hier een beginners vriendelijke handleiding voor hebben 
opgesteld.


2.  Contact the relevant local OSM community to make sure you're not 
heading down a path someone else has tried and to get a sense of how 
receptive the community is to imports. Check for local user groups, 
local chapters, and country-specific mailing lists.


De discussies met de lokale community zijn gestart op de mailinglist 
[2] en forum [3], en de reacties tot nu zijn nog niet echt negatief. 
Ik verwacht geen bezwaar van de NL community tegen de BAG imports 
zolang de uitvoering hiervan geen problemen gaat verzorgen. Zolang de 
BAG panden maar geen custom edits verwijderen, en BAG woonplaats 
grenzen de bestaanden kunnen aanpassen ipv vervangen lijkt mij de weg 
vrij. Maar het is ook nog wat vroeg om over duidelijke consensus te 
spreken. Nog niet veel verschillende mensen hebben zich in de 
discussies gemengd. Veel meer mensen verwacht eerlijk gezegd ook niet 
echt, er zijn niet erg veel NL mappers die zich ook nog eens met de 
community communicatie bezig houden lijkt het.


[2] 
http://lists.openstreetmap.org/pipermail/talk-nl/2012-October/014215.html

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

3.  Check the license of the data. If the license of the data is not 
compatible with the OpenStreetMap license, you can not use the data.


De open data portal van de Nederlandse overheid [4] is heel expliet in 
de vrije licensering van de BAG data. Licentie: Publiek Domein.


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


Op de home page van de open data portal staat dit wat uitgebreider:
http://lists.openstreetmap.org/pipermail/talk/2012-October/064868.html
Wat is open data?

 *  De data is openbaar;
 *  Er berust geen auteursrecht of andere rechten van derden op;
 *  De data zijn bekostigd uit publieke middelen, beschikbaar gesteld
voor de uitvoering van die taak;
 *  De data voldoen bij voorkeur aan ‘open standaarden’ (geen barrières
voor het gebruik door ICT-gebruikers of door ICT-aanbieders);
 *  Open Data is bij voorkeur computer-leesbaar, zodat zoekmachines
informatie in documenten kunnen vinden.

De situatie rond de postcode is mogelijk nog wel een struikelblok. 
Ondank dat de overheid de data vrij geeft, procederen PostNL en 
Cendris nog steeds tegen het vrij geven van de postcode database. Zie 
de dreigbrief tegen postcodeatlas.nl:


http://www.postcodeatlas.nl/pages/postcodebestand.html

In het vonnis van 21 december 2011 [5] word gesteld dat de postcodes 
die de overheid van PostNL krijgt niet uit het postcodebestand van 
PostNL noch de postcodetabel van Cendris komen, en de databaserechten 
die beide partijen hebben niet van toepassing zijn op de postcodes in 
de BAG. Dat na de privatisering van de PTT het toewijzen van postcodes 
niet meer door een overheidsinstantie gedaan word maakt het tot een 
vreemde situatie. Alle drie partijen stellen nu hun eigen database op 
met de gegevens die zijn gezamenlijk vast stellen zoals ze dat vroeger 
als staatsbedrijf onder een dak deden. De BAG database van de overheid 
word duidelijk als losstaand werk gezien, wat geen afgeleide is van de 
postcode databases van PostNL en Cendris.


Het vonnis word nader toegelicht in Jurispundentie Nr 1 [6].

[5] http://zoeken.rechtspraak.nl/detailpage.aspx?ljn=BU9147
[6] http://www.ivir.nl/publicaties/eechoud/Annotatie_Mf_2012_4.pdf

Mocht in het beroep dat PostNL heeft aangetekend tegen dit vonnis 
geoordeeld worden dat PostNL toch rechten heeft op de postcodes in de 
BAG, dan verwacht ik dat de overheid licentiegelden aan PostNL zal 
gaan betalen voor het gebruik van de postcodes. Wat OSM betreft zullen 
we de postcodes dan mogelijk achterwege moeten laten bij het 
importeren indien de postcodes uit de BAG niet vrijelijk gebruikt 
mogen worden. Ik kan alleen geen informatie vinden over het beroep wat 
PostNL tegen het vonnis zou hebben aangetekend.


Heeft iemand meer informatie over de huidige stand van zake in deze zaak?

4.  Find out what data layers the organization offers. This might be 
street centerlines, building outlines, waterways, addresses, etc.


Gebouwen, adressen en administratieve grenzen. Binnen de BAG bekend 
als de PND, NUM en WPL data 

Re: [Talk-ca] Canvec 10 and landcover issues

[Frank Steggink]

On 19-10-2012 21:46, Harald Kliems wrote:

Hi Pierre,
thanks for the response.

On Fri, Oct 19, 2012 at 3:25 PM, Pierre Béland infosbelas-...@yahoo.fr wrote:

I dont know how you conclude that there is no wetlands around this area in
Laval.  It is not sufficient to see houses around to conclude that there is
no wetland. These are often wooded areas with water all over.  Google
physical also shows a stream starting from this area.

The link below shows a comparison of this area with Google imagery.  Are you
sure that there is no wetland in this area.
http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.91012lat=45.69989zoom=17

This is a misunderstanding. I did not mean that there is _no_ wetland
in the area. But I'm pretty certain that the boundaries of the wetland
are wrong:

http://tools.geofabrik.de/mc/?mt0=mapnikmt1=googlehybridlon=-73.90457lat=45.69533zoom=17

Aside from the wetland issue (see below), we can probably agree that
the area is not natural = wood, even if some people might have planted
trees in their yards.


The link below shows an aera in Saint-Jean-sur-Richelieu were houses have
been built for over 30 years. Look how many houses were flooded last year.
Zoom in to see areas that were flooded.
http://pierzen.dev.openstreetmap.org/hot/openlayers/inondation-richelieu-2011.htm?zoom=16lat=45.28568lon=-73.24907layers=B000T

My experience, as a volunteer for SOS-Richelieu, last year, showed me how
that too often the municipalities have accepted that contractors build
houses over wetlands. And this was often the case with Laval.

Okay, this is a different issue, coming down to the definition of what
wetland is. I'm by no means an expert, but in my understanding you
can't have a residential area in wetlands. In order to build houses
you must first use drainage channels etc. to turn wetland into
developed land. The fact that there can be flooding in a given area
doesn't make it into wetland to me. The wiki isn't very explicit about
this (http://wiki.openstreetmap.org/wiki/Tag:natural%3Dwetland) but
the specific subtypes seem to hint at a definition stricter than
yours. Maybe someone can tell us what definition is used for Canvec.

Cheers,
  Harald.

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


Hi Harald,

As Paul just explained, the Canvec data comes from different ages, so 
what this basically tells is that 20 or 30 years ago (or maybe just 10 
years ago) this area was a wooded marsh. Unfortunately, this landcover 
data is the best available. (The lower resolution Landsat data can be 
pretty old too, and its resolution makes it unusable.) It still needs to 
be reconciled with the roads, preferably with the help of Bing imagery. 
I'm not sure if a decent resolution is available in this area. Good 
coverage is pretty spotty in Canada.


Regarding the flooding: areas which used to be wetlands in the past are 
still prone to flooding, unless significant work has been undertaken 
from ever happening again (like drainage, diverting streams, putting 
extra soil on top). Especially when buildings are built within the 
channels which have been eroded by rivers, then you can basically wait 
for a disaster to happen.


Frank


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

Re: [OSM-talk] [OSM-talk-fr] Continued aggression against French contributors (cadastre integration)

[Frank Steggink]

On 18-10-2012 20:52, Christian Quest wrote:

So far, the only explanation about the usesulness of the dedicated
account is linked to tracking imported data or I missed something on
the wiki.

If this is the goal, why small changesets of imported data may not
require a dedicated account ?
This data doesn't need to be tracked ?

I'm also really wondering on the tracking of the data thru dedicated
accounts for such highly split imports (as a reminder, the cadastre
data is split with 36000+ datasets, one for each village/town/city in
France).
On how many accounts will the cadastre data will have to be tracked ?
Is there a list of cadastre import dedicated accounts somewhere ?
Maybe a required naming of the account names ?

The more interesting proposal I've seen so far were the bot/import
tags. It really brings a benefit for the tracking and makes the
dedicated account requirement outdated.


I also asked some time ago if it was necessary to have a dedicated
account for each source of imported data ?
If tracking is the goal, it seems logical.

If so, I need one dedicated account for:
- cadastre (administrative boundaries + buildings)
- IGN (geodesic points + GEOFLA place=*)
- schools
- RATP (paris public transport, subway station, and we expect 12000+
bus_stops should be available sooner or later)
- SNCF (railway stations and level crossings)
- La Poste (post office locations)
- Nantes metropole adresses (400.000 imported street by street after
crowdsourced reviewing)
and so on... because that's today's situation with more and more
useful datasets to bring into OSM.


Wake up ! opendata is here, now, and the more (useful) datasets we
find the more it is clear that a mass import is not possible.
We've learned from CLC and Tiger imports... and the map is not blank
as it used to be.


Here is my proposal... have separate guidelines for mass imports and
for split/shared/crowdsource imports.

When a full dataset is imported more or less as is by a very small
number of contributors (possibly just one) in such case, YES, a
dedicated account is a real benefit. With ONE dedicated account, you
track all the imported data.

When the dataset needs to be reworked manually, integrated sometime by
reviewing each object one by one, or sometime group by group, where
the works is share by a lot of contributors, in such cases frankly I
don't see the benefits of the dedicated account(s). The bot/import tag
on changesets is much more efficient.

Christian

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

Does nobody know about the -Djosm.home=dir parameter you can pass to 
JOSM when starting up? It can be put easily in a shortcut. I've used it 
all the time during imports. When doing integration you only need to 
download the data in another JOSM instance though, but one is 
downloading data all the time when working on OSM.


I find it convenient to have separate accounts, so I can distinguish my 
survey/tracing work from my import work, and the different imports from 
each other. It is also good as a safeguard when data turns out to be 
non-compliant with the OSM license. The requirement to have different 
e-mail accounts is strange and unnecessary, especially if we encourage 
users to use different accounts for imports.


As for having a multitude of accounts, I see no problem with abandoning 
them once the import is complete.


This issue gets way too overblown.

Frank

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

Re: [Talk-ca] Import des limites administratives, municipalités du Québec

[Frank Steggink]

Hi Pierre,

If I recall correctly, Daniel once mentioned that the municipality  
boundaries were to become part of Canvec. I don't know when that would  
eventually happen, but he or someone from NRCan might confirm that. Or  
someone who has connections in the Quebec government might attempt to  
persuade them to attach a better license to the boundaries which have  
currently opened up.


As for removing the incorrect data: did you try to contact the users  
already, and how did they respond? I see no problem if the data is  
clearly wrong, and/or when the users cannot provide clear sources.  
Boundaries aren't something you can see on the ground (except for a  
few individual markers). On the other hand, if both conditions are  
satisfied (quality and source), then you can't just delete existing  
boundaries, without discussing it with the contributing users first.  
This would only be the case on the Isle of Montreal, if I understand  
correctly.


As for centralizing the import: in the Netherlands we have centralized  
it as well. This is giving good results, since it is clear where the  
responsibilities are. Generally once a year the boundaries are  
updated, because adjustments being made are becoming in effect usually  
on January 1st.


Regards,

Frank

Quoting Pierre Béland infosbelas-...@yahoo.fr:

Les données de limites administratives sont déterminantes pour  
assurer une recherche par nom de rue et municipalité dans OSM. Dans  
ce contexte, plusieurs contributeurs du Québec ont commençé à  
importer des données de limites administratives pour les  
municipalités, dans les régions de Québec, Îles-de-la-Madeleine,  
Montréal, Rive-sud, Saint-Jean-sur-Richelieu et Labelle.  De façon  
générale, les sources de données ne sont pas indiquées, et il y a  
parfois des chevauchements (exemple entre Laprairie et  
Saint-Jean-sur-Richelieu. 


En faisant une recherche sur les chemins et relation de limites  
administratives déjà saisis, j'ai constaté que plusieurs limites  
étaient incomplètes et donc inopérantes. J'ai ainsi réparé les  
limites de plusieurs municipalités sur l'Île de Montréal. Les villes  
de banlieu et Montréal s'affichent maintenant correctement et il est  
possible de faire une recherche à partir d'un nom de rue. Sur la  
Rive-sud, des limites saisies par des contributeurs pour Brossard et  
Laprairie sont actuellement incomplètes et inopérantes.


Dans l'ensemble on se retrouve avec des données disparates dont ont  
ne connait pas toujours la provenance. Ces données se chevauchent,  
sont de formes différentes, ce qui rendra de plus en plus difficile  
à assembler ce puzzle si on poursuit dans cette direction.


Au cours des deux dernières semaines, j'ai corrigé plusieurs  
relations définissant les limites de municipalités du côté de  
Labelle et à Montréal. Et j'ai pu vérifier avec les outils  
appropriés que ces limites fonctionnaient correctement.


Cependant, je fais un pas en avant et deux pas de côté. Des  
contributeurs inexpérimentés continuent à importer des données et  
font des manipulations qui rendent les limites déjà importées ou  
corrigées inopérantes. Si on poursuit dans cette direction, on aura  
le torticoli de l'autruche.


C'est pourquoi je propose d'arrêter l'import et la modification des  
limites administratives de municipalités, arrondissements, etc. et  
d'en discuter sur cette liste avant de poursuivre le travail.


La solution qui me semble le plus réaliste est d'effacer si  
nécessaire les limites déjà importées et de ré-importer à partir  
d'une source unique.


Il faut d'abord s'entendre sur les données à utiliser. Il est prévu  
d'obtenir éventuellement les données du gouvernement du Québec. Dans  
l'éventualité où on devra attendre encore une longue période pour  
obtenir ces données, il y a la possibilité d'utiliser les données de  
Statistique Canada. Celles-ci me semblent assez précises.


Pour le travail d'import, il me semble souhaitable de centraliser ce  
travail. Je suis expérimenté dans le traitement de telles données.  
Si les collaborateurs du Québec sont d'accord, je pourrais  me  
charger du travail d'import.



Pierre




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

Re: [OSM-talk-nl] Oude topografische kaarten

[Frank Steggink]

On 12-9-2012 11:51, Paul Smits wrote:
Het zou ook van pas kunnen komen bij humanitaire mapping. Kunnen goede 
aanwijzingen zijn voor wegen in afgelegen gebieden. Bijvoorbeeld 
http://tasks.hotosm.org/job/47
Is er een kans dat deze russische kaarten als WMS beschikbaar komen 
voor bijvoorbeeld JOSM?


Op 12 september 2012 10:38 schreef Maarten Deen md...@xs4all.nl 
mailto:md...@xs4all.nl het volgende:


On 2012-09-12 09:38, Frank Fesevur wrote:

Op 12 september 2012 08:01 heeft Maarten Deen het volgende
geschreven:

Ik weet niet of het hier al een keer genoemd is, maar op
http://www.topomapper.com kun je oude topografische
kaarten zien, en ook
split-screen vergelijken met de huidige situatie in o.a. OSM.


Zijn inderdaad oude kaarten, ik gok jaren 80. Dan pas zie je
hoeveel
er bijvoorbeeld in en om Den Haag is bijgebouwd.


Nog daarvoor. Als ik op
http://www.autosnelwegen.nl/asw/netw/netwerk2.htm kijk en zie dat
de A50 onder Valburg alleen nog als stippellijn is ingetekend en
de A28 vanaf Meppel ontbreekt (daar is wel een andere kaart
gebruikt), en de A50 van Den Bosch naar Heesch er wel al is, dan
is het stand 1975.



In JOSM is het al mogelijk om een WMS-laag of tiles-laag (TMS) toe te 
voegen. In het specifieke geval van topomapper ligt het anders, omdat 
dit gebruik maakt van het tiled WMS protocol. Het request wordt aan 
TileCache gedaan (een applicatie die tiles uit WMS genereert en cachet). 
Hierdoor heb je wel de extent van de tiles nodig zoals in WMS, maar je 
bent gebonden aan de tile-indeling. Ik weet niet of JOSM dit 
ondersteunt. Ik zie geen voorbeeld met TileCache in de lijst met WMS / 
TMS. Misschien kan TileCache ook op een andere manier aangesproken 
worden (dus met x, y en zoom, zoals de OSM tiles), maar ik ben hier niet 
in thuis.


In theorie is het natuurlijk mogelijk om oude kaarten te gebruiken om 
daar informatie vandaan te halen. Je moet dan wel alert zijn op de 
volgende zaken:
* Ouderdom: de meeste topografische kaarten die beschikbaar zijn van 
afgelegen gebieden zijn vaak al tientallen jaren oud. De kans is groot 
dat de situatie is veranderd.
* Kwaliteit: je weet niet zeker wat de kwaliteit van de kaart is. Ik heb 
met Topomapper een stukje in de D.R. Congo vergeleken met OSM. De 
situatie kwam niet erg overeen. In ieder geval was op die plek al OSM 
data beschikbaar.
* Copyright: vaak rust er copyright op kaarten, dus je kunt ze niet 
zomaar gebruiken. In het geval van de Sovjet-kaarten is dat anders, 
omdat de USSR nooit de Conventie van Bern heeft ondertekend. Let op: op 
de meer gedetailleerde West-europese kaarten (1:200.000 en groter) rust 
wel copyright, omdat bewezen is dat de kaarten zijn overgetekend van de 
Ordnance Survey, etc.


Als je oude kaarten hebt, moeten ze wel worden gegeorefereerd, 
geherprojecteerd danwel gewarped en opgeknipt worden in tiles. Hiermee 
houd ik me nu en dan bezig (ter afwisseling van OSM ;) ). Een oud 
voorbeeldje staat nog hier: http://steggink.org/mtbl/. Dit toont zgn. 
Messtischblätter, oude Duitse topografische kaarten. Dit is de werkwijze 
die ik volg:


* Georefereren (toekennen van coördinaten aan bepaalde pixels): dit kost 
een hoop tijd. Er zijn wel kaarten te vinden die MAP-files hebben. Dit 
zijn een soort van georeferentie-bestanden die door OZI Explorer 
gebruikt worden. Met de trial editie kun je wel kaarten georefereren. Je 
moet ten eerste een coördinatenstelsel opgeven. Dit kan een probleem 
zijn voor oude kaarten, omdat daarvoor stelsels werden gebruikt die niet 
door OZI Explorer ondersteund worden. Dan moet je maar wat kiezen wat in 
de buurt ligt. Bijv. voor het vastleggen van latlon WGS84 gebruiken, 
i.p.v. Hayford of Clarke 1866. En voor het vastleggen van XY-coördinaten 
van geprojecteerde stelsels de UTM-velden gebruiken en daar een fake 
zone invullen. In OZI Explorer kun je max. 9 punten opgeven. Die prik je 
in de kaart en je vult dan de bijbehorende coördinaten in (latlon of XY).
* Herprojecteren: ik heb een programmaatje gemaakt die de MAP-files 
uitleest naar een ander formaat. In het begin worden de 
coördinatenstelsels als WKT gedefinieerd. Hier wordt later naar 
verwezen. Ik vervang de WKT-tekst door wat anders, en zoek/vervang de 
verwijzingen. Dan het herprojecteren zelf: ook via een eigen gemaakt 
command line tooltje. Dit leest het configuratiebestand uit. Je kunt 
hierin de bounding box, resolutie en coördinatenstelsel opgeven. Voor 
gebruik in OpenLayers is dat vaak Web Mercator, maar het kan ook RD, 
etc. zijn. Soms kan dit heel lang duren, vooral als je een kaart met een 
hoge resolutie wilt maken. Alle berekeningen (warpen, herprojectie, 
bepalen resolutie) voer ik achter elkaar uit, zodat voor elke pixel in 
het doelbestand ik maar 1x data uit de bronbestanden hoef te lezen. 
Anders gaat dat zwaar ten koste van de kwaliteit, zoals je bijv. op 
Topomapper kunt zien. Je moet hier 

Re: [OSM-talk-nl] Oude topografische kaarten

[Frank Steggink]

On 13-9-2012 11:22, Frank Steggink wrote:

On 12-9-2012 11:51, Paul Smits wrote:
Het zou ook van pas kunnen komen bij humanitaire mapping. Kunnen 
goede aanwijzingen zijn voor wegen in afgelegen gebieden. 
Bijvoorbeeld http://tasks.hotosm.org/job/47
Is er een kans dat deze russische kaarten als WMS beschikbaar komen 
voor bijvoorbeeld JOSM?


Op 12 september 2012 10:38 schreef Maarten Deen md...@xs4all.nl 
mailto:md...@xs4all.nl het volgende:


On 2012-09-12 09:38, Frank Fesevur wrote:

Op 12 september 2012 08:01 heeft Maarten Deen het volgende
geschreven:

Ik weet niet of het hier al een keer genoemd is, maar op
http://www.topomapper.com kun je oude topografische
kaarten zien, en ook
split-screen vergelijken met de huidige situatie in o.a. 
OSM.



Zijn inderdaad oude kaarten, ik gok jaren 80. Dan pas zie je
hoeveel
er bijvoorbeeld in en om Den Haag is bijgebouwd.


Nog daarvoor. Als ik op
http://www.autosnelwegen.nl/asw/netw/netwerk2.htm kijk en zie dat
de A50 onder Valburg alleen nog als stippellijn is ingetekend en
de A28 vanaf Meppel ontbreekt (daar is wel een andere kaart
gebruikt), en de A50 van Den Bosch naar Heesch er wel al is, dan
is het stand 1975.



In JOSM is het al mogelijk om een WMS-laag of tiles-laag (TMS) toe te 
voegen. In het specifieke geval van topomapper ligt het anders, omdat 
dit gebruik maakt van het tiled WMS protocol. Het request wordt aan 
TileCache gedaan (een applicatie die tiles uit WMS genereert en 
cachet). Hierdoor heb je wel de extent van de tiles nodig zoals in 
WMS, maar je bent gebonden aan de tile-indeling. Ik weet niet of JOSM 
dit ondersteunt. Ik zie geen voorbeeld met TileCache in de lijst met 
WMS / TMS. Misschien kan TileCache ook op een andere manier 
aangesproken worden (dus met x, y en zoom, zoals de OSM tiles), maar 
ik ben hier niet in thuis.


In theorie is het natuurlijk mogelijk om oude kaarten te gebruiken om 
daar informatie vandaan te halen. Je moet dan wel alert zijn op de 
volgende zaken:
* Ouderdom: de meeste topografische kaarten die beschikbaar zijn van 
afgelegen gebieden zijn vaak al tientallen jaren oud. De kans is groot 
dat de situatie is veranderd.
* Kwaliteit: je weet niet zeker wat de kwaliteit van de kaart is. Ik 
heb met Topomapper een stukje in de D.R. Congo vergeleken met OSM. De 
situatie kwam niet erg overeen. In ieder geval was op die plek al OSM 
data beschikbaar.
* Copyright: vaak rust er copyright op kaarten, dus je kunt ze niet 
zomaar gebruiken. In het geval van de Sovjet-kaarten is dat anders, 
omdat de USSR nooit de Conventie van Bern heeft ondertekend. Let op: 
op de meer gedetailleerde West-europese kaarten (1:200.000 en groter) 
rust wel copyright, omdat bewezen is dat de kaarten zijn overgetekend 
van de Ordnance Survey, etc.


Als je oude kaarten hebt, moeten ze wel worden gegeorefereerd, 
geherprojecteerd danwel gewarped en opgeknipt worden in tiles. Hiermee 
houd ik me nu en dan bezig (ter afwisseling van OSM ;) ). Een oud 
voorbeeldje staat nog hier: http://steggink.org/mtbl/. Dit toont zgn. 
Messtischblätter, oude Duitse topografische kaarten. Dit is de 
werkwijze die ik volg:


* Georefereren (toekennen van coördinaten aan bepaalde pixels): dit 
kost een hoop tijd. Er zijn wel kaarten te vinden die MAP-files 
hebben. Dit zijn een soort van georeferentie-bestanden die door OZI 
Explorer gebruikt worden. Met de trial editie kun je wel kaarten 
georefereren. Je moet ten eerste een coördinatenstelsel opgeven. Dit 
kan een probleem zijn voor oude kaarten, omdat daarvoor stelsels 
werden gebruikt die niet door OZI Explorer ondersteund worden. Dan 
moet je maar wat kiezen wat in de buurt ligt. Bijv. voor het 
vastleggen van latlon WGS84 gebruiken, i.p.v. Hayford of Clarke 1866. 
En voor het vastleggen van XY-coördinaten van geprojecteerde stelsels 
de UTM-velden gebruiken en daar een fake zone invullen. In OZI 
Explorer kun je max. 9 punten opgeven. Die prik je in de kaart en je 
vult dan de bijbehorende coördinaten in (latlon of XY).
* Herprojecteren: ik heb een programmaatje gemaakt die de MAP-files 
uitleest naar een ander formaat. In het begin worden de 
coördinatenstelsels als WKT gedefinieerd. Hier wordt later naar 
verwezen. Ik vervang de WKT-tekst door wat anders, en zoek/vervang de 
verwijzingen. Dan het herprojecteren zelf: ook via een eigen gemaakt 
command line tooltje. Dit leest het configuratiebestand uit. Je kunt 
hierin de bounding box, resolutie en coördinatenstelsel opgeven. Voor 
gebruik in OpenLayers is dat vaak Web Mercator, maar het kan ook RD, 
etc. zijn. Soms kan dit heel lang duren, vooral als je een kaart met 
een hoge resolutie wilt maken. Alle berekeningen (warpen, 
herprojectie, bepalen resolutie) voer ik achter elkaar uit, zodat voor 
elke pixel in het doelbestand ik maar 1x data uit de bronbestanden 
hoef te lezen. Anders gaat dat zwaar ten koste van de kwaliteit, zoals 
je

Re: [OSM-talk-nl] Nieuwe maximumsnelheden op snelwegen

[Frank Steggink]

On 4-9-2012 9:56, Maarten Deen wrote:

On 2012-09-03 20:42, Colin Smale wrote:

Het heeft onze regering behaagd om de snelheidslimieten op 's lands
autosnelwegen aan te passen. Helaas is het er niet makkelijker op
geworden; vroeger had je 120 met een paar uitzonderingen, tegenwoordig
moet je rekening houden met verschillende scenario's, elk met eigen
bebording.

Met het volgende ben ik me ervan bewust dat ik het risico loop om
gelyncht te worden wegens het willen standardiseren van de tagging...

Het lijkt mij zinvol om enige gelijkvormigheid in de tagging na te
streven. De drie scenario's zijn afhankelijk van tijdstip en het al
dan niet open zijn van een eventuele spitsstrook. Laat ik even de
discussie aanzwengelen met het volgende voorstel, waarbij ik gebruik
maak van het voorstel voor uitgebreide toegangskenmerken zoals
beschreven op de volgende pagina:

http://wiki.openstreetmap.org/wiki/Proposed_features/Extended_conditions_for_access_tags 



1) Vaste maximumsnelheid
maxspeed=X
2) 130 bij nacht, 120/100 overdag
maxspeed=130
maxspeed:(06:00-19:00)=120
3) 130 bij nacht, 120/100 overdag bij gesloten spitsstrook; 100 bij
geopende spitsstrook
maxspeed=130
maxspeed:(06:00-19:00)=120
maxspeed:spitsstrook=100

De snelheid bij geopende spitsstrook is een probleem omdat de tijden
niet voorspelbaar zijn. Wie heeft hiervoor een oplossing?


In de geest van 
http://wiki.openstreetmap.org/wiki/Proposed_features/Conditional_restrictions:

maxspeed=130
maxspeed:conditional=100 @ open spitsstrook

Maar ik vraag me af of je dat soort dingen echt wil taggen. Dit is 
alleen nuttig voor navigatiesystemen en die weten ook niet of een 
spitsstrook open is of niet en kunnen die snelheid dus niet tonen.


Om er nog niet van te spreken dat het er alleen maar toe leidt dat 
mensen nog minder op borden gaan kijken en het dus een promotie van 
slecht weggedrag is. Laat duidelijk zijn dat ik voor een levenslang 
rijverbod pleit voor al dat soort wegmisbruikers die in dat soort 
berichten staan van auto rijdt rivier in omdat de navigatie dat zegt.


Krijgen we trouwens wel een variabele maximumsnelheid.openstreetmap.nl 
kaart? Dus eentje die van 6 tot 19 een andere snelheid toont dan van 
19 tot 6? ;)


Maarten


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

Dan wil ik ook versies voor inhaalverboden voor vrachtauto's, voor het 
geval ik mijn vrachtwagenrijbewijs haal. Verder een voor slecht weer 
(snelheidsrestricties bij nat wegdek), etc.


Of op borden kijken helpt, weet ik niet. Op de parallelbaan bij 
knooppunt Hoevelaken op de A1 van Hengelo naar Amsterdam viel me het 
volgende op.

1. Snelheidsrestrictie 100 km/u
2. Snelheidsrestrictie 70 km/u bij nat wegdek
3. 120 km/u (nieuw bord) - staat echt op de parallelbaan
4. Einde snelheidsrestrictie 70 km/u bij nat wegdek
5. 100 km/u, nadat de baan vanaf de A28 vanuit Zwolle is bijgevoegd
Na samenvoegen parallelbaan op hoofdrijbaan: 120 km/u (nieuw bord), 
volgens mij nog met onderbord 6-19 uur...

Dit alles is over een traject van zo'n 2 km.

Wat is nu de snelheid bij droog weer tussen bord 3 en 5?

Ik heb me al eerder afgevraagd hoe nat een wegdek moet zijn voor sommige 
extra snelheidsbeperkingen. Is het als het een beetje vochtig is, of als 
er water uitspat als je er overheen rijdt, of moet er blank water op staan?


Alhoewel ik zelf wel van een beetje doorrijden houd, vind ik dit gewoon 
een verkiezingsstunt. Ook al heeft Melanie dit aangekondigd voordat ome 
Geert de stekker eruit trak... (Weet ik niet zeker, het was rond 
dezelfde tijd.) De overheid zit het land dood te gooien met allerlei 
regeltjes. Er kan veel beter een beroep worden gedaan op het gezonde 
verstand van automobilisten. En voor degenen die dat niet hebben: die 
horen niet op de weg thuis.


Frank

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

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

To be clear, I haven't done full imports. I haven't imported roads or  
water, in order not to duplicate features. Water was previously  
imported by Yan Morin in 2009 (Geobase NHN data), and roads were  
either drawn by users, or a result of the Geobase NRN import. In case  
of water, I only have added a few streams which were missing.


One of the issues is that certain ways are duplicated, because of  
multipolygon holes. That's why I'm gauging your thoughts about it,  
because I don't see that as an issue myself. Perhaps we could come up  
with a proper way how to deal with it.


Another issue which is bothering myself for a long time is the fact  
that Geobase NRN roads don't have road names in Quebec. Road names are  
present in Canvec now. Replacing them manually is a tedious task. I  
have thought about it for quite some time, but I can't come up with a  
better procedure, offering the same quality. I also have considered  
writing tools for them. Any (semi-)automated tools have an inherent  
risk, particularly because it's hard to guarantee they will still do a  
proper job, given the diversity in OSM data.


Frank


Quoting Béland Pierre bela...@yahoo.fr:


David and Paul, do you think this was the problem with these imports???
 
Pierre





De : David E. Nelson denelso...@yahoo.ca
À : Paul Norman penor...@mac.com; talk-ca@openstreetmap.org  
talk-ca@openstreetmap.org

Envoyé le : Mercredi 22 août 2012 21h59
Objet : Re: [Talk-ca] Canvec import issues


Yeah, don't just do blanket imports.  Just import whatever data  
OSM *does not* have.




- David E. Nelson


From: Paul Norman penor...@mac.com
To: 'Daniel Begin' jfd...@hotmail.com; 'Pierre Béland'  
infosbelas-...@yahoo.fr; talk-ca@openstreetmap.org

Sent: Wednesday, August 22, 2012 6:52:12 PM
Subject: Re: [Talk-ca] Canvec import issues


I see the problem as being the importing of everything as being  
the problem, not the geometric model :)

 
From:Daniel Begin [mailto:jfd...@hotmail.com]
Sent: Tuesday, August 21, 2012 1:49 PM
To: 'Pierre Béland'; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
Bonjour Pierre,
 
The Canvec Geometric Model is explained in the following OSM wiki page ...
http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model
 
The model was adopted after discussions with the community. The  
model was designed to simplify the import of a selection of  
features by the  contributors, instead of imposing import the  
entire contents by them.

 
However, history now shows that the community usually imports the  
entire content.

Compromises always bring pros and cons.!-)
 
Best regards,
Daniel
 



From:Pierre Béland [mailto:infosbelas-...@yahoo.fr]
Sent: August-21-12 16:04
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Canvec import issues
 
 
I didn't do Canvec imports too much. Looking at various lakes in  
wooded areas,  I now realize that Canvec imports are often  
(always?) duplicating lakes. I do'nt know what was the reason to  
create these duplicate ways in the Canvec import file.  Should we  
duplicate the lakes to apply a inner role in the relation? Is this  
a reason for that? Or could we instead simply use the existing  
lake with a inner role in the wooded area polygon relation?

 
Pierre



De :Frank Steggink stegg...@steggink.org
À : talk-ca@openstreetmap.org
Envoyé le : Mardi 21 août 2012 13h32
Objet : [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat  
hostile tone) after the Canvec import I've done over the weekend  
northwest of Montréal. He was not really happy with the way how  
the import has handled. The way the Canvec data is currently  
provided, leaves some room for improvement. I'm not sure if all  
his issues have been discussed in the past (since I haven't  
followed all Canvec discussions, especially in the beginning), but  
I could see some merit in some of the point.


Some examples he provided come from the Mt. Tremblant area [1].  
Note that the lakes (and most of the streams) were imported  
previously by someone else, based on NHN data, but the same issue  
plays with the Canvec data itself. (This left me to the task to  
leave the Canvec lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He
mentioned that a large part of the ways are duplicated. The outer  
boundary of the wooded area is a separate polygon from the lake  
itself.  However, Lac Gauthier on the right is a different case.  
This lake has been cut out from the woods, and I left the inner  
boundary intact. JOSM is not complaining about this. Since dealing  
with multipolygons remains a sticky issue, I have not done that. I  
think it would be better to take care of these issues with some  
tool. Although using a tool is considered dangerously (and  
rightfully so!), dealing

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Pierre,

Regarding the duplicated ways, I'll get to that by replying Daniel's mail.
Regarding the toponyms, the user I'm having contact with is refering to 
Sûreté de Québec, for example this page: 
http://www.sq.gouv.qc.ca/poste-mrc-des-pays-d-en-haut/organisation/carte-detaillee-pays-haut.pdf


I don't know if both data sources can be considered public domain.  As 
far as I know, the guidelines for the federal government don't apply to 
provincial and local governments. See also the discussion about 
importing data from the Ville de Québec.


Frank

On 21-8-2012 20:59, Pierre Béland wrote:

Frank

The NEtiquette is always important in these circumstances. Lets hope 
this mapper will learn how to deal with the community.


I Looked rapidly at the data.I see a multipolygon natural=wood 
Relation : 2362646 that contains 72 members. I see that you imported a 
wooded area way=176778952 that is part of this relation. It also 
overlaps for the 2/3 with a lake way=57988179. I see similar situation 
with way 176778559.  Unless I missed something, my understanding is 
that you should simply remove ways 176778952 and 176778559 and any 
others that duplicate what is already defined  by relation 2362646.


The Quebec toponyms may sometime be more complete then Canvec. But not 
all the lakes have names and it is not easy to find infos for a 
specific area. You can  search for a specific name at 
http://www.toponymie.gouv.qc.ca/.
See 
http://www.toponymie.gouv.qc.ca/ct/ToposWeb/recherche.aspx?s=lac-ouimetx=0y=0 
for lac Ouimet results

Pierre


*De :* Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues

Hi,

Today I was contacted by someone inquiring (with a somewhat
hostile tone) after the Canvec import I've done over the weekend
northwest of Montréal. He was not really happy with the way how
the import has handled. The way the Canvec data is currently
provided, leaves some room for improvement. I'm not sure if all
his issues have been discussed in the past (since I haven't
followed all Canvec discussions, especially in the beginning), but
I could see some merit in some of the point.

Some examples he provided come from the Mt. Tremblant area [1].
Note that the lakes (and most of the streams) were imported
previously by someone else, based on NHN data, but the same issue
plays with the Canvec data itself. (This left me to the task to
leave the Canvec lakes out of the upload, as well as most streams.)

On the left you see Lac Ouimet. He mentioned that a large part of
the ways are duplicated. The outer boundary of the wooded area is
a separate polygon from the lake itself.  However, Lac Gauthier on
the right is a different case. This lake has been cut out from
the woods, and I left the inner boundary intact. JOSM is not
complaining about this. Since dealing with multipolygons remains a
sticky issue, I have not done that. I think it would be better to
take care of these issues with some tool. Although using a tool is
considered dangerously (and rightfully so!), dealing with
multipolygons is prone to errors as well.

Another issue is that some lakes do not have names, but contain a
separate node (not part of any of the ways) with natural=water and
name=* tags. I can only assume that this comes from the source
data. In many cases it is hard to determine the extent of the
lake, since it can gradually taper into a river. This was not
mentioned directly by the user, but I thought he was referring to
this.

His issue turned out to be somewhat different. There is a place
node near Lac Gauthier, with the same name. I explained to this
that this must be the name of a hamlet. The non-official tag
place=locality is probably due to this confusion. This name is
also visible on the original topo map [2].

Furthermore he noticed that I have duplicated his address nodes
and ways. This was an omission, so I have corrected this. I scan
the existing data in order not to duplicate existing features. Of
course this is prone to errors as well, especially in a large area
which is void of address nodes and ways, except for two ways
around a lake...

I'm not asking anyone for solutions. I can easily think about
them as well, but that doesn't make the problem go away. Thinking
about the solution is the easiest part, but working it out and
implementing it is much more difficult. It is more than simply
typing in some code and then run it over the data. Instead of
doing that, I have tried to explain him something about the hybrid
data model OSM is using (not purely geographical, but also not
purely topological). And of course there is also the gap between

Re: [Talk-ca] Canvec import issues

[Frank Steggink]

Hi Daniel, Pierre,

It is possible to reuse ways in the OSM datamodel, as you know. It is 
also possible to do this, while having to make extracts later. For 
example, when you only want to select lakes, you should do the following 
in JOSM:

* Select natural=water, replace selection
* Select child selected, add to selection
This way you have all lakes, including multipolygon ones with islands. 
Note that the islands could have tags applied on them as well. You can 
deal with them after you've copied the data to another layer.


Anyways, unfortunately it is not possible to have ways being reused 
easily with JOSM. At least not with standard JOSM or the Validator tool. 
Perhaps there is a plug-in. I haven't looked into that. However, if this 
functionality were to be implemented, it could easily open a new can of 
worms. Sometimes it also happens that functionality is revised (wholly 
or partially). For example, that is the case with unclosed ways. Now 
it isn't possible to merge duplicate nodes with the Validator tool. With 
all the crossing address interpolation ways and streams, I need to merge 
them manually tens of times per sheet, sometimes even up to a hundred 
times. (Probably not much more, because sheets are being split up 
farther in crowded, residential areas.)


History also shows that everyone has his own standards, even amongst all 
the people who have imported Canvec data. However, that is an entirely 
different discussion...


Frank

On 21-8-2012 22:49, Daniel Begin wrote:


Bonjour Pierre,

The Canvec Geometric Model is explained in the following OSM wiki page ...

http://wiki.openstreetmap.org/wiki/CanVec:_Geometric_Model

The model was adopted after discussions with the community. The model 
was designed to simplify the import of a selection of features by the  
contributors, instead of imposing import the entire contents by them.


However, history now shows that the community usually imports the 
entire content.


Compromises always bring pros and cons.!-)

Best regards,

Daniel



*From:*Pierre Béland [mailto:infosbelas-...@yahoo.fr]
*Sent:* August-21-12 16:04
*To:* talk-ca@openstreetmap.org
*Subject:* Re: [Talk-ca] Canvec import issues

I didn't do Canvec imports too much. Looking at various lakes in 
wooded areas,  I now realize that Canvec imports are often (always?) 
duplicating lakes. I do'nt know what was the reason to create these 
duplicate ways in the Canvec import file.  Should we duplicate the 
lakes to apply a inner role in the relation? Is this a reason for 
that? Or could we instead simply use the existing lake with a inner 
role in the wooded area polygon relation?


*/Pierre/**//*



*De :*Frank Steggink stegg...@steggink.org
*À :* talk-ca@openstreetmap.org
*Envoyé le :* Mardi 21 août 2012 13h32
*Objet :* [Talk-ca] Canvec import issues


Hi,

Today I was contacted by someone inquiring (with a somewhat hostile 
tone) after the Canvec import I've done over the weekend northwest of 
Montréal. He was not really happy with the way how the import has 
handled. The way the Canvec data is currently provided, leaves some 
room for improvement. I'm not sure if all his issues have been 
discussed in the past (since I haven't followed all Canvec 
discussions, especially in the beginning), but I could see some merit 
in some of the point.


Some examples he provided come from the Mt. Tremblant area [1]. Note 
that the lakes (and most of the streams) were imported previously by 
someone else, based on NHN data, but the same issue plays with the 
Canvec data itself. (This left me to the task to leave the Canvec 
lakes out of the upload, as well as most streams.)


On the left you see Lac Ouimet. He mentioned that a large part of the 
ways are duplicated. The outer boundary of the wooded area is a 
separate polygon from the lake itself.  However, Lac Gauthier on the 
right is a different case. This lake has been cut out from the 
woods, and I left the inner boundary intact. JOSM is not complaining 
about this. Since dealing with multipolygons remains a sticky issue, I 
have not done that. I think it would be better to take care of these 
issues with some tool. Although using a tool is considered 
dangerously (and rightfully so!), dealing with multipolygons is 
prone to errors as well.


Another issue is that some lakes do not have names, but contain a 
separate node (not part of any of the ways) with natural=water and 
name=* tags. I can only assume that this comes from the source data. 
In many cases it is hard to determine the extent of the lake, since it 
can gradually taper into a river. This was not mentioned directly by 
the user, but I thought he was referring to this.


His issue turned out to be somewhat different. There is a place node 
near Lac Gauthier, with the same name. I explained to this that this 
must be the name

Re: [OSM-talk-nl] openkvk bedrijfsnamen / geolocaties bulkimporteren?

[Frank Steggink]

Ctrl+C en dan Shift+Ctrl+V (paste tags only). Als dat teveel goede tags 
overschrijft, ga dan naar http://josm.openstreetmap.de/newticket


Frank

On 3-8-2012 23:43, Robert Elsenaar wrote:
Voor een dergelijke osm file heb ik ook meer dan belangstelling. Voor 
de mergel activiteiten zou eigenlijk een mooie functie in JOSM moeten 
zijn.




Met vriendelijke groeten
Robert Elsenaar


Frank Steggink stegg...@steggink.org schreef:


Quoting Stefan de Konink ste...@konink.de:

 Dit weekend zal er weer een update van openkvk plaatsvinden. Al eerder
 hebben we veel adressen kunnen koppelen met de BAG. Daarmee zijn
 geolocaties eenvoudig te onttrekken. Zou er belangstelling zijn om
 automatisch een PoI import te doen met data uit openkvk, waar
 beschikbaar inclusief amenity?

 Stefan

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

Automatisch importeren lijkt me sowieso niet wenselijk, onder meer
vanwege het risico op duplicates.

Wat je beter zou kunnen doen is OSM-files beschikbaar stellen met deze
amenities, uitgesplitst naar 4-cijferig postcodegebied. Dan kunnen
deze handmatig gemerged worden met de al aanwezige info. Dit gaat jouw
wel lukken :) Hiervoor heb ik wel belangstelling.

Ik denk dat het verstandig is om eerst de mapping van OpenKVK naar OSM
apart te bespreken. Welk voorstel heb je hiervoor klaarliggen?

Groeten,

Frank

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



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



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

Re: [OSM-talk-nl] openkvk bedrijfsnamen / geolocaties bulkimporteren?

[Frank Steggink]

Quoting Stefan de Konink ste...@konink.de:


Dit weekend zal er weer een update van openkvk plaatsvinden. Al eerder
hebben we veel adressen kunnen koppelen met de BAG. Daarmee zijn
geolocaties eenvoudig te onttrekken. Zou er belangstelling zijn om
automatisch een PoI import te doen met data uit openkvk, waar
beschikbaar inclusief amenity?

Stefan

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


Automatisch importeren lijkt me sowieso niet wenselijk, onder meer  
vanwege het risico op duplicates.


Wat je beter zou kunnen doen is OSM-files beschikbaar stellen met deze  
amenities, uitgesplitst naar 4-cijferig postcodegebied. Dan kunnen  
deze handmatig gemerged worden met de al aanwezige info. Dit gaat jouw  
wel lukken :) Hiervoor heb ik wel belangstelling.


Ik denk dat het verstandig is om eerst de mapping van OpenKVK naar OSM  
apart te bespreken. Welk voorstel heb je hiervoor klaarliggen?


Groeten,

Frank

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

Re: [Talk-ca] opendata datasets

[Frank Steggink]

Hi Bruno,

Although there are many more European datasets listed in the catalogue, 
many of them are very small, covering only a city, province, etc. In 
North America there are a few, but very large datasets which have been 
imported or are in the process of being imported. Examples in the US are 
the Tiger dataset (imported in 2007/2008) and the NHD dataset 
(waterways). In Canada there are of course Canvec and previously 
Geobase. So, the amount of imported data in North America is larger than 
in Europe. And of course, in Europe the situation differs by country. 
For instance, in the Netherlands there is a lot of imported data as well 
(roads, landuse, buildings), as well as in France (landuse, buildings). 
On the other hand, Germany and the UK have relatively small amounts of 
imported data.


Referring back to your earlier question: there is open data, and there 
is open data. The degree of openness is varying. The most open 
datasets are the public domain datasets (PD, CC-0). Federal Canadian and 
US datasets are examples of that, like Canvec. Any license attached to 
the open data in fact restricts its usage. Each restriction needs to 
be evaluated carefully. Before importing any open dataset, one must 
make sure that those restrictions can be honored to.  So, a license like 
CC-BY-SA imposes that the author should be attributed (BY-clause), and 
that the data can only be shared under a similar license (SA-clause). It 
is difficult for OSM to do the attribution part, because the objects 
themselves can easily be edited. Sharing alike is out of the question 
with the ODbL, as this is a completely different license (although with 
similar clausess). And of course other guidelines are that it should not 
replace user-contributed data (unless widely agreed upon), that it is 
maintainable, etc.


Of course there is a way out when the license seems to be 
incompatible, namely contacting the author, and ask if they are prepared 
to grant you a license to have it incorporated under the OSM-license 
(ODbL). They own the copyright to the data, so they have the authority 
to decide on that. You can see the (too restrictive) license as an 
invitation for negotiations for the data owner to open up a bit more ;) 
This is the way how a lot of the listed datasets in the catalog ended up 
being imported in OSM. Of course, when you receive authorization, it 
should be listed on the wiki page describing the import as well, so it 
can be referred to later as well. This is also the place where the 
original author can be attributed to.


When it comes to the question whether imported data is good or not: 
there is no clear cut answer to it. Sometimes it can be good, but all 
too often it ends up badly. Those kinds of imports are the main reason 
why imports in general have not a good name. See for example 
http://worstofosm.tumblr.com/ . Have a laugh about it :) BUT, if you 
intend to import data, make sure your import doesn't end up at that place!


I hope this clears up some of your concerns.

Cheers,

Frank

On 31-7-2012 19:04, Bruno Remy wrote:



2012/7/31 Richard Weait rich...@weait.com mailto:rich...@weait.com

2012/7/31 Bruno Remy bremy.qc...@gmail.com
mailto:bremy.qc...@gmail.com:
 Thanks Richard for your considerations.

 While reading your comments, I'm carried to believe that :
 wheras Canadian municipalities produce scrap data versus
europenan ones

I don't believe this.

 Canadian citizen are less confident in theyr gouvernement's IT
stuff than
 European does.

I don't believe this either.

OSM in Europe has grown more effectively than in North America,
because there are more _OSM contributors_ in Europe.  Not because
there is more Open Data in Europe.  Much less data has been imported
in Europe than in North America.


I totally agree with you about the number of contributors in Europe 
versus in North America.
But I don't see clear correlation between number of contributors and 
number of data (ways, nodes.) because only 38% of contributors 
doesn't edit data, and only 19% make recuring edits.

(source = http://www.mdpi.com/2220-9964/1/2/146)

In the facts, most of main ways (coastlines, cities, roads, 
administrative boundaries) provides from Datasets mentionned here  
(http://wiki.openstreetmap.org/wiki/Import/Catalogue) But if you take 
the time to analyse this import catalog 
http://wiki.openstreetmap.org/wiki/Import/Catalogue, it's clear that 
*mostly all datasets are provided by European* organisations (*only 
14%* from North-America).

So, YES Europe has more date but MOSTLY because of import of dataset.

*For sure, contributors maintained and enhanced acuracy of these 
data*... but nobody can imagine that every single house and every 
single road has been handmade by volunteered geographic information 
(VGI):



In this context, if I introduce new mappers to OpenStreetMap as you 
said, *by telling them drawing manualy 

Re: [Talk-ca] opendata datasets

[Frank Steggink]

On 31-7-2012 15:09, Bruno Remy wrote:

Does this Quebec city Opendata Licence compatible with OSM? (Y/N) And Why?
http://donnees.ville.quebec.qc.ca/licence.aspx


I'll give this a try with my understanding of French, so be aware... ;) 
I'll only pay attention to the clauses which might be an issue for an 
eventual import in OSM.



2. Droits de propriété intellectuelle

2.1 La Ville conserve tous les droits de propriété intellectuelle à 
l’égard des Données et vous reconnaissez que vous n’avez aucun droit 
de propriété intellectuelle, incluant les droits d’auteur, sur les 
ensembles de Données. Si vous rendez les ensembles de Données 
accessibles à un tiers en octroyant une sous-licence, en format 
original ou modifié, vous devez lui fournir une copie des présentes 
conditions d’utilisation pour vous assurer qu’il respecte les 
conditions d’utilisation, sans les modifier.
This means that OSM should inform all third parties about this license. 
How can this be done? And this should only apply to extracts which cover 
parts of Quebec City, and only when it includes City data. This is 
difficult with the current infrastructure.



3. Indication de la source des ensembles de Données

3.1 Vous devez inclure et maintenir l'avis suivant sur toute 
reproduction des ensembles de Données :


« Contient des données reproduites et distribuées « telles quelles » 
avec la permission de la Ville de Québec. ».

Same issue as 2.1



3.2 Si vous développez une application qui contient, en tout ou en 
partie, des Données de la Ville, vous devez inclure l'avis suivant sur 
cette application :


« Cette application contient des données ouvertes accordées sous 
licence « telles quelles » aux termes d’une licence d'utilisation des 
données de la Ville de Québec. L'octroi de la licence ne constitue pas 
une approbation de l’application par la Ville de Québec. »


ou tout autre avis approuvé au préalable par écrit par la Ville.
Same issue as 2.1 + we can't control any applications users of the OSM 
dataset apply. For reasons like this the import catalog has been set up, 
including the pages describing each import.



4. Modifications des ensembles de Données ou des conditions d’utilisation

La Ville peut apporter en tout temps des modifications concernant les 
ensembles de Données ou les conditions d’utilisation. Le cas échéant, 
un avis de modification peut être publié sur la page d’accueil des 
ensembles de Données ou sur la présente page. Sauf indication 
contraire, toute modification entre en vigueur dès la publication de 
l’avis.
This means that the City government can change the license. Although 
this only applies after data which has been obtained from their site 
after a certain date, OSM should state that the used data has been 
obtained before that particular date. To avoid any misunderstandings, 
special permission would be much better.


5.2.1 la Ville ne peut assurer qu’aucun tiers ne détient de droit 
d’auteur, droit moral ou autre type de droit de propriété 
intellectuelle à l’égard des ensembles de Données;
Whoops! What happens if a third party claims copyright about imported 
data? Even with written permission from the City, this remains an issue.



7. Annulation de la licence en cas de non-respect

La Ville se réserve le droit de résilier ou de suspendre votre licence 
d’utilisation aux ensembles de Données sans avis ni délai si elle 
estime que vous ne respectez pas les conditions d’utilisation, que 
vous contrevenez à la loi ou que vous portez préjudice à autrui. Le 
cas échéant, vous ne serez plus autorisé à utiliser ni à reproduire 
les ensembles de Données. Vous demeurez toutefois lié par toute 
entente de sous-licence que vous avez conclue dans l'exercice de vos 
droits aux termes de la présente licence avant la résiliation.
This means we can't just import the data under their own license, 
because we have no guarantees that the City thinks we respect their 
license terms.



8. Lois et juridiction applicables

La présente Entente et les droits des parties sont interprétés, 
appliqués et régis en conformité avec les lois en vigueur de la 
province du Québec et les lois du Canada, le cas échéant. Tout litige 
relatif à l’interprétation, l’application ou l’exécution de la 
présente licence ou de l’utilisation des Données devra être tranché 
par les tribunaux compétents siégeant dans la province de Québec.
OSM is an international project, so this might be an issue, albeit 
theoretical, since most users of Québec data (city/province) will likely 
be from Canada.



Conclusion: based on their license terms, I would say that this data 
cannot be imported into OSM, without an additional license. Clause 5.2.1 
remains a problem though, and I can imagine that this could be a reason 
not to grant special permission to OSM at all. On the other hand, this 
can (should!) be addressed in an eventual request, explaining the role 
of the OSMF and the Data Working Group.


Regards,

Frank

Re: [Talk-ca] Noms autochtones

[Frank Steggink]

Quoting Fabian Rodriguez magic...@member.fsf.org:


On 07/17/2012 06:38 PM, Bruno Remy wrote:


bonjour,

Avez-vous déjà pensé à l'indication des lieux autochtones? Il y en a
beaucoup à travers le Canada et comment les intégrer à nos
cartographies à tendance francophones ou anglophones dans nos
différentes provinces?

Bruno Remy



Pour quelle langue(s)? Je suppose que tu penses surtout à l'attribut
name? Il a une extension, par exemple pour un parc qui aurait un nom en
inuktitut ou mohawk tu utiliserais le code ISO-639-1.2 correspondant:
name:iu=XX
name:moh=XX
sans oublier
name:en
name:fr

Cette page l'explique bien, peut-être bénéficierait-elle d'une section
pour le Canada:
http://wiki.openstreetmap.org/wiki/Bilingual_street_names

A+

Fabian Rodriguez
http://openstreetmap.magicfab.ca



Salut,

Au Village-des-Hurons à Québec j'ai ajouté des noms huron (Wyandot)  
aussi. Voir ici: http://osm.org/go/cKZkGCh9L-- . J'ai utilisé le code  
ISO 'wya' pour les noms autochtones.


Par example: http://www.openstreetmap.org/browse/way/33724586

Frank


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

Re: [OSM-talk-nl] Maandelijkse geo-borrels in Utrecht

[Frank Steggink]

Hoi Robert,

Iemand van OSGeo.nl heeft voorgesteld om de borrel in een café bij 
station Driebergen-Zeist te houden. Wellicht beter bereikbaar met je 
heilige koe. (Een stalen ros is volgens mij gewoon een fiets ;))

Dit omdat er ook geluiden waren om in/rond Wageningen iets te organiseren.

Anyways, er is nog niks vastgelegd. Utrecht was gewoon een voorstel, 
omdat het centraal ligt en ik er woon. Tegen de tijd dat het zover is, 
hakken we de knoop wel door :)


Frank

On 29-6-2012 12:11, Robert Elsenaar wrote:

Frank,
Fijn je weer actief terug te zien. Zo heb ik je leren kennen en zo heb 
ik je leren waarderen.


Wat ik op amsterdam tegen heb is dat je er onmogelijk per auto kunt 
komen. Wil je mij in Utrecht regelmatig tegen komen, ga dan niet in 
het centrum zitten, of zorg in iedetgeval dat er een betaalbaar plekje 
voor mijn stalen ros aanwezig is.


Ik hoop tot snel.

Met vriendelijke groeten
Robert Elsenaar



Frank Steggink stegg...@steggink.org schreef:


Hoi,

Ik wil graag maandelijks een geo-borrel organiseren in Utrecht. Deze is
bedoeld om gezellig met elkaar te praten over open data en open source
software op geo-gebied. Uiteraard is OSM een van de belangrijkste topics
;) De borrel is er op gericht om open (source/data) geo-kennis in
Midden-Nederland bij elkaar te brengen. Dus als je hier woont en/of
werkt, of als je het geen bezwaar vindt om van verder weg langs te
komen, dan ben je van harte uitgenodigd!

Het tijdstip is de laatste donderdag van de maand, zodat we niet in het
vaarwater zitten van de Amsterdamse Mappersborrel. Ik denk dat 19:00 uur
een goed moment is om open te gaan. Eventueel kunnen we eerst ergens
eten, want iedereen komt terug van een lange werk-/studiedag. De locatie
moeten we nog bepalen, dus als je een goede suggestie hebt, met name
waar de muziek op donderdagavond niet te luid staat, laat het me dan
s.v.p. weten. Een vaste locatie is wel zo praktisch, maar uiteraard
kunnen we ook wel eens 'verhuizen'.

De eerste borrel wil ik op donderdag 30 augustus organiseren, i.v.m. de
vakantie. Eventueel kunnen we een proefdraaisessie organiseren op 26
juli a.s. Via de osgeo.nl meetup groep heb ik een meeting opgezet voor
de 30e augustus: http://www.meetup.com/OSGeoNL/events/71140362/. Laat
s.v.p. daar weten of je komt. Ik ga ook de wiki-pagina [1]
http://wiki.openstreetmap.org/wiki/Utrecht op osm.org van Utrecht
bijwerken, zodat je je ook daar kunt opgeven en niet een meetup-account
hoeft aan te maken.

De aanleiding van deze borrel is een oproep van Just van den Broecke op
de zeer geslaagde eerste OSGeo.nl meeting (nederlandstalige open source
geo-organisatie) in Velp om meer regionale meetings te houden. De
OSGeo.nl conferentie was bijzonder interessant. OSM kwam regelmatig aan
bod. Ook ons aller Henk hield een presentatie en Milo van der Linden
heeft een workshop OSM gehouden. Het mooiste om te horen vond ik een
presentatie van iemand van de veiligheidsregio Fryslân, waarin hij
vertelde dat zij OSM als basislaag gebruikten, maar als de
hulpmedewerkers (o.a. brandweermensen) fouten constateerden in de data,
ze deze ook gingen aanpassen, zodat de volgende keer de kaart correct
is! Kijk, dit soort toepassingen, met feedback van gebruikers van onze
data, maakt OSM zo'n fantastisch project :)

Groeten,

Frank


[1] http://wiki.openstreetmap.org/wiki/Utrecht


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



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




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

Re: [Talk-ca] How did you start in OSM?

[Frank Steggink]

On 6-7-2012 13:27, Richard Weait wrote:

Do you remember how you first heard of OSM, or first got mapping?

I think the first sign I saw of OSM was in a post on slashdot in June 2006.

Share your story.  How'd you get started?

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

I probably heard for the first time about OSM years ago on the 
PlanetGS.com blogroll. It must be around 2005 / 2006. There were talks 
about mapping parties at the Isle of Man and later Isle of Weight in the 
United Kingdom. At that time I would think it would be nearly impossible 
to create a worldwide street map. Later I went to the FOSS4G conference 
in Vancouver, and talked with some guys about it. I would swear James 
Ewen was one of them, but the conference was in 2007. As the project 
grew, I became more interested :)


Anyways, in spring 2008 I got my old GPS (which I've used for 
geocaching, but only a few times), and went exploring the area around 
Quebec City, where I was living at that time. Being Dutch but living 
abroad, I didn't have a big social network. So, being a mapping geek OSM 
was a great way to explore the environment where I was living.


Frank


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

Re: [OSM-talk-nl] Iemand op 5 juli 's middags tijd voor Situatie gewijzigd: Navigatie aan!

[Frank Steggink]

Hetzelfde geldt voor mij. Vandaag met een nieuwe klus begonnen, dus het 
lijkt me niet handig om in de 1e week een halve dag vrij te nemen. Ik 
ben benieuwd of alle wegbeheerders (dus niet alleen RWS, maar ook 
gemeenten en provincies) hieraan gaan meedoen.


Afgelopen vrijdag had ik een discussie met een collega hierover. Hij 
heeft een blauwe maandag bijgedragen aan de Fietsrouteplanner. Zij 
hebben een systeem om tijdelijke blokkades in te voeren. Zoiets zou 
eigenlijk ook in OSM moeten komen, maar dat is een ander verhaal.


Frank

On 2-7-2012 10:09, Henk Hoff wrote:
Zeker een interessante bijeenkomst waarbij OSM aanwezig zou moeten 
zijn. Ik kan zelf helaas niet, heb al teveel dagen vrij genomen de 
afgelopen tijd.


Mocht iemand tijd en zin hebben, wil die hem/haar van harte 
aanmoedigen te gaan!


Gr,
Henk Hoff


2012/7/1 Stefan de Konink ste...@konink.de mailto:ste...@konink.de


Komende donderdagmiddag vanaf 14:30 is er in Utrecht een congres over
de digitale bekendmakingen van onder andere IM. Op die manier kunnen
kaartenboeren direct hun kaarten updaten op het moment dat er
wegopbrekingen zijn of dat er iets is gewijzigd is het verkeersplan.

Ik ben uitgenodigd ook door m'n bijdrage bij openOV, mocht er een
OpenStreetMapper mee willen, mail even, er is plek ;)


Stefan



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




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

Re: [Talk-ca] Tr : [OSGeo-qc] Données ouvertes : gouvernement du Québec...

[Frank Steggink]

Nicolas, thanks a lot for the data and the information!

Of course the first page I went to was the License page: [1] 
Unfortunately this license doesn't seem to be compatible with any of the 
current OSM licenses (neither CC-BY-SA nor ODbL). The reason is that the 
license states that it it non transférable (non-transferrable). Also 
the Province of Quebec reserves all intellectual property rights to this 
data: L’Administration gouvernementale conserve tous les droits de 
propriété intellectuelle à l’égard des données ouvertes... When the 
data would be uploaded into OSM, it would be inevitable that the data 
gets modified somehow, due to the fact that this is a crowdsourced project.


An option for OSM would be to get some special agreement that we can use 
this data under our own conditions. I don't know if this would be 
realistic. Nicolas, could you give your view on it, as an employee of 
the provincial government? What would be the best venue to come to some 
agreement? Are there any other options?


On the other hand: weren't the administrative boundaries of Quebec 
scheduled for inclusion in a future release of Canvec? Probably the 
Government of Quebec and NRCan have some kind of agreement on this.


Frank

[1] http://donnees.gouv.qc.ca/?node=/licence

On 30-6-2012 5:33, Nicolas Gignac wrote:
Pour votre info, il y a des données géographiques administratives sur 
le site de données ouvertes du Qc, voir ce jeu de données :

http://donnees.gouv.qc.ca/?node=/donnees-detailsid=d6c535cb-b508-4cab-9a15-bdccd9433da4
Sur la page de téléchargement, voir la section *Découpages 
administratifs**(mise à jour mai 2012)* :

http://www.mrnf.gouv.qc.ca/territoire/portrait/portrait-donnees-mille.jsp
Évidemment, l'échelle de cette donnée est au 1 : 1 000 000.

Au plaisir,

Nicolas

Le 29 juin 2012 16:50, Pierre Béland infosbelas-...@yahoo.fr 
mailto:infosbelas-...@yahoo.fr a écrit :


Je fais suivre le courriel de Nicolas Gignac adressé à la liste
OSGeo-qc concernant le nouveau site de données ouvertes du
gouvernement du Québec. Nous ne retrouvons pas les données de
limites administratives (ville, MRC, régions administratives).
Pourquoi ne pas les demander?

I forward the email sent to the OSGeo-qc list byNicolas Gignac
relatively to the Government of Québec Open Data site newly
created. We do not find the administrative boundaries data (city,
RCM, administrative region). Why not ask?

Pierre

- Mail transféré -
*De :* Nicolas Gignac gignac...@gmail.com
mailto:gignac...@gmail.com
*À :* OSGeo-Quebec que...@lists.osgeo.org
mailto:que...@lists.osgeo.org
*Envoyé le :* Vendredi 29 juin 2012 15h17
*Objet :* [OSGeo-qc] Données ouvertes : gouvernement du Québec...

Pour votre info, le site de données ouvertes du gouvernement
du Québec est maintenant officiellement en ligne depuis hier :
http://donnees.gouv.qc.ca http://donnees.gouv.qc.ca/
La partie géomatique du site :
http://donnees.gouv.qc.ca/?node=/applications-geomatique est
supportée par le projet GOLOC qui intègre OpenLayers / GeoExt
et les couches WMS sont diffusées par UMN MapServer. Des
données brutes sont également disponibles en format Shapefile
et KML.
L'url du getcapabilities pour le WMS qui inclue certaines des
données ouvertes géographiques est le suivant :

http://geoegl.msp.gouv.qc.ca/cgi-wms/gouvouvertqc?request=getcapabilitiesservice=wmsversion=1.1.1

Le site web en tant que tel est supporté par du code en JQuery
/ Php, avec un service de catalogue normé (Catalog Service for
the Web) :
http://en.wikipedia.org/wiki/Catalog_Service_for_the_Web
supporté par le projet international GeoNetwork
(http://geonetwork-opensource.org/), une base de données
PostgreSQL (www.postgresql.org/ http://www.postgresql.org/)
et ses fonctionnalités PG de full text searching comme
tsvector et trigram pour la recherche du catalogue, tout
cela est monté sur deux serveurs Linux : OpenSuse et Ubuntu
Server ( pour GeoNetwork).

Si vous avez des données géographiques que vous aimeriez voir
sur le site de données ouvertes produites par le gouvernement
du Québec et qu'elles ne s'y retrouvent pas, veuillez faire
une demande de données en utilisant le formulaire disponible
en ligne sur le site :
http://donnees.gouv.qc.ca/?node=/demande-donnees


Au plaisir,

Nicolas

___
Quebec mailing list
que...@lists.osgeo.org mailto:que...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/quebec





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

Re: [OSM-talk] Zoom 14 gray vs green?

[Frank Steggink]

On 12-6-2012 19:43, Lynn W. Deffenbaugh (Mr) wrote:
Ok, I've got zero editing experience, but have been using and 
exploring OSM for some time now.  Can someone lead me by the nose as 
to what might be causing zoom level 14 and only 14 to be gray instead 
of green for the National Park?


http://www.openstreetmap.org/?lat=35.5585lon=-83.5005zoom=14layers=M

Lynn (D) - KJ4ERJ


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

The rendering date of the tiles was April 12. I've requested a 
rerendering of this meta tile by marking it dirty, and now those are 
green again.
Normally tiles of level 13+ should be rerendered automatically on 
changes. But perhaps this didn't happen, because the area is quite 
large, so the metatile falls entirely within the park. (Not checked though.)


Frank

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

Re: [Talk-ca] CBC English; no - françias; oui

[Frank Steggink]

On 30-5-2012 18:41, Bruno Remy wrote:

Hi folks!

Here from Quebec city (Qc) we're starting a local OSM group of mapping 
users and contributors.

Hope we'll have fun and a lot of mapping partys !

At first, we'd like to exchange working expriences with the gang of 
Toronto saw recently on CBC-Radio-Canada news.

Is there anybody here from Toronto ? (John Robb.Steve Singer, or )

Thanks,
--
Bruno Remy
OSM Québec


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

Hi Bruno,

Great initiative! I'll try to follow it, albeit not closely. Just about 
6000 km nowadays. ;) Will there be a mailing list or something? French 
is not an issue.


Regarding work in the area: have a look at residential areas which are 
built after 2009. Perhaps a couple of other roads have changed names in 
the meantime. Also the info from the RTC was released under an open data 
license a while back. Maybe it could be use to add more bus lines to 
Quebec City. And of course the Bing imagery in the area is great, which 
could be put to good use as well :)


There is also some work to be done to the Geobase roads which were 
imported in 2009 (by me or others). Those don't have names. It's still 
on my list to do something about it (by either copying the names from 
the latest Canvec roads, or replace them altogether if they aren't 
edited since the import), although I must admit that it has sunken to 
the bottom.


Anyways, it's great to hear that a real community is growing at last :) 
I wish you guys a lot of succes!


Frank

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

Re: [OSM-talk] Import of buildings in Chicago

[Frank Steggink]

On 27-5-2012 20:58, Ian Dees wrote:
On Sun, May 27, 2012 at 1:53 PM, Alan grunthos...@yahoo.com 
mailto:grunthos...@yahoo.com wrote:



I object.

An ID tag is highly useful for future reconciliation and/or
synchronization later.  And the chicago: namespace is, in my
opinion, definitely the correct way to do it, because it clearly
defines the scope of the id.  The chicago:building_id should stay.
   Not including it is dumping data into OSM; including it is
enabling collaborative use.


I've searched for a reliable way of doing this for years and have yet 
to find anything worthwhile.


Leaving the external ID on the objects doesn't really help when others 
remove or split the shape later on. On the other hand, they don't hurt 
anything...


I tend to think that keeping the ID has no use. As Ian mentioned, users 
can (and will) edit the data, so those features become split, merged 
together, or erased. The way OSM 'works' makes it really hard to deal 
with the ID's. There is also the principle that imports should not 
override user-contributed data, so (I assume that) a part of the 
building won't be imported at all. That will leave the set of ID's in 
the OSM DB in an incomplete state, which makes it much less useful.


Updates, if done at all, could better be done by using geographical 
matching. It would be great to have some generic tools with which an 
external datasource can be compared with OSM. This will generate a set 
of changeset files: one with matching features, one with modified 
features, one with 'new' features (not existing in OSM), one with 
'deleted' features (features which only exist in OSM). Then the user 
taking care of the import would only need to look at the latter three, 
to judge what has happened, and manually apply the changes he wishes.


In the Dutch community we've been discussing this a while ago, because 
all buildings in the Netherlands are available in a high quality PD 
dataset, called BAG (Basisregistratie Adressen and Gebouwen: base 
registration of adresses and buildings). Ironically, exactly the reason 
this dataset is existing and freely available, it makes it not worth 
while the effort to import this into OSM, and impose the burden of 
updating it onto ourselves. It is much more convenient to take OSM 
without buildings (and addresses) and merge this with the other dataset.


Frank

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

Re: [OSM-talk-nl] Andere tijden

[Frank Steggink]

Volgens mij is deze discussie erg OT aan het raken.

Robert: CC-0 is binnen de OSM community bij velen wel bekend. Meer 
informatie hier: http://creativecommons.org/choose/zero/?lang=nl. Het 
komt overeen met Public Domain (PD).


Frank

On 25-5-2012 22:38, Robert Elsenaar wrote:
Stefan, weinigen interesseert al dat licentie gedoe. Misschien ken jij 
10CC. Van CC-0 hebben echt weinigen gehoord. Welk genre is dat? Snapje 
het nou?



Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)


Stefan de Konink ste...@konink.de schreef:


On 25-05-12 08:40, Robert Elsenaar wrote:
 Nee, maar daar gaat het niet om. Alleen op ieder moment dat er een nieuw
 initiatief is, begin jij direct te z... over licentievoorwaarde. A)
 iedereen weet best wel dat je ook faar tijdens het proces naar moet
 kijken. B) Henk (foundation) is onze licentie sheriff en die heeft heus
 geen overijverige assistent nodig.

Waarom worden mijn ideeën waar ik vooraf over in overleg ga met de
foundation dan de grond in gefietst, en hoor je er niemand meer over bij
een ander project.

In dat geval kan iedereen dus gewoon doen wat hij goed dunkt - mij maakt
het niet uit, immers mijn data is CC-0.


Stefan

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



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



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

[OSM-talk-nl] Andere tijden

[Frank Steggink]

Genietend van het mooie weer en de vakantie die ik toevallig heb, 
besloot ik maar weer e.e.a. in kaart te brengen in de prachtige stad 
Utrecht. Ondanks de mapping party van 2 jaar geleden is er nog meer dan 
genoeg te mappen. Wandelend langs de Oudegracht kwam ik toevallig uit 
bij een schim uit een ver verleden: een platenzaak [1]! Groot was 
zojuist mijn ontsteltenis bij het invoeren dat er hiervoor geen shop-tag 
was gedefinieerd! Blijkbaar heeft niemand hiervoor de moeite genomen in 
de tijd van iTunes. Volgens TagWatch [2] is een platenzaak sowieso een 
uitstervend verschijnsel. Culturel erfgoed?


De kaart ziet er saai uit: alleen maar een lange reeks huisnummers. Er 
zitten hier wel woonhuizen, maar ook wel winkels (antiek, galerij, iets 
voor volwassenen, etc.) en een groot hok op nr. 312 [3] waar nog geen 
witte rook uitkomt.


Groeten,

Frank


[1] http://www.openstreetmap.org/browse/node/1763428067
[2] http://taginfo.openstreetmap.org/keys/?key=shop#values , zoek op 
'record'

[3] http://www.openstreetmap.org/browse/node/1763427942


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

Re: [OSM-talk-nl] Andere tijden

[Frank Steggink]

On 23-5-2012 21:38, Martijn van Exel wrote:

Ik heb shop=music gebruikt in het verleden:
http://taginfo.openstreetmap.org/tags/shop=music#overview
http://wiki.openstreetmap.org/wiki/Proposed_features/Music_shop
Aangepast. Ik blijf tagging een uitdaging vinden. O.a. een winkel met 
new-agespulletjes tegengekomen en een 'spellenspeciaalzaak' (verkopen 
Magic The Gathering-kaarten, etc.). Ik heb hen beloofd om ze niet als 
speelgoedwinkel op te nemen, dus nu is het shop=card_games ;) Bij 
twijfel gebruik ik tag watch, om gewoon aan te sluiten wat het meest 
gebruikelijk is.


Frank

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

Re: [OSM-talk-nl] State of the Map in Tokyo Goedkope vluchten

[Frank Steggink]

On 19-5-2012 3:30, Henk Hoff wrote:

Hallo allen,

Mocht je interesse hebben om in september naar Tokyo te gaan voor 
State of the Map. (www.stateofthemap.org 
http://www.stateofthemap.org) Er is dit weekend nog een hele leuke 
actie voor goedkope tickets naar Tokyo.


Alitalia heeft goedkope tickets naar Tokyo. En tot zondag kun je ook 
nog eens 20% extra korting krijgen.


http://hukd.mydealz.de/deals/20-rabatt-bei-alitalia-tokio-flüge-nun-89741 
http://hukd.mydealz.de/deals/20-rabatt-bei-alitalia-tokio-fl%C3%BCge-nun-89741


Ik heb deze net gedaan en het werkt. Je moet alleen even via 
alitalia.de http://alitalia.de boeken wil je de 20% korting kunnen 
krijgen.


Mijn route:
Amsterdam (Rome) Tokyo  met Alitalia
Tokyo (Rome) Boedapest  met Alitalia
Boedapest - Eindhoven   met Whizzair

Totaalprijs: 320 euro.

Gr,
Henk


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

Henk,

Heb je toevallig de laatste tijd nog iets meegekregen van een mogelijke 
SotM-EU? Aan de ene kant zou ik best wel Japan willen bezoeken, maar aan 
de andere kant zie ik als een Fuji-san op tegen de lange vlucht (+ 
douane-gedoe op het vliegveld), dus laat ik de internationale editie 
schieten.


Groeten,

Frank

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

Re: [OSM-talk] [SPAM]Re: OSM cycle map - ?excessive focus on long-distance routes

[Frank Steggink]

As a local I can confirm that those routes are signed, or at least 
partially. IIRC they are nothing more than small white signs with black 
letters with the direction you're heading. I strongly doubt if these 
signs are put along the entire route. I don't recall them at all places, 
just at a few locations. Most locals would already know which route 
suites them the best. (And no, they're definitely not taking the 
touristic ones ;) )


The local government is promoting those routes for bike traffic which 
has to cross the city from/to the suburbs and/or neighboring towns (like 
Houten, Nieuwegein, etc.). They're investing in infrastructure, proper 
lighting (for safety reasons), etc. However, so far it hasn't come up in 
my mind to tag those routes. They're not mandatory, and there is nothing 
particular to the signs (as opposed to the 'knooppuntenroutes', the 
routes with the numbered points).


Anyways, the map isn't really accurate, but from what I can tell from 
the route Lunetten/Houten - Smakkelaarsveld, I would follow a different 
road along the last part, because it bypasses many traffic lights which 
are on the Catharijnesingel [1] (most of them are not in OSM...). By the 
way, another section of the route has been closed since extra railway 
tracks are being constructed. [2]


Regards,

Frank

[1] http://osm.org/go/0E6JD67ym-?m
[2] http://osm.org/go/0E6Ifk~Et--?m

On 9-5-2012 16:01, Richard Mann wrote:
You'd have to ask the City of Utrecht whether their main cycle 
routes are signed. If they've officially identified a particular set 
of routes, that would seem to be fairly clear-cut. See their city 
website: 
http://www.utrecht.nl/images/dso/infraprojecten/fiets/fietsroutes.html

Richard


On Wed, May 9, 2012 at 2:34 PM, Richard Fairhurst 
rich...@systemed.net mailto:rich...@systemed.net wrote:


Richard Mann wrote:
 My point is that tagging should allow both types of routes to be
 recorded

We tag what's on the ground, whether it's route signage,
cycle-specific
infrastructure, or a giant woolly mammoth (http://url.ie/f9ts).

Are you suggesting a deviation from that?

cheers
Richard



--
View this message in context:

http://gis.19327.n5.nabble.com/OSM-cycle-map-excessive-focus-on-long-distance-routes-tp5697183p5697391.html
Sent from the General Discussion mailing list archive at Nabble.com.

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




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



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

Re: [OSM-talk] A rendering issue with the maps on OSM homepage?

[Frank Steggink]

On 10-4-2012 15:23, Robert Tromp wrote:
Have a look at this area on the west coast of Hokkaido, Japan: 
http://osm.org/go/7U~IT~Jz

Notice the greyed-out ocean and the mis-aligned areas, coastline

Looking at the OSM-data itself using JOSM, there seems nothing wrong 
(other than a few small mapping mishaps)
Furthermore, MapOSMatic, for example, creates perfectly good maps 
(including edits I made to OSM after I first noticed the rendering issue).


In the past weeks, neither regular nor forced re-renderings of the map 
tiles have solved the problem.


Robert


___
talk mailing list
talk@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk
When I look at [1] the status is: Tile is clean. Last rendered at Mon 
Oct 10 12:56:45 2011


Forced rerendering seems to solve the problem.  The area now looks fine to me.

Frank


[1] http://a.tile.openstreetmap.org/16/58277/24359.png/status

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

Re: [Talk-ca] Quebec's Bermuda Triangle

[Frank Steggink]

On 10-4-2012 21:53, Pierre Béland wrote:

Harald,
It probably mean that this have been corrected already but that tiles 
have not been updated yet for all zoom levels. I often see that when a 
erase a feature, updates can be made rapidly at some zoom levels and 
not at others. And after a day or two, the edit is completed for all 
levels.

//
/Pierre/

*De ：* Harald Kliems
*Date/heure ：* 2012-04-10 14:25:08
*A ：* Talk-CA OpenStreetMap
*Cc ：*
*Sujet ：* [Talk-ca] Quebec's Bermuda Triangle
Hi everyone:
a while ago I noticed this weird triangle west of Vaudreuil:
http://www.openstreetmap.org/?lat=45.342lon=-74.24zoom=9layers=M
If you zoom in any further it disappears. I initially thought it was
some coastline-related flooding issue but since it doesn't extend all
the way to the Ottawa River that seems unlikely. I've opened the
region in JOSM and couldn't find anything that might render as this
weird triangle. Maybe someone will have luck in uncovering its secret.
Best,
Harald.
--
Please use encrypted communication whenever possible!
Key-ID: 0x199DC50F
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca


___
Talk-ca mailing list
Talk-ca@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-ca
The triangle is probably caused by the shapefile which is used for 
rendering the coastline at levels 9 and below. This shapefile isn't 
updated very often. I believe it is a different one than the file used 
for levels 10 and above, which should be updated about once a week.


Frank

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

Re: [OSM-talk-nl] AND data in OSM

[Frank Steggink]

On 5-4-2012 20:55, Henk Hoff wrote:
Die voorwaarde heeft AND gesteld. Aangezien AND de goedkeuring voor 
gebruik van de data enkel het deel betreft wat reeds in onze database 
was gelezen, vonden we (de licentie werkgroep) dit geen belemmerende eis.


Gr,
Henk

2012/4/5 Stefan de Konink ste...@konink.de mailto:ste...@konink.de

On 05-04-12 15:38, Henk Hoff wrote:

Wanneer er nog vragen zijn, stuur me even een mailtje.


Waarom moeten bron bestanden die onder de CC-BY-SA zijn
vrijgegeven worden verwijderd?


Stefan



___
Talk-nl mailing list
Talk-nl@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-nl
Wat is er in 2007 precies met AND afgesproken? Hebben zij de 
bronbestanden onder CC-BY-SA vrijgegeven, of was er een soortgelijke 
overeenkomst als met Bing, nl. dat hun data als input voor OSM gebruikt 
kan worden (wat dan onder CC-BY-SA zou vallen)? In de bronnen op de 
wiki-pagina [1] die nog online zijn, kom ik niet meer tegen dan dat het 
beschikbaar gesteld is. Dit is inclusief de press release van AND [2].


Groeten,

Frank

[1] http://wiki.openstreetmap.org/wiki/AND_Data
[2] 
http://web.archive.org/web/20070927051801/http://www.and.com/company/newsletter/newsletter10/art01en.php


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

Re: [Talk-ca] Clean up progress and last push

[Frank Steggink]

On 31-3-2012 7:25, Richard Weait wrote:

Okay, so, u.  Wow!

I've been looking around with the OSM Inspector to see how the license
clean up is progressing elsewhere.

You've been busy.

Victoria and Nanaimo looked pretty dire a few weeks ago.  They're in
much better shape now.  Southwestern Ontario looks great. The Niagara
peninsula and Golden Horseshoe look good.  Toronto and environs has
some minor issues still, but is much improved. All of that is super to
see.

There are some spots that could use your attention if you still have
some cleaning cycles before Sunday.  Ottawa, Montreal, Quebec, Sydney,
Fredericton and Sherbrooke could use some help. There is some
coastline to be cleaned near Sept-Iles.  Winnipeg and Brandon would
like your help.  Yorkton, up to Saskatoon and Lloydminster need some
love.  Edmonton, Red Deer and Calgary would benefit from your
attention and there are still some areas near Whistler to improve.

If you are feeling some cross-border love, perhaps you'll help our
lake-mates with the US side of the Great Lakes?  The area near Sault
Sainte Marie should be looking better. Lake Ontario seems good as does
most of Erie.

Help out some more, if you can.  You've done a super job of sorting
out a lot of data.  That's great to see.  Be proud of yourselves.  :-)

If you haven't been using OSMI to help clean up, you should.  Have a
look.  Sorry for the long link.

http://tools.geofabrik.de/osmi/?view=wtfelon=-75.24686lat=45.17431zoom=7opacity=0.41overlays=overview,wtfe_point_clean,wtfe_line_clean,wtfe_point_harmless,wtfe_line_harmless,wtfe_point_inrelation,wtfe_line_inrelation_cp,wtfe_line_inrelation,wtfe_point_modified,wtfe_line_modified_cp,wtfe_line_modified,wtfe_point_created,wtfe_line_created_cp,wtfe_line_created

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


Hi Richard,

Working on Quebec. I've replaced about half of the affected roads with 
Canvec. The stray non-ODBL nodes (which happen to be along main streets) 
are due to nodes being reused for landuse. I'm not sure if those can be 
cleaned up in time (as I expect to be busy with the rest of the roads 
most of the day), but I'll try.



Frank

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

Re: [OSM-talk-nl] Toponym

[Frank Steggink]

Citeren Frank Steggink stegg...@steggink.org:


Citeren Maarten Deen md...@xs4all.nl:


On 2012-03-23 08:56, Colin Smale wrote:

Op dit moment wordt op een paar duizend plekken de tag toponym
gebruikt, waarvan bij allemaal in Nederland. Maar wat ik zie in de
waarden zijn volgens mij helemaal geen toponiemen! park, forest
etc. zijn geen toponiemen maar voorbeelden van landgebruik/dekking.
Julianapark en Zwarte Woud zouden wel toponiemen zijn.

Of begrijp ik het woord toponym verkeerd?

Ik zag dat er in feb 2010 een discussie was over detail omgeving
oldenzaal waarin melding werd gemaakt van een nieuw voorstel voor
toponiem-gebruik, en er is ook een Nederlandse Wiki-pagina [1] die
daar heel kort iets over zegt waarin de basis wordt gelegd voor dit
(IMHO) misbruik van de term.

T.a.v. de toponym-tag heb ik de volgende constateringen:
1) Het is bijna uitsluitend een Nederlands verschijnsel - heeft dus
nagenoeg geen internationale bekendheid/draagvlak
2) De tag is niet gedocumenteerd op de wiki
3) Het woord wordt verkeerd gebruikt - de waarden zijn geen toponiemen
4) Geen brede ondersteuning door editors/renderers
5) Het is gebruikt om andere, wel gedocumenteerde/ondersteunde tags
te vervangen

Ik zou graag willen dat de huidige voorkomens van toponym=* opgeruimd
worden en wellicht de voorgaande tags (landuse, name, etc) teruggezet.

Wat vinden jullie?

Colin

[1] http://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import


Ik heb die toponiem tag ook al een paar keer gezien, maar ik begrijp de
gedachte erachter niet. Een toponiem is een naam die afgeleid is van de
streek of van een topografisch verschijnsel. Amsterdam - Dam in de
Amstel.
Het is niet zo dat de naam van een bos per definitie een toponiem is.
Ik zie ook niet in waarom deze tag gebruikt moet worden. Voor de naam
van een feature in OSM kun je gewoon name= gebruiken. De toponym
toelichting in [1] begrijp ik ook niet. Waarom kun je name= niet
gebruiken op een groot gebied dat is opgedeeld in kleine stukken? Of is
dat om er voor te zorgen dat voor de kleine stukken de naam niet
gerenderd wordt? Los dat op met een relatie.
toponym=forest is IMHO ook incorrect. Een bos is geen toponiem. De naam
van een bos kan een toponiem zijn.

Maarten


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


Ik zal kort zijn, want het volledige antwoord ben ik kwijtgeraakt in
de browser, omdat ik een 'ë' wilde intypen terwijl de numlock toets
uitstond. De tag is door Lennard en mij geïntroduceerd, om de namen
van de landuse-vlakken van AND te bewaren tijdens de 3dShapes import.
De vlakken zelf zijn omgetagd, omdat je anders grote stukken dubbele
landuse krijgt, wat niet wenselijk is.

Het was de bedoeling om hier een goed voorstel voor te schrijven, maar
vanwege tijdgebrek is dit er niet meer van gekomen. Er bestaat al
rendering-support, aangezien de namen zelf worden weergegeven. Hier
gaat het namelijk om. Het idee achter de toponym-tag zelf is om
renderers een hint mee te geven van hoe de naam gerenderd kan worden.
Het kan in theorie ook voor grote gebieden, zoals de Alpen worden
gebruikt. Dat wil je niet allemaal met een relatie o.i.d. bijhouden.
Zelfs de Veluwe niet ;)

Verder betekent toponiem letterlijk plaatsnaam [1]. Het zegt niet
iets over hoe de naam tot stand is gekomen.

Groeten,

Frank

[1] http://en.wikipedia.org/wiki/Toponymy



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


Wat ook meespeelde in onze overweging is dat het gebruik van de  
landuse-tag een zootje is geworden. Het beschrijft zowel de functie  
(landuse=park) als wat er in het terrein te vinden is (landuse=forst).  
Er is ook een grote overlap met de natural-tag. Van natural=wood vs.  
landuse=forest kan ik het onderscheid nog wel begrijpen (want  
niet-beheerd / wel beheerd), maar waarom wordt dan wel natural=water  
gebruikt in een land zoals Nederland, waar het meeste water haar  
natuurlijke karakter al lang verloren heeft (of zelfs nooit gehad  
heeft)?


Misschien kan een eventueel toponiem-voorstel, mocht dat ooit toch van  
de grond komen, worden aangevuld met een tagging-voorstel wat een  
duidelijk onderscheid maakt tussen functie en fysiek voorkomen. Het is  
lastig om hierin eenduidigheid te krijgen.


Bijv. Julianapark:
toponiem: name=Julianapark
functioneel: function=park
landgebruik (huidige tagging): meerdere vlakken met landuse=forest;  
landuse=grass; natural=water
Hier kan function=park en name=Julianapark prima worden gecombineerd.  
Dit komt goed over met ons oorspronkelijke idee.


Alpen:
toponiem: name=Alps; hoe aangeven dat dit een gebergte is? (dus:  
toponym=mountain_range)
functioneel: n.v.t.? De Alpen zijn er; het is niet door mensen bepaald  
dat de Alpen moeten komen waar ze nu zijn. Wel zijn er binnen de Alpen  
regionaal en lokaal vele gebieden met allerlei soorten

Re: [OSM-talk-nl] Toponym

[Frank Steggink]

Citeren Maarten Deen md...@xs4all.nl:


On 2012-03-23 10:52, Frank Steggink wrote:

Citeren Frank Steggink stegg...@steggink.org:


Citeren Maarten Deen md...@xs4all.nl:


On 2012-03-23 08:56, Colin Smale wrote:

Op dit moment wordt op een paar duizend plekken de tag toponym
gebruikt, waarvan bij allemaal in Nederland. Maar wat ik zie in de
waarden zijn volgens mij helemaal geen toponiemen! park, forest
etc. zijn geen toponiemen maar voorbeelden van landgebruik/dekking.
Julianapark en Zwarte Woud zouden wel toponiemen zijn.

Of begrijp ik het woord toponym verkeerd?

Ik zag dat er in feb 2010 een discussie was over detail omgeving
oldenzaal waarin melding werd gemaakt van een nieuw voorstel voor
toponiem-gebruik, en er is ook een Nederlandse Wiki-pagina [1] die
daar heel kort iets over zegt waarin de basis wordt gelegd voor dit
(IMHO) misbruik van de term.

T.a.v. de toponym-tag heb ik de volgende constateringen:
1) Het is bijna uitsluitend een Nederlands verschijnsel - heeft dus
nagenoeg geen internationale bekendheid/draagvlak
2) De tag is niet gedocumenteerd op de wiki
3) Het woord wordt verkeerd gebruikt - de waarden zijn geen toponiemen
4) Geen brede ondersteuning door editors/renderers
5) Het is gebruikt om andere, wel gedocumenteerde/ondersteunde tags
te vervangen

Ik zou graag willen dat de huidige voorkomens van toponym=* opgeruimd
worden en wellicht de voorgaande tags (landuse, name, etc) teruggezet.

Wat vinden jullie?

Colin

[1] http://wiki.openstreetmap.org/wiki/3dShapes/Landuse_import


Ik heb die toponiem tag ook al een paar keer gezien, maar ik begrijp de
gedachte erachter niet. Een toponiem is een naam die afgeleid is van de
streek of van een topografisch verschijnsel. Amsterdam - Dam in de
Amstel.
Het is niet zo dat de naam van een bos per definitie een toponiem is.
Ik zie ook niet in waarom deze tag gebruikt moet worden. Voor de naam
van een feature in OSM kun je gewoon name= gebruiken. De toponym
toelichting in [1] begrijp ik ook niet. Waarom kun je name= niet
gebruiken op een groot gebied dat is opgedeeld in kleine stukken? Of is
dat om er voor te zorgen dat voor de kleine stukken de naam niet
gerenderd wordt? Los dat op met een relatie.
toponym=forest is IMHO ook incorrect. Een bos is geen toponiem. De naam
van een bos kan een toponiem zijn.


Ik zal kort zijn, want het volledige antwoord ben ik kwijtgeraakt in
de browser, omdat ik een 'ë' wilde intypen terwijl de numlock toets
uitstond. De tag is door Lennard en mij geïntroduceerd, om de namen
van de landuse-vlakken van AND te bewaren tijdens de 3dShapes import.
De vlakken zelf zijn omgetagd, omdat je anders grote stukken dubbele
landuse krijgt, wat niet wenselijk is.


Kon je dan niet beter name:AND gebruiken? Je hebt nu een verwarrende
tag geintroduceerd.


Verder betekent toponiem letterlijk plaatsnaam [1]. Het zegt niet
iets over hoe de naam tot stand is gekomen.


Ja, de griekse vertaling van topo-niem is plaats-naam. Maar een
toponiem is een naam die is afgeleid van de
plaats/omgeving/omstandigheden van waar het object zich bevindt of hoe
het er uitziet.
Zoals ik al eerder heb gezegd: het is niet zo dat een plaatsnaam
automatisch een toponiem is, alhoewel het dat natuurlijk meestal wel is.


Alpen:
toponiem: name=Alps; hoe aangeven dat dit een gebergte is? (dus:
toponym=mountain_range)


mountain_range is geen toponiem. mountain_range is een omschrijving
van datgene wat er is.
Alpen is juist het toponiem, want Alpen is afgeleid van het Latijnse
woord voor wit (de definitie van een toponiem: een naam die is afgeleid
van datgeen wat er is).
Dan zou het eerder moeten zijn: toponym=Alps, name=mountain_range. Of
description=mountain_range.

IMHO is de tag toponym in OSM overbodig. Want als de naam een toponiem
is dan is toponym gelijk aan name. Als de naam geen toponiem is dan
heeft het object geen toponiem.
Het gebruik van toponym=park of toponym=forest is helemaal onjuist.
Volgens mij is voor de soort begroeiing de landuse tag en voor het
gebruik kun je o.a. leisure gebruiken (landuse=grass, leisure=park).

Maarten


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


OK, vervang dan 'toponym' maar door 'description'. Zolang het maar  
geen 'landuse' / 'leisure' / etc. wordt, of is dit volgens jou taggen  
voor de renderer?


Name:AND lost niks op. Het ging er ons hoofdzakelijk om de landuse-tag  
van de shape af te halen, zodat je dan geen dubbele vlakken krijgt.  
Dat zou helemaal niet acceptabel zijn geweest voor de 3dShapes import.


Frank

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

Re: [OSM-talk-nl] Toponym

[Frank Steggink]

Citeren Maarten Deen md...@xs4all.nl:



Dan gebruik je landuse:AND. Ik dacht dat je de name-tag van AND   
wilde bewaren.




Achteraf gezien was dat beter geweest.

Frank


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

Re: [OSM-talk-nl] Toponym

[Frank Steggink]

Citeren Colin Smale colin.sm...@xs4all.nl:


On 23/03/2012 11:52, Lennard wrote:
Niet omdat het kan, maar omdat het wellicht zou moeten; met beleid   
natuurlijk en niet rücksichtslos. Hoe veel van de 2000+ voorkomens  
 van toponym=* in NL zijn vergelijkbaar met wat er onlangs met het   
Julianapark (Utrecht) [1] gebeurde? Hierbij is leisure=park   
vervangen met toponym=park met het gevolg dat het niet langer als   
park herkenbaar was.


Aan de begroeiing, weergegeven door landuse=forest + landuse=grass, is  
wel op te maken dat het een park in. Toen ik afgelopen week hier bezig  
was, heb ik de tag leisure=park vervangen door toponym=park.



Dat er nog een discussie loopt over ontdubbeling van vlakken n.a.v. de
3dshapes import is een ding, maar kunnen wij alsjeblieft onze 1418
forests, 597 parken, 44 cemeteries (zie tagwatch [2]) etc etc
terugkrijgen?


Dan krijg je overal in Nederland de situatie zoals nu met het  
Julianapark. In bijna alle gevallen is er sprake van dubbel landuse,  
anders was er uberhaupt voor ons geen reden om de toponym-tag in te  
zetten. Is dat wat jou voor ogen staat? Wellicht kan de styling worden  
aangepast voor functionele tags (zoals leisure).


Belangrijk om te weten is dat de informatie niet verloren is, in  
afwachting van een beter voorstel. Ik ben het wel met je eens dat de  
huidige situatie niet ideaal is en dat er een betere oplossing moet  
komen.


V.w.b. mijn aanpassingen van afgelopen week [1]: ik hoop tenminste dat  
je akkoord gaat met de verwijdering van het park aan weerszijden en  
in de middenberm van de Einsteindreef en langs de rand van de N230.


Verder heb ik toen de shape van Park de Gagel hersteld [2]. Dit had al  
de toponym-tag, maar was opgeknipt geraakt. Hier speelde nog een ander  
issue, namelijk dat er 3 3dShapes-vlakken [3] [4] [5] een naam hadden  
gekregen. Niet geheel willekeurig, maar wel zodat de naam op  
representatieve plekken in het park worden gerenderd. Dat is de  
light-variant van het taggen van alle shapes in een bepaald gebied met  
een naam.


Kortom, er genoeg aanleiding om eens na te gaan denken voor een betere  
tagging om gebieden een naam te geven, maar waarbij wel recht wordt  
gedaan aan de functie en het fysieke voorkomen. V.w.b. het  
landcover-voorstel wat door G.J. wordt genoemd: is daar de laatste  
tijd nog over gepraat?


Groeten,

Frank

[1] http://www.openstreetmap.org/browse/changeset/11043851
[2] http://www.openstreetmap.org/browse/way/143448708
[3] http://www.openstreetmap.org/browse/way/72107784
[4] http://www.openstreetmap.org/browse/way/72107938
[5] http://www.openstreetmap.org/browse/way/72110476

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

Re: [OSM-talk-nl] Uitsnede OSM van Amsterdam

[Frank Steggink]

On 23-3-2012 14:31, Steven M. Ottens wrote:

Hoi allemaal,

WhereCampEU (http://wherecamp.eu) komt het weekend voor Koninginnedag 
naar Amsterdam. Voor de bezoekers wil ik een leuke online en offline 
kaart *) maken met uitleg wat waar is etc. is er ergens een recente 
uitsnede van Amsterdam te vinden? Bij voorkeur alleen van het gebied 
binnen de A10, of kan iemand dat in een handomdraai doen?


Alvast bedankt
Steven

*) iets met tilemill, mbtiles en apps voor mobieltjes, ideeën daarvoor 
zijn ook welkom.





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


Hoi Steven,

Kijk eens hier: http://metro.teczno.com/#amsterdam
Het is wel een stuk groter dan de stad zelf, maar beter te hanteren dan 
de planet-dump of zelfs de benelux-dump.


Groeten,

Frank

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

Re: [OSM-talk-nl] Toponym

[Frank Steggink]

On 23-3-2012 16:54, Colin Smale wrote:
Dan krijg je overal in Nederland de situatie zoals nu met het 
Julianapark. In bijna alle gevallen is er sprake van dubbel 
landuse, anders was er uberhaupt voor ons geen reden om de 
toponym-tag in te zetten. Is dat wat jou voor ogen staat? Wellicht 
kan de styling worden aangepast voor functionele tags (zoals leisure).


Belangrijk om te weten is dat de informatie niet verloren is, in 
afwachting van een beter voorstel. Ik ben het wel met je eens dat de 
huidige situatie niet ideaal is en dat er een betere oplossing moet 
komen.


De informatie is wel uit het zicht verdwenen omdat de 
oorspronkelijke tags verwijderd zijn. Iedereen mag nieuwe tags 
toevoegen - dit is inherent aan het open karakter van OSM. Maar het 
verwijderen van bestaande, breed geaccepteerde tags kan niet zomaar. 
En het misbruiken van woorden zoals nu gebeurt met toponym is zonder 
meer iets wat vermeden moet worden.

Ik was in de veronderstelling dat dat hier geen probleem was, omdat:
a) het evident is dat het gebied een park is, door de geïmporteerde landuse.
b) de informatie an sich niet verloren is gegaan. Niet alle informatie 
in de DB wordt op de kaart gerenderd.


Hoe vaak wil je dat ik nog sorry moet zeggen, omdat wij de 
toponym-tags hebben gebruikt als placeholder? Ik heb je nu wel begrepen...


Verder waren we al meer dan 2 jaar geleden begonnen met de import van 
3dShapes data en is deze al een tijd afgerond (op 2 kleine plukjes na). 
Blijkbaar was de toponym-tag al die tijd geen issue, maar omdat ik 
toevallig een paar dagen geleden het waagde om het Julianapark aan te 
passen, nu in een keer wel?


V.w.b. mijn aanpassingen van afgelopen week [1]: ik hoop tenminste dat 
je akkoord gaat met de verwijdering van het park aan weerszijden en 
in de middenberm van de Einsteindreef en langs de rand van de N230.
Dat lijkt mij geen probleem! Een park is pas een park als de gemeente 
(of ander beheerorgaan) het zo noemt, lijkt mij.


Verder heb ik toen de shape van Park de Gagel hersteld [2]. Dit had 
al de toponym-tag, maar was opgeknipt geraakt. Hier speelde nog een 
ander issue, namelijk dat er 3 3dShapes-vlakken [3] [4] [5] een naam 
hadden gekregen. Niet geheel willekeurig, maar wel zodat de naam op 
representatieve plekken in het park worden gerenderd. Dat is de 
light-variant van het taggen van alle shapes in een bepaald gebied 
met een naam.
Jouw beeld van de grens van Park de Gagel wijkt wel sterk af van het 
beeld van Gemeente Utrecht... zie pagina 38 (inzoomen vereist!!) van 
http://www.utrecht.nl/images/Stadswerken/Parken/beheerplan180308.pdf
Mijn beeld is een samenvoeging van 2 ways met toponym=park; 
area=yes, inclusief de namen die op 3 grasvelden stonden binnen het 
park. Verder heb ik me niet in de officiële omvang van het betreffende 
park verdiept. Is dat een vereiste voordat er überhaupt een verandering 
gemaakt mag worden?


Frank


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

[OSM-talk-nl] In het licht van de toponym-thread

[Frank Steggink]

Beste lijstgenoten,

Hieronder staat een mail die ik naar talk-nl heb gestuurd n.a.v. de 
BAG-discussie, met de ervaring van de 3dShapes import in het 
achterhoofd. Zie ook hier: [1]

Ik ga hier even doorheen lopen, omdat het de toponym-discussie raakt.

Verder had ik verwacht dat onderstaande mail de nodige discussie zou 
opleveren, maar de respons was 0,0.


On 1-2-2012 20:52, Frank Steggink wrote:
Voordat het import-virus losbarst: wees je er wel van bewust wat voor 
klus dit is! Dit kan ik niet genoeg benadrukken. Elke import is uniek. 
De BAG-import heeft meer voeten in de aarde dan bijv. de 3dShapes 
import. Dit om de volgende redenen:


* Vervanging bestaande data: Ten tijde van de 3dShapes import was NL 
redelijk blanco op het gebied van gebouwen en landgebruik. (De 
AND-landuse was van lage kwaliteit, dus die kon worden verwijderd.) Nu 
staat NL vol met gebouwen uit de 3dShapes. Voor een deel zijn deze ook 
bewerkt / verrijkt met andere data. Je kunt geen import doen zonder 
hier een goede oplossing voor te verzinnen. In het geval de 3dShapes 
gebouwen niet gewijzigd zijn (version=1), zouden deze vervangen kunnen 
worden. Probeer dus eerst inzichtelijk te krijgen welke gebouwen wel 
problemen opleveren, bijv. omdat je tags moet omzetten. Ga eerst in 
conclaaf met andere OSM-ers die wijzigingen aan de gebouwen hebben 
aangebracht in het gebied waarvan je de BAG wil importeren.
Wat mijn opmerking over de AND-landuse betreft: ik sta hier nog steeds 
achter. Shapes met een naam zijn omgetagd. Redundante shapes zijn 
verwijderd. Dit kunnen ook vlakken met alleen een tag leisure=park zijn 
geweest. Oeps, wat nu? Er geldt nog steeds dat er landuse voor in de 
plaats is gekomen, dus op de kaart is het nog steeds als zodanig 
zichtbaar. Verder is het maar de vraag of de situatie in de AND-data 
juist was en of de gekozen tagging voor de AND-import juist was.


* Verantwoordelijkheid: als je aan een import begint, heb je je te 
houden aan de import guidelines. Zie hier: 
http://wiki.openstreetmap.org/wiki/Import_guidelines . Als jij zelf 
BAG-data wil importeren, heb jij je _zelf_ hier aan te houden, omdat 
de import onder _jouw_ account zal plaatsvinden. Je bent dus ook 
verantwoordelijk voor eventuele troep die je achterlaat. Natuurlijk ga 
je die ook zelf opruimen ;) De rest van de community zit hier niet op 
te wachten. Vraag je eerst af of je bereid bent je hieraan te 
committen. Zie ook het volgende punt.
Of je het er mee eens bent of niet: dit hebben wij ook gedaan met de 
3dShapes import. Wel naar onze eigen inzichten. Gezien het feit dat er 
weinig feedback was, hadden wij geen reden om aan te nemen dat wij er 
een zootje van maakten. Alhoewel ik op voorhand mij van dit punt bewust 
was, heb ik wel in de loop van het proces ervaren hoe belangrijk dit is. 
Een andere conclusie is dat je het nooit goed genoeg doet en niet 
iedereen 100% tevreden kunt stellen, zoals de toponym-thread bewijst.


* Updates: al aangestipt. Zeker zinvol om over na te denken, maar het 
probleem hier is dat dit niet af te dwingen is. Iemand kan ergens de 
BAG importeren en plechtig beloven zich te committen aan updates, maar 
als hij een andere hobby heeft gevonden, zijn er ook geen updates meer.
N.v.t. voor de 3dShapes, aangezien die eenmalig was. Technisch gezien 
zou je met Top10NL 3dShapes kunnen updaten, maar daar was in 2009/2010 
totaal geen zicht op.


* Nut: wat is de toegevoegde waarde van de BAG in OSM? De adressen 
ontbreken in OSM, wat handig is voor routing, e.d., maar er zijn al 
wel gebouwen. IMO zijn deze van voldoende kwaliteit voor de meeste 
toepassingen van OSM. Ik wil natuurlijk in mijn gebied wel de best 
beschikbare data, maar ik weet ook al dat, als ik een mooie kaart van 
NL ga maken, ik de BAG data wel uit de originele bron ga betrekken en 
niet uit OSM. Dit omdat de BAG zelf de beste bron is. Wie weet wat er 
met de OSM data is gerommeld is en wat de actualiteit is? Zelfs al 
loopt OSM voor (wat heel goed mogelijk is), je kunt niemand binnen OSM 
aanspreken als de situatie niet klopt. Het standaardantwoord: pas het 
lekker zelf aan. In de GIS-wereld loopt al enige jaren de discussie 
tussen authoritive data vs. crowdsourced data, wat hierop betrekking 
heeft.
Het is evident wat het nut van de 3dShapes import is. Daarom kozen we in 
de 1e plaats voor deze import. Nu is ons land al voorzien van landuse 
data, en hoeven we niet als een gek van Bing te tracen (waar actualiteit 
ook een probleem is).


Het bovenstaande punt geldt trouwens ook voor de landuse. Ja, in die 
zin heb ik maanden vrije tijd voor niks besteed, maar toen was ook 
niet bekend dat de Top10NL open data zou worden. Mijn handen jeuken 
totaal niet om Top10NL in OSM te laden. Hooguit om de 3dShapes data 
ten dele te verrijken, om fouten met de classificaties ongedaan te 
maken. Bij de 3dShapes-import is i.i.g. hier wel zoveel mogelijk 
rekening gehouden en tijd ingestoken.

Een ander voorbeeld van de moeite die wij erin hebben

Re: [OSM-talk-nl] Postcodes semi-automatisch toevoegen aan adrespunten

[Frank Steggink]

On 1-2-2012 10:44, Ruud den Blanken wrote:
Vorig jaar heb ik OSM rondom Gorinchem aangepast door panden en 
adressen uit de BAG toe te voegen.
Ik had ook de beschikking over postcodes maar die mochten vanwege 
licentiebezwaren nog niet worden toegevoegd.

Vandaag, per 1 februari 2012, mag het wel.

De vraag is nu hoe ik dit het beste kan aanpakken.
Alle adrespunten die ik wil uitbreiden met een addr:postcode tag, 
hebben nu in principe al een tag bag:vbo_id.
Ik kan een lijst genereren van alle verblijfsobject_id's met 
bijbehorende postcodes.


Liefst zou ik hieruit een script met update-query's genereren die ik 
kan loslaten op OSM.
Ik maak voornamelijk gebruik van JOSM en kon geen plugins vinden die 
in dit soort functionaliteit voorzien.

Waarschijnlijk moet ik dit vanuit een andere invalshoek benaderen.

Iemand hints hoe dit aan te pakken?


Met vriendelijke groet,

Ruud den Blanken
Gorinchem


Hoi Ruud,

Zoals je weet, kun je niet zomaar een script met update-queries 
uitvoeren tegen de OSM-database aan ;) Je moet de adrespunten downloaden 
als OSM file, bewerken en vervolgens uploaden. Ik geloof niet dat er 
tools beschikbaar zijn om een join uit te voeren van OSM-data met een 
externe databron. Dit zou je moeten scripten.


Voor upload met JOSM kun je gebruik maken van het eigen file formaat: 
http://wiki.openstreetmap.org/wiki/JOSM_file_format . Dit lijkt erg op 
het standaard OSM XML-formaat. D.m.v. een action-attribuut kun je 
aangeven wat er met de data moet gebeuren. Voorbeeldje:
node id='1608043892' action='modify' timestamp='2012-01-28T00:16:32Z' 
uid='210260' user='jotpe' visible='true' version='1' 
changeset='10517630' lat='52.3024097' lon='7.1756024'

tag k='bag:vbo_id' v='abcdef' /
tag k='addr:housenumber' v='yyy' /
tag k='addr:street' v='xxx' /
tag k='addr:postcode' v='zzz' /
/node

De attributen id, timestamp, uid, user, visible, version, changeset, lat 
en lot zijn standaard-attributen. Deze waren al aanwezig in de download. 
Het action-attribuut geeft aan dat de betreffende node moet worden 
geupdate. De tags geven aan welke tags de nieuwe versie moet hebben. Je 
kunt aan de tags niet zien welke nieuw is, dus je moet gewoon die van 
jou toevoegen.


BELANGRIJK: aangezien je bestaande data wijzigt, zorg ervoor dat je de 
bewerkingstijd zo kort mogelijk houdt! Het heeft dus de voorkeur om 
kleine gebieden tegelijk te updaten, omdat in theorie de kans aanwezig 
is dat anderen tussentijds de data bewerken. Je kunt de database immers 
niet freezen. Dit heeft als gevolg dat jij conflicten moet oplossen 
indien nodig. Dat is zonde van de tijd. Let er dan ook op dat je na een 
upload eerst nieuwe data downloadt, om eventuele wijzigingen mee te pakken.


Mogelijk is in jouw geval FME een optie. Ik ben niet bekend met de 
OSM-writer, maar als je zelf het action-attribuut in het node-element 
weet te krijgen i.p.v. als tag, dan zou het wel eens kunnen werken. De 
andere attributen moeten dan niet wijzigen. Als dit klaar is, zou je de 
wijzigingen met JOSM kunnen uploaden.


Groeten,

Frank


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

Re: [OSM-talk-nl] Postcodes semi-automatisch toevoegen aan adrespunten

[Frank Steggink]

Voordat het import-virus losbarst: wees je er wel van bewust wat voor 
klus dit is! Dit kan ik niet genoeg benadrukken. Elke import is uniek. 
De BAG-import heeft meer voeten in de aarde dan bijv. de 3dShapes 
import. Dit om de volgende redenen:


* Vervanging bestaande data: Ten tijde van de 3dShapes import was NL 
redelijk blanco op het gebied van gebouwen en landgebruik. (De 
AND-landuse was van lage kwaliteit, dus die kon worden verwijderd.) Nu 
staat NL vol met gebouwen uit de 3dShapes. Voor een deel zijn deze ook 
bewerkt / verrijkt met andere data. Je kunt geen import doen zonder hier 
een goede oplossing voor te verzinnen. In het geval de 3dShapes gebouwen 
niet gewijzigd zijn (version=1), zouden deze vervangen kunnen worden. 
Probeer dus eerst inzichtelijk te krijgen welke gebouwen wel problemen 
opleveren, bijv. omdat je tags moet omzetten. Ga eerst in conclaaf met 
andere OSM-ers die wijzigingen aan de gebouwen hebben aangebracht in het 
gebied waarvan je de BAG wil importeren.


* Verantwoordelijkheid: als je aan een import begint, heb je je te 
houden aan de import guidelines. Zie hier: 
http://wiki.openstreetmap.org/wiki/Import_guidelines . Als jij zelf 
BAG-data wil importeren, heb jij je _zelf_ hier aan te houden, omdat de 
import onder _jouw_ account zal plaatsvinden. Je bent dus ook 
verantwoordelijk voor eventuele troep die je achterlaat. Natuurlijk ga 
je die ook zelf opruimen ;) De rest van de community zit hier niet op te 
wachten. Vraag je eerst af of je bereid bent je hieraan te committen. 
Zie ook het volgende punt.


* Updates: al aangestipt. Zeker zinvol om over na te denken, maar het 
probleem hier is dat dit niet af te dwingen is. Iemand kan ergens de BAG 
importeren en plechtig beloven zich te committen aan updates, maar als 
hij een andere hobby heeft gevonden, zijn er ook geen updates meer.


* Nut: wat is de toegevoegde waarde van de BAG in OSM? De adressen 
ontbreken in OSM, wat handig is voor routing, e.d., maar er zijn al wel 
gebouwen. IMO zijn deze van voldoende kwaliteit voor de meeste 
toepassingen van OSM. Ik wil natuurlijk in mijn gebied wel de best 
beschikbare data, maar ik weet ook al dat, als ik een mooie kaart van NL 
ga maken, ik de BAG data wel uit de originele bron ga betrekken en niet 
uit OSM. Dit omdat de BAG zelf de beste bron is. Wie weet wat er met de 
OSM data is gerommeld is en wat de actualiteit is? Zelfs al loopt OSM 
voor (wat heel goed mogelijk is), je kunt niemand binnen OSM aanspreken 
als de situatie niet klopt. Het standaardantwoord: pas het lekker zelf 
aan. In de GIS-wereld loopt al enige jaren de discussie tussen 
authoritive data vs. crowdsourced data, wat hierop betrekking heeft.


Het bovenstaande punt geldt trouwens ook voor de landuse. Ja, in die zin 
heb ik maanden vrije tijd voor niks besteed, maar toen was ook niet 
bekend dat de Top10NL open data zou worden. Mijn handen jeuken totaal 
niet om Top10NL in OSM te laden. Hooguit om de 3dShapes data ten dele te 
verrijken, om fouten met de classificaties ongedaan te maken. Bij de 
3dShapes-import is i.i.g. hier wel zoveel mogelijk rekening gehouden en 
tijd ingestoken.


* Afhankelijkheid van anderen: er wordt wel geroepen dat er moet worden 
nagedacht over zaken of dat er iets beschikbaar moet komen, maar wie 
gaat daadwerkelijk tijd en serverruimte vrij maken om dit ook te 
regelen? Is het reëel om te verwachten dat anderen dit klusje voor jou 
gaan klaren? We zijn allemaal vrijwilliger en 99,9% van ons heeft ook 
andere dingen te doen.


Zelf ben ik er nog niet uit of ik mijzelf wil committen aan de BAG. 
Zoals gezegd wil ik in de gebieden die mijn meeste interesse hebben wel 
de beste data, maar aan de andere kant zie ik op tegen het integreren 
met de bestaande data en het blijvend actualiseren. Ik kan alleen 
constateren dat de behoefte om delen van de BAG te importeren eerder 
afneemt dan toeneemt. Dit zeg ik zowel met de OSM- als met de werk-pet op.


Zo, dat was het wel voor deze keer :)

Groeten,

Frank

On 1-2-2012 17:44, Floris Looijesteijn wrote:

Ik wil dit ook wel doen voor Haarlem maar laten we in ieder geval een procedure
bedenken voor hoe we omgaan met updates.

Waar TS dus nu tegenaan loopt zou je ook als update kunnen zien.

Groet,
Floris

2012/2/1 Robert Elsenaarrob...@elsenaar.info:

+1


Met vriendelijke groeten,
Robert Elsenaar
(Verzonden vanaf Mobile)


drekd...@drek.nl  schreef:


Op 01-02-12 11:49, Floris Looijesteijn schreef:

2012/2/1 Ruud den Blankenruud.den.blan...@gmail.com:

Vorig jaar heb ik OSM rondom Gorinchem aangepast door panden en adressen
uit
de BAG toe te voegen.

Maar die import ziet er best mooi uit, is dat ergens gedocumenteerd?

Die import ziet er zeker mooi uit. Ik wil de BAG-gegevens ook toevoegen
in mijn woonplaats Woudenberg, maar ik weet eerlijk gezegd nog niet
precies hoe. Ik ben dat nu aan het uitzoeken hoe dat werkt. Een
gedocumenteerde import zou dus zeer van pas kunnen komen. :-)

Groeten, André

Re: [Talk-ca] canvec data offset

[Frank Steggink]

I've seen some of these deviations as well during Canvec import. Because 
they are so small ( 1 meter), I just decided to glue the polygons 
together, so any slivers are gone.


It is inconvenient though. Could it be related to that some sheets were 
originally still in NAD27, instead of NAD83 (which is approximately 
WGS84, as used by OSM)?


Frank

On 31-1-2012 15:06, michael bishop wrote:

the south east corner of 021O10.0 is at 47.534 by -66.7500013
the north east corner of 021O07.1 (should be exact same node), is at 
47.500 by -66.750
the exact offset differs from corner to corner, some are off more then 
others, some are off in a different direction



On 01/31/2012 08:11 AM, Bégin, Daniel wrote:

Bonjour,

I'll have a look to see if I can do something for it in the next 
release.


I suspect that might be caused by data resolution. Lat and Lon are 
stored in decimal degrees with 7 digits precision (48.1234567). The 
7th digit will provide a precision around 0.001 meter. The 6th digit 
a precision around 0.027 meter witch look like your 0.03 meter.


Cheers
Daniel

-Original Message-
From: michael bishop [mailto:cle...@nbnet.nb.ca]
Sent: January 30, 2012 16:11
To: Talk-CA OpenStreetMap
Subject: [Talk-ca] canvec data offset

ive been working with canvec for a few days now, and ive noticed some 
of the data is offset by 0.03 meters its not matching up with nearby 
tiles


for example 021O10 doesnt match up with 021O07

ive noticed the problem on other tiles aswell, but didnt think to 
write them down



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




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




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

Re: [OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen

[Frank Steggink]

Goede zaak, nu lopen we mijlenver voor op de kaartjesconcurrent, die de 
vorige, verouderde situatie zelfs niet goed had! Viva crowdsourcing :)


Frank

On 28-1-2012 19:10, Colin Smale wrote:
Hij is open! Ben er net twee keer doorheen gereden. Ik heb de tunnel 
in OSM al geopend, samen met de nieuwe afrit 8 die ook al open is. 
Ik ga straks even een viertal GPS tracks ertegenaan leggen.


De oude, tijdelijke rijbaan ligt er natuurlijk nog steeds, en is zelfs 
nog een klein beetje open middels een doorsteek van de hoofdrijbaan 
voor verkeer vanuit Breukelen naar Utrecht-Centrum moet (want de 
parallelrijbaan is t.h.v. Maarssen nog eventjes gesloten). Ik geloof 
dat het de bedoeling is dat de situatie na dit weekend redelijk op de 
definitieve zal lijken - dan zal die doorsteek ook weg zijn. Op dit 
moment heb ik de oude rijbaan omgetagd in service maar afhankelijk 
van hoe het er maandag uitziet kan die weg of naar construction of 
wat dan ook.


Colin

On 24/01/2012 19:26, Frank Steggink wrote:
Voor wie het heeft gemist, binnenkort zal eindelijk een stuk 
highway=construction; construction=motorway van de kaart [1] 
verdwijnen en worden omgezet naar een highway=motorway. Vorige week 
is besloten om de Leidsche Rijntunnel in gebruik te nemen. Zie [2] 
voor meer info. De hoofd- en parallelbanen zullen gefaseerd in 
gebruik worden genomen, te beginnen met de meest westelijke 
tunnelbuis (lokaal verkeer van noord naar zuid). Deze wordt a.s. 
weekend aangepast, zodat deze geopend kan worden. De overige 
weekenden zijn 17 t/m 20 februari, 13 t/m 16 april en 15 t/m 18 juni.


Als iemand in de buurt van Utrecht in de gelegenheid is de situatie 
te checken na a.s. weekend, dan graag. Mij gaat het pas het weekend 
erop lukken.


Groeten,

Frank


[1] http://osm.org/go/0E6Dnlli-
[2] 
http://rijkswaterstaat.nl/actueel/nieuws_en_persberichten/2012/januari2012/a2_leidsche_rijntunnel_in_vier_weekenden_geopend_start_eind_januari.aspx


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



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




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

[OSM-talk-nl] Leidsche Rijntunnel (A2 Utrecht) wordt eindelijk in gebruik genomen

[Frank Steggink]

Voor wie het heeft gemist, binnenkort zal eindelijk een stuk 
highway=construction; construction=motorway van de kaart [1] verdwijnen 
en worden omgezet naar een highway=motorway. Vorige week is besloten om 
de Leidsche Rijntunnel in gebruik te nemen. Zie [2] voor meer info. De 
hoofd- en parallelbanen zullen gefaseerd in gebruik worden genomen, te 
beginnen met de meest westelijke tunnelbuis (lokaal verkeer van noord 
naar zuid). Deze wordt a.s. weekend aangepast, zodat deze geopend kan 
worden. De overige weekenden zijn 17 t/m 20 februari, 13 t/m 16 april en 
15 t/m 18 juni.


Als iemand in de buurt van Utrecht in de gelegenheid is de situatie te 
checken na a.s. weekend, dan graag. Mij gaat het pas het weekend erop 
lukken.


Groeten,

Frank


[1] http://osm.org/go/0E6Dnlli-
[2] 
http://rijkswaterstaat.nl/actueel/nieuws_en_persberichten/2012/januari2012/a2_leidsche_rijntunnel_in_vier_weekenden_geopend_start_eind_januari.aspx


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

Re: [OSM-talk-nl] NLExtract project

[Frank Steggink]

On 23-1-2012 21:27, Michiel Faber wrote:

Just van den Broecke schreef op ma 23-01-2012 om 10:33 [+0100]:


Dit zijn o.a. de gotchas waar ik in een eerdere mail op doelde. En
mogelijk zijn er die ik nog niet ken.

groeten,

Just

Hallo,

Ik spui hier zomaar wat vragen die in mij opkomen omtrent de top10.
Dit zijn zo maar dingen die in mij opkomen. Wellicht al bij jullie
opgekomen, niet relevant of al in overleg met het kadaster.

Weet het Kadaster van deze gotchas?
Zijn ze bewust er in gebracht?
Hoe gaan zij er mee om?
Wellicht een idee om er met hun over te praten om de brondata al in een
beter formaat (aangeleverd) te krijgen of hun manier van werken te
bekijken?

Succes,
Michiel


Michiel,

De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze 
zijn bewust ingebracht. Dit is gebaseerd op GML (geography markup 
language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en 
geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als 
doel uitwisseling van ruimtelijke data in Nederland. Dit model is 
behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld. 
Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al de 
mogelijkheid om meerdere geometrieën aan een object te koppelen (bijv. 
oppervlakte en hartlijn van een weg), of om meerdere attributen met 
dezelfde naam toe te voegen (bijv. wegnummers: een weg kan meerdere 
wegnummers hebben). Het doel is om de informatie zo compleet mogelijk op 
te slaan en uit te wisselen. Het is aan de gebruikers hiervan om te 
bepalen welke data wel of niet getoond wordt.


Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet 
voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing 
voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de 
splitsings-stap nodig. Uitlevering in een ander formaat lost het 
probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie 
ongeschonden door te laten. De data zoals die door het Kadaster wordt 
uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker iets 
mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De reden dat 
het NLExtract project is opgestart is juist om deze bewerkingsslag te 
maken en afgeleide producten te genereren, bijv. database-dumps voor 
PostgreSQL/PostGIS en Oracle. Dit is geen verantwoordelijkheid van het 
Kadaster. De markt kan het prima oplossen. (Het Kadaster levert wel de 
data in FGDB uit, maar waarschijnlijk komt dat omdat dit een 
tussenproduct van hun eigen werkproces is.) O.a. op LinkedIn in de NL 
OpenData groep is hierover discussie gevoerd.


Andere gotcha's zijn niet bewust:
* Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is 
omheen te werken, door bijv. de GFS-bestanden te editen.
* Niet-validerende GML: ik heb begrepen dat het Kadaster hier 
ondertussen van op de hoogte is. In april zou een goede versie moeten 
komen. (Kan geen linkje vinden.)
* Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat 
ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten 
oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken 
waar geen dubbelingen in voorkomen.

Voor de rest moeten we zien waar het schip strandt ;)

Groeten,

Frank

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

Re: [OSM-talk-nl] NLExtract project

[Frank Steggink]

On 23-1-2012 21:58, Frank Steggink wrote:

Michiel,

De meeste gotcha's zijn inherent aan het datamodel van Top10NL, dus ze 
zijn bewust ingebracht. Dit is gebaseerd op GML (geography markup 
language). Op basis hiervan is door Geonovum NEN3610 ontwikkeld en 
geïmplementeerd in GML (via een XML Schema-definitie). Dit heeft als 
doel uitwisseling van ruimtelijke data in Nederland. Dit model is 
behoorlijk complex. Top10NL is weer op basis van NEN3610 ontwikkeld. 
Volgens mij is dit alleen door het Kadaster gedaan. NEN3610 biedt al 
de mogelijkheid om meerdere geometrieën aan een object te koppelen 
(bijv. oppervlakte en hartlijn van een weg), of om meerdere attributen 
met dezelfde naam toe te voegen (bijv. wegnummers: een weg kan 
meerdere wegnummers hebben). Het doel is om de informatie zo compleet 
mogelijk op te slaan en uit te wisselen. Het is aan de gebruikers 
hiervan om te bepalen welke data wel of niet getoond wordt.


Dit heeft als consequentie dat de tooling aan behoorlijke eisen moet 
voldoen. ogr2ogr komt een heel eind, maar niet overal is een oplossing 
voor. Bijv. de meerdere geometrieen per object: hiervoor is dus de 
splitsings-stap nodig. Uitlevering in een ander formaat lost het 
probleem niet 1-2-3 op. Bijv. Shape is te beperkt om alle informatie 
ongeschonden door te laten. De data zoals die door het Kadaster wordt 
uitgeleverd is ook geen eindproduct waar een willekeurige gebruiker 
iets mee kan. Daarvoor moet er nog een bewerkingsslag overheen. De 
reden dat het NLExtract project is opgestart is juist om deze 
bewerkingsslag te maken en afgeleide producten te genereren, bijv. 
database-dumps voor PostgreSQL/PostGIS en Oracle. Dit is geen 
verantwoordelijkheid van het Kadaster. De markt kan het prima 
oplossen. (Het Kadaster levert wel de data in FGDB uit, maar 
waarschijnlijk komt dat omdat dit een tussenproduct van hun eigen 
werkproces is.) O.a. op LinkedIn in de NL OpenData groep is hierover 
discussie gevoerd.


Andere gotcha's zijn niet bewust:
* Afkappen van velden: dit is iets wat ogr2ogr blijkt te doen. Hier is 
omheen te werken, door bijv. de GFS-bestanden te editen.
* Niet-validerende GML: ik heb begrepen dat het Kadaster hier 
ondertussen van op de hoogte is. In april zou een goede versie moeten 
komen. (Kan geen linkje vinden.)
* Sommige objecten zijn dubbel als je alles importeert. Dit komt omdat 
ze over de bladgrenzen heen liggen. Dat zullen we met de hand moeten 
oplossen, tenzij het Kadaster een set landsdekkende GML's gaat maken 
waar geen dubbelingen in voorkomen.

Voor de rest moeten we zien waar het schip strandt ;)


Een andere gotcha waar ik bang voor was, nl. meertaligheid, zit ook in 
Top10NL. Zie bestand 06west.gml.


top10nl:GeografischGebied gml:id=nl.top10nl.103078931 
nen3610:identificatieNL.TOP10NL.103078931/nen3610:identificatie
nen3610:objectBeginTijd2008-11-24T00:00:00/nen3610:objectBeginTijdnen3610:versieBeginTijd2008-11-24T00:00:00/nen3610:versieBeginTijd
top10nl:naam xml:lang=nlLeeuwarden/top10nl:naam
top10nl:naam xml:lang=fyLjouwert/top10nl:naam
top10nl:typeGeografischGebied plaats, bewoond 
oord/top10nl:typeGeografischGebied
top10nl:labelPuntgml:Point 
srsName='urn:opengis:def:crs:EPSG::28992'gml:pos 
srsDimension=2182596.785 
579147.489/gml:pos/gml:Point/top10nl:labelPunt

top10nl:brontypetop10vector/top10nl:brontype
top10nl:bronbeschrijvingTOP10vector 2004/top10nl:bronbeschrijving
top10nl:bronactualiteit2004-01-01/top10nl:bronactualiteit
top10nl:bronnauwkeurigheid2/top10nl:bronnauwkeurigheid
top10nl:dimensie2D/top10nl:dimensie
/top10nl:GeografischGebied

De naam Leeuwarden komt ook in het Fries voor, Ljouwert (met 
xml:lang=fy).


Frank

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

[OSM-talk-nl] PDOK deels openbaar

[Frank Steggink]

Sorry voor de crosspost en het is laat, maar ik heb eigenlijk op beide 
lijsten het nieuws gemist dat een aantal open-data datasets vanaf 
vandaag via PDOK op te vragen zijn. Just attendeerde me gisteren hierop.


Nieuws van Geonovum: 
http://www.geonovum.nl/nieuws/pdok/open-data-publieke-dienstverlening-op-kaart

Demoviewer: http://nieuwsinkaart.nl/pdok/
Info voor het fair use gebruik: 
http://www.geonovum.nl/dienstenniveau/PDOK-Fair-Use


Deze service wordt as is ter beschikkingg esteld. Misschien is het een 
idee voor een nieuw projectje om op de osgeo.nl wiki-site documentatie 
te zetten? Het is voor mij nu te laat om nog het veld op te rennen om te 
voetballen :)


Groeten,

Frank Steggink



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

Re: [OSM-talk-nl] Fwd: [OpenStreetMap] ODBL licentie wijziging OSM

[Frank Steggink]

On 21-1-2012 11:39, Pim Clotscher wrote:
Ik ben nieuw op deze mailinglijst, maar al geruime tijd actief op het 
forum en als mapper voor OSM.Mijn overtuiging is altijd geweest dat 
het forum het geijkte medium was (is??) om de mappers te bereiken en 
ook om daar de discussie te voeren over o.a. de licentie-wijziging. 
Ben benieuwd  hoe dat dan gaat via deze lijst die me aangeraden is 
nadat ik iemand een PB had gestuurd met een uitnodiging om akkoord te 
gaan met ODbL (sommigen vatten zoiets op als spam...) :-) .

Pim

On 21-1-2012 0:57, Maarten Deen wrote:

Op 21-01-12 00:13, Cartinus schreef:

Als je de afzenders van deze berichtjes werkelijk wilt bereiken
dan kun je dat beter doen op een plek waar ze het lezen: het
forum.


Is er eigenlijk een tweedeling? Zij de het forum gebruiken en zij die 
de mailinglijst gebruiken? Ik gebruik het forum eigenlijk niet. Ik 
zou nog niet eens weten waar het is. En waarom zou ik aannemen dat de 
afzenders van die berichten wel op het forum zitten maar niet op de 
mailinglijst? Is dat een ander soort mapper die daar zit?


Er is geen geijkt medium om mappers te bereiken. Zowel het forum als de 
mailinglijst zijn plekken waar discussies gevoerd worden. De een voert 
liever discussie in een browser, terwijl de ander dat liever via zijn 
mailclient doet. Ikzelf vind daar niks mis mee.


OpenStreetMap is niets meer dan een project waar veel mensen zich mee 
verbonden voelen, waardoor ook een heel ecosysteem aan discussieplekken 
(mailinglijsten, fora, wiki, blogs, irc) is ontstaan, naast het 
ecosysteem van software. Er is wel een groep mensen die zich heeft 
opgeworpen om het officiële orgaan van OSM te zijn (de OSMF), maar 
zelfs deze organisatie wordt door sommigen niet als zodanig erkend. Dit 
alles maakt het lastig om goed op de hoogte te blijven van alle 
gebeurtenissen. Voor velen is dat ook niet te doen. Daarvoor is het 
project veel te groot geworden (waar ik op zich blij om ben :) ).


Maarten, het forum bestaat al bijna 5 jaar. Hier is de link: 
http://forum.openstreetmap.org/viewforum.php?id=12 , ook te bereiken via 
forum.openstreetmap.nl . Ik denk niet dat er sprake is van een 
tweedeling, maar ik heb wel de indruk dat degenen die op het forum 
zitten meer zijn geinteresseerd in het gebruik van OSM en minder in de 
techniek. Ofwel, de Nederlandse OSM-community is twee keer zo groot dan 
je denkt :)


Frank

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

Re: [OSM-talk-nl] Mappers en 'Kadaster geeft gigabytes aan data vrij'

[Frank Steggink]

On 6-1-2012 17:39, drek wrote:

Hallo allemaal,

Wat mij nog niet helemaal duidelijk is, is wat dit betekent voor de 
gebruikers. Ik heb diverse aanpassingen in de kaart gedaan en heb nog 
wat aanpassingen op mijn to-do-lijstje staan. Zijn deze aanpassingen 
nog wel nodig als er Kadaster-informatie gebruikt gaat worden? En wat 
gebeurt er met bestaande data?


Groeten, André

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


Hallo Andre,

Voorlopig betekent dit helemaal niks voor de OSM-vrijwilligers. Er zijn 
geen grootscheepse plannen om Top10NL data te importeren in OSM. 
Voorlopig kan dat ook niet, omdat OSM binnenkort volledig overgaat op de 
ODbL. Vraag is of het Kadaster hiermee akkoord gaat. ODbL kent wel 
attribution (bronvermelding), maar de licentie zou in de toekomst 
kunnen veranderen.


Mocht die toestemming er zijn, dan vind ik dat we hier heel hard over 
moeten nadenken of we dit wel willen. Het is nl. een rotklus, met een 
marginale toegevoegde waarde. De 3dShapes dataset die de afgelopen jaren 
is geïmporteerd, is een afgeleid product van Top10vector (de voorloper 
van Top10NL). Qua geometrie is er geen verbetering, maar qua 
classificatie zou die er wel kunnen zijn. Het is makkelijker om een 
hybride kaart te gebruiken (voor visualisatie, gebruik in de GPS, etc.), 
die zowel op OSM als op Top10NL is gebaseerd.


Voor de BAG (Basisregistratie Adressen en Gebouwen), wat ook speelt, 
ligt dit iets genuanceerder. Ik was een paar maanden geleden wel 
voorstander van een import, maar ben hierover van gedachten aan het 
veranderen. Ondanks dat de BAG open data is, is het lastig om hieraan te 
komen. In theorie heb je een abonnement nodig, alhoewel het feit dat de 
BAG open data is, ook betekent dat het verder verspreid kan worden (tot 
1 feb. a.s. nog m.u.v. postcodes). In OSM zitten al gebouwen, die voor 
het schaalniveau van OSM van voldoende kwaliteit zijn. (Dit geldt 
natuurlijk niet voor nieuwbouw.) Van alleen de adressen is de 
toegevoegde waarde veel hoger, i.v.m. routing, etc. Het wordt wel een 
klus om in de pas te blijven lopen met de maandelijkse levering. Ook 
moeten zaken goed worden gecoördineerd. Hier is een paar maanden geleden 
wel op talk-nl over gesproken, maar dit heeft nog geen concreet 
resultaat opgeleverd.


Groeten,

Frank

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

[OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland

[Frank Steggink]

Zie: 
http://www.inoverheid.nl/artikel/nieuws/3083157/nederland-telt-weer-minder-gemeenten.html?utm_campaign=rssutm_source=rssutm_medium=rss
Het gaat hierom: De gemeente Hollands Kroon - een samenvoeging van de 
voormalige gemeenten Anna Paulowna, Niedorp, Wieringen en Wieringermeer 
- is de jongste fusiegemeente in Nederland.


Is hier al iemand mee bezig?

Frank

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

Re: [OSM-talk-nl] Gemeentelijke herindeling in Noord-Holland

[Frank Steggink]

On 6-1-2012 20:09, Lennard wrote:

On 6-1-2012 18:19, Frank Steggink wrote:


Het gaat hierom: De gemeente Hollands Kroon - een samenvoeging van de
voormalige gemeenten Anna Paulowna, Niedorp, Wieringen en Wieringermeer
- is de jongste fusiegemeente in Nederland.

Is hier al iemand mee bezig?


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

http://woonplaatsgrenzen.openstreetmap.nl/?zoom=10lat=52.86994lon=5.00638layers=B0F 



Was OSM weer de snelste met de updates op de kaart? :-)



Ook deze update was wel een persmomentje waard ;)
Shame on me dat ik niet eens de moeite nam om het in de kaart te checken!

Frank

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