Re: [OSM-talk-be] 'losse' wegen

[Tim Couwelier]

Het is een gevalletje van 'taggen voor de render'.
De mapper in kwestie is aan het micro-mappen geweest (maar is er gelukkig
wel consistent in geweest), en heeft ze als highway = footway getagd,
terwijl dat helemaal niet nodig was.

Ik gok overigens dat (doordat de kleur vrij dicht aanleunt bij die van een
residential landuse) het effect visueel knal hetzelfde was geweest zonder
ze toe te voegen.

Corrigeren zou kunnen door ze in bulk te selecteren in JOSM en dan zo in 1x
de tag van alle geselecteerde objecten aan te passen, alleen weet ik
eerlijkheidshalve ook niet zo zeer naar wat je ze zou aanpassen dan.
'Private verharding' zonder te specifiëren wat, daar ken ik niet meteen een
gepaste tag voor.

Op ma 21 dec. 2020 om 08:31 schreef joost schouppe :

> Dag Meannder,
>
> De oorzaak lijkt me dat iemand al de opritten heeft ingetekend als vlak,
> maar zonder ze te verbinden met de rest van de weginfrastructuur. Dat ziet
> er wel mooi uit, maar het is volstrekt zinloos voor navigatie. En als je
> dus een woning hebt die nabij verschillende wegen ligt, dan gaat de oprit
> niet helpen om dichter bij je bestemming gestuurd te worden. Alleszins is
> de foutmelding wel terecht: er zijn hier talloze verkeerseilandjes
> gecreëerd.
>
> Mvg,
> Joost
>
> Op zo 20 dec. 2020 18:44 schreef meannder :
>
>> Dag-ga-dag,
>>
>> In Zwevezele zijn, al een aantal maanden, ontelbaar veel
>> 'niet-verbonden' wegen te zien op
>>
>> https://www.keepright.at/report_map.php?zoom=16=51.0357=3.2121
>>
>> Zijn dit schoonheidsfoutjes -toch niet te zien op de map-, de moeite om
>> op te lossen  en desgevallend... HOE (zonder uren werk)?
>>
>> groet, meannder
>>
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] De kaainummers van de haven van Gent.

[Tim Couwelier]

Phillipe,

Ze zijn beschikbaar als open data:
https://data.stad.gent/explore/dataset/kaainummers-north-sea-port/export/?flg=nl
Je kan nog kiezen in welk formaat.



Op wo 21 okt. 2020 om 09:59 schreef Philippe Casteleyn <
philippecastel...@hotmail.com>:

> Dit is al mijn derde poging na Facebook en het OSM forum.
>
> Waar vind ik de kaainummers van de Gentse haven ?
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] waymarked or not?

[Tim Couwelier]

ey should definitely be put in their own data model." They're
>>> still local/regional/... hiking/cycle/... routes. Adding some tag like
>>> 'virtual=yes" on the route relations and nodes should suffice. (It will be
>>> a bit more complicated because a node can be both a virtual hiking node and
>>> a real cycle node.)
>>>
>>> Regards,
>>>
>>> StijnRR
>>>
>>> On Monday, October 19, 2020, 07:34:48 PM GMT+2, Steven Clays <
>>> steven.cl...@gmail.com> wrote:
>>>
>>>
>>> Tendency in Toerisme Vlaanderen > ALL hiking nodes will go virtual
>>> within 10 years or so. (At least, that is their vision) So if you do not
>>> follow this tendency, you make OSM irrelevant for routes. I'd make a
>>> thorough choice in the official operators AND their choices. Eg. Natuurpunt
>>> DOES stick to signposting AFAIK.
>>>
>>> Op ma 19 okt. 2020 om 14:47 schreef Matthieu Gaillet <
>>> matth...@gaillet.be>:
>>>
>>>
>>> Wether they are following another route is not relevant since it’s a
>>> separate relation.
>>>
>>> Matthieu Gaillet
>>>
>>> On 19 Oct 2020, at 14:33, Wouter Hamelinck 
>>> wrote:
>>>
>>> Are there any EV routes in Belgium that are not also LF or RV?
>>>
>>> Wouter
>>>
>>> On Mon, 19 Oct 2020, 12:29 Matthieu Gaillet, 
>>> wrote:
>>>
>>> Things are actually much less obvious and deserve a real second thought
>>> before taking position : it just came up to my mind that much of the
>>> Eurovelo network is still currently completely virtual (work in progress),
>>> yet deleting in from our map would be totally irrelevant since this routes
>>> are actually existing by the simple fact that thousands of users are using
>>> it.
>>>
>>> Matthieu Gaillet
>>>
>>> On 13 Oct 2020, at 19:21, joost schouppe 
>>> wrote:
>>>
>>> I think we shouldn't actively map purely virtual routes. But there's a
>>> lot of info that only lives on paper and still is relevant to OSM. So I
>>> find it hard to give it a hard no. What is essential though, is that we
>>> don't make a mess of the tagging. A route, right now, is something you can
>>> expect to see waymarked. If someone starts mapping virtual routes, they
>>> should definitely be put in their own data model.
>>>
>>> Op di 13 okt. 2020 om 13:27 schreef Matthieu Gaillet <
>>> matth...@gaillet.be>:
>>>
>>>
>>> That might be true but apply as well to signposted trails on the fled…
>>> I’m not fully convinced.
>>>
>>> But it is true that other websites or apps are specialised into
>>> publishing “virtual" trails and that might be something pertaining to the
>>> OSM project.
>>>
>>> Matthieu Gaillet
>>>
>>> On 13 Oct 2020, at 13:20, Wouter Hamelinck 
>>> wrote:
>>>
>>> Hi all,
>>>
>>> I follow those who propose to limit ourselves for the mapping purposes
>>> to what is waymarked on the ground.
>>> Taking routes from other sources (be they official or not) makes
>>> everything so fluid that we will end up with a huge mixed bag of gpx files
>>> that were at some point in time on some website of an authority, routes
>>> that are actively promoted, routes that were actively promoted for some
>>> event a few years ago and still can be found somewhere but are no longer
>>> maintained, routes where nobody really knows where they come from but they
>>> sound kind of official...
>>> It will get messy...
>>>
>>> Wouter
>>>
>>> On Tue, 13 Oct 2020, 09:51 Francois Gerin, 
>>> wrote:
>>>
>>> +1 for the "end user's perspective".
>>>
>>> From my point of view, two key rules make the ground for OSM as pointed
>>> out in several places of the documentation:
>>>
>>> 1. Think to end users
>>>
>>> 2. Map what really exists
>>>
>>> "Map what really exists" is visible in many places in the docs, and this
>>> is indeed important, up to some "threshold".
>>> "Think to the end users" is much less visible, but is visible anyway.
>>>
>>> I'm afraid that, being driven mostly by technical profiles/mappers, the
>>> "Map what exists" rule seems to take the precedence because it is more
>>> visible.
&g

Re: [OSM-talk-be] waymarked or not?

[Tim Couwelier]

I'm inclined to go by 'mapping verifiable ground truth'. Which means no -
don't add them unless signposted along the way.

Op di 13 okt. 2020 om 08:45 schreef s8evq :

> I do not think they should be in OSM, and I wouldn't mind deleting them. :)
>
> First of all, they are harder to keep up to date and verify.
> Secondly, like you said, where do you draw the line. Who's routes do we
> add and who's not?
>
> For example, Natuurpunt and some of the local tourism offices already have
> 'virtual' hikes, where they only suggest which node numbers to combine. On
> the ground, nothing is marked. I don't think this should be in OSM.
>
> If I get this correctly, 'Randonnées en Boucle' (SGR) are hikes made out
> of parts of existing GR trails? I wouldn't add that. The possibilities are
> just endless...
>
> On Mon, 12 Oct 2020 19:57:59 + (UTC), Stijn Rombauts via Talk-be <
> talk-be@openstreetmap.org> wrote:
>
> > Hi,
> >
> > There is a guideline or rule that only waymarked hiking/cycle/... routes
> should be added to OSM. Not everyone agrees and there are some
> non-waymarked routes in OSM because nobody, not even me, dares to remove
> them.
> > Anyway, that rule/guideline is getting in trouble because some official
> routes are not waymarked anymore.
> > Provincie Vlaams-Brabant enlarged the 'wandelnetwerk Getevallei', but
> the new nodes and routes are not waymarked anymore (too expensive). But
> there is a map, a website and an app. [1]
> > The municipality of Profondeville has the project '1000 bornes' (40
> parcours pour vélos de route et VTT): only gps-tracks on route-you. [2]
> > More will probably follow (or perhaps already exist).
> >
> > So, what do we do? Or where do we draw the line? Because the line
> between what can be considered as official routes or not, could (in the
> future) become very thin. Or what do we do with the 'Randonnées en Boucle'
> (SGR)? What if Natuurpunt/Natagora starts with 'virtual' walking routes?
> >
> > What is your opinion?
> >
> > Regards,
> >
> > StijnRR
> >
> > P.S. The new map of 'wandelnetwerk De Merode' has OSM as background
> layer. Thanks to everyone who contributed.
> >
> > [1] https://www.toerismevlaamsbrabant.be/pagina/werken-wandelnetwerken/
> > [2] https://www.profondeville.be/loisirs/sport/1000bornes
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fietsstraatzones in Leuven and a question about zones inside zones

[Tim Couwelier]

F4a should remain yes, despite both implying the same speed limit, UNLESS
the local gov removed the F4a signs due to the 'fietszone' completely
overlapping with the 'zone 30'.
Ideally, for the 'zone 30', differentiate between 'normal' with F4a only
and 'school- zone 30'  (F4a + A23)

If there's living streets within, I'd say the restrictions 'stack': no
overtaking, 20 km/h.
There may actually be a slight nuance here - generally in case of possible
contradiction, the rule applies 'traffic sign takes priority over traffic
rules'. The speed limits in both fietszone and living_street are traffic
rules, but this might leave a loophole where 'zone 30' as a sign takes
priority.

There used to be a loophole where a C43 70km/h would trump the 50km/h speed
limit in a built up area until the first intersection (extent of the
validity for the C43) but afaik that's been 'patched' in legislation now.
This might just be an unforeseen edge case opening another such loophole,
although I'm not 100% sure on this.


Sidenote: I think I agree with not making a seperate sign for this, but
just giving it a 'zonal' extent. If anything, F4a/b signs existing as such
is confusing. But then again, so were the original streetsigns as they were
semi-assumed to be zonal, but the law wasn't overly specific (and didn't
mention it being zonal). Readability, in database or map format, is far
better if you speak of 'zonal C43' and 'zonal F111' without having to know
another number for the same type of thing.

Op zo 30 aug. 2020 om 14:50 schreef Jo :

> Hi,
>
> I added the new fietsstraatzones in Leuven to the map. They will be in
> vigor on September 1st. The legislator didn't create a separate sign, they
> just decided that it's allowed use F111 on a ZONE sign...
>
> I do like to distinguish between the 'real' cycle streets and the
> 'pretenders', so the ones inside zones and the ones connecting the zones, I
> guess. I used BE:F111zone as the traffic_sign. I may have done something
> silly though, as I removed the F4a from the traffic sign tag.
>
> If you search for F111 you get all.
> If you search for F111zone you get all the ones inside the zones.
> If you search for "F111 -F111zone" in JOSM, you get only the cyclestreets
> with an actual cycle street sign.
>
> If you search for F4a you get all the streets inside the zone30, but the
> cycle streets are not included in that. How do we want to work with zones
> within zones? There are also parking zones...
>
> Should I have put traffic_sign=BE:F111;BE:F4a;BE:F1a ?
>
> Initially I didn't because both are limited to 30km/h, but now I'm
> thinking I should have.
>
> What about the living_street ways? They are also inside the zone30 (and in
> built-up area), but the traffic rules that apply are BE:F12a. Do we add
> BE:F12a;BE:F4a;BE:F1a ?
>
> Jo
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Weggetje verdwenen, hoe terug ?

[Tim Couwelier]

Bijlage bleeft hangen wegens groter dan 80kb, maar hierbij even ter
illustratie hoe je ze kan traceren met de 'skyview' laag.  Is een soort
hoogtemodelweergave op grondniveau, de bomen zie je dus niet.. en het pad
wordt zichtbaar.

https://framapic.org/r01ExtbzPorU/Z1Zri8oU24QM.jpg

(ik had al even afzonderlijk gemaild naar de betrokken persoon, maar
mogelijks zijn er nog mensen waarvoor dit een meerwaarde kan betekenen.)


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

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi Daniel,

I agree with you. I didn't pay attention to the fact that Squamish is 
located in a hilly area.


Greetings from Quebec's flatlands,
Tim

On 2020-03-22 14:16, Daniel @jfd553 wrote:
Hi all, sorry for this long Email.

Thanks to Tim to have comment! He wrote: “I [...] found that you can 
either align the hospital with the underlying imagery or the houses to 
the right of the task, but not both at the same time. [...]  If we 
assume that the aerial imagery data is the correctly projected [...], we 
would have to correct the position of all the buildings according to the 
underlying aerial imagery.”


Well, you are right. Actually, I did not align most of the buildings to 
the image! Why? Because unless proven otherwise, ODB data should be more 
accurate (XY) than most images available, especially in hilly areas.
Municipalities generally use aerial photos to create their maps (ODB 
data). Because these aerial photos provide multiple views of the same 
area, they can be used to compute digital elevation models (DEMs) 
showing even buildings’ height. Only once done, they can create accurate 
ortho-images (orthographic view [1]). Without an accurate DEM, objects 
location on an image is not accurate either, because we are in a 
perspective view [1].
The DEMs used to create available OSM images generally do not have a 
sufficient accuracy in mountainous areas. This is the case of the 
Squamish area where the image shows many examples of perspective views 
[1]. In flat areas, this effect is minimal, which makes it possible to 
adjust an image over a large region with a great accuracy. The only 
visible effect is then related to buildings’ height.


Regarding the hospital, it is located on a hill between two plateaus. 
The image can be adjusted with a good accuracy on the flat area near the 
river, or on the plateau on the top of the hill (potentially with 
another offset), but it is more difficult in between. I tried to adjust 
its geometry (details) from its original ODB location.


I adjust the image to surrounding buildings when I need to map a new one 
or add details to an existing one. I may also look at available GPS 
tracks to confirm general ODB data location.


Thanks again. Comments?
Daniel

[1] https://en.wikipedia.org/wiki/Orthophoto


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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi Daniel,

I had a brief look at project #173, task #20 and found that you can 
either align the hospital with the underlying imagery or the houses to 
the right of the task, but not both at the same time (Bing and ESRI bear 
the same effect). This might have to do with different 
projections/coordinate reference systems used by the data provider of 
the buildings and the one used by the aerial imagery provider.
If we assume that the aerial imagery data is the correctly projected (as 
we do as default in OSM, at least for Bing imagery), we would have to 
correct the position of all the buildings according to the underlying 
aerial imagery.


Furthermore, the buildings to be imported seem to have an odd level of 
detail. Some are pretty detailed, some are missing details at all. I did 
not only look at task #20 which you have already worked on, but also 
task #21. Not sure if they were automatically collected or if a bored 
intern had to do this - that would explain the varying quality.


Apart from the location of the buildings, you did a great job, I think.

Unfortunately, I am still working on two other projects in the tasking 
manager at the moment, so, I most probably won't be of much help on 
#173, but who knows, we are all grounded at the moment, aren't we?


Happy mapping,
Tim


On 2020-03-20 10:23, Daniel @jfd553 wrote:
Hi,

I completed more than a dozen tiles of the task #173 (Squamish). That
would be interesting if some of you could validate what I did so far, in
order to adjust the procedure if required.

Thanks.

Daniel


___
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-be] tile.osm.be

[Tim Couwelier]

As I understood from Jonathan, the process isn't fully automated yet. Was
supposedly to get updated on a near-weekly basis, but it must've slipped
from attention.
I'd guess that moving on towards a full automation of the process would go
a long way?

Op di 10 mrt. 2020 om 11:05 schreef rodeo .be :

> Hey all,
>
> I see this tile server has not been updated the last months. Is the future
> of that tile service unsure?
>
> Btw, we asked several organiations to use those tiles in the past (see
> here ):
> "*Met OpenStreetMap Belgium hebben we in samenwerking met een sponsor een
> tile-server optgezet die wel expliciet bedoeld is om te gebruiken in uw
> situatie.*"
>
> I think it would be worth it to keep that service! How can we help?
>
> KR
> Maarten
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[talk-au] Introduction

[Tim P. Firman]

Hi All,

Is there any chance I could get added to the Slack group for 
maptimeoceania.slack.com?

Cheers
Tim

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi John,

As stated before, I don't consider the Microsoft dataset being close to 
the minimum quality requirements I would expect from any automated 
building entry into OSM. If you just want to display buildings, you can 
download the MS dataset and use it right away - no need to import into 
OSM. I think, the MS dataset has value as proof of concept and to count 
the number of buildings in a given area (e.g. to estimate market size 
for roofers, estimate number of persons living there for desaster 
relief, etc.). I also think, when Microsoft feeds its algorithm with 
higher resolution data than they did (I don't recall, but I think they 
only used the regular Bing data) they will probably end up with building 
footprints that will meet our/my quality requirements for import into 
OSM one day.


For me, the value of OSM is having accurate information in terms of tags 
and geometry. Otherwise, we could join Wikimapia; they don't care too 
much about geometry accuracy but emphasize on content/tags of objects. 
Pretty interesting project, but different from OSM.


Cheers,
Tim

On 2020-01-17 10:40, john whelan wrote:
 >first, to add missing buildings (if it were
just for this purpose we could also use the much bigger Microsoft
dataset)

I can't resist.  Does this infer that for parts of the country without
Stat Can data we are happy to import Microsoft dataset buildings as is?
Or would we wish to wait until we have some more imports done before
looking at preprocessing them in some way first.

Thanks John



On Thu, Jan 16, 2020, 10:11 PM Tim Elrick, mailto:o...@elrick.de>> wrote:

I would assume in most cases the imported building footprint will be
more precise than existing data. For me, this would be a reason to
replace already existing objects. However, I think this is a case by
case decision. However, I think it is important to keep tags and
history
of buildings already existent in OSM. This is how I would
read/interpret
the import guideline stated by Nate: "If you are importing data where
there is already some data in OSM, then *you need to combine this data*
in an appropriate way or suppress the import of features with overlap
with existing data." (emphasis added by me)

However, that just means, the import, hence, is nothing easy and could
not be achieve quickly, I would assume. One way of making sure that
this
is dealt with diligently, would be setting the tasking manager to
'experienced mappers only'. We would have to ask James, who is in
charge
of the Canada Tasking Manager, how to edit/set up the 'experienced
mapper role' in the TM. It might be possible to feed in a list of
mappers manually or to set a threshold of objects/changesets that they
must have entered in OSM. However, maybe only mappers who feel
experienced enough to handle the import would contribute to the TM
project anyway and we let everyone judge on their own and don't
restrict
access.

If we were to separate the new and overlapping buildings, I am also
leaning towards Daniel's assessment. I would be afraid to cause more
issues than by doing it all at once (with a reasonable tile size, of
course).

In the end, the main point of importing this specific dataset fulfils
two purposes, in my opinion: first, to add missing buildings (if it
were
just for this purpose we could also use the much bigger Microsoft
dataset), second, to get the best geospatial representation possible in
our OSM database. That means, we defer from using the Microsoft dataset
and use the much higher quality data from the ODB. This also means that
we should replace already existing buildings (yet keeping tags and
history) wherever the ODB footprint is more precise than the
existing one.

Just my two cents here,
Tim

___
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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

I would assume in most cases the imported building footprint will be 
more precise than existing data. For me, this would be a reason to 
replace already existing objects. However, I think this is a case by 
case decision. However, I think it is important to keep tags and history 
of buildings already existent in OSM. This is how I would read/interpret 
the import guideline stated by Nate: "If you are importing data where 
there is already some data in OSM, then *you need to combine this data* 
in an appropriate way or suppress the import of features with overlap 
with existing data." (emphasis added by me)


However, that just means, the import, hence, is nothing easy and could 
not be achieve quickly, I would assume. One way of making sure that this 
is dealt with diligently, would be setting the tasking manager to 
'experienced mappers only'. We would have to ask James, who is in charge 
of the Canada Tasking Manager, how to edit/set up the 'experienced 
mapper role' in the TM. It might be possible to feed in a list of 
mappers manually or to set a threshold of objects/changesets that they 
must have entered in OSM. However, maybe only mappers who feel 
experienced enough to handle the import would contribute to the TM 
project anyway and we let everyone judge on their own and don't restrict 
access.


If we were to separate the new and overlapping buildings, I am also 
leaning towards Daniel's assessment. I would be afraid to cause more 
issues than by doing it all at once (with a reasonable tile size, of 
course).


In the end, the main point of importing this specific dataset fulfils 
two purposes, in my opinion: first, to add missing buildings (if it were 
just for this purpose we could also use the much bigger Microsoft 
dataset), second, to get the best geospatial representation possible in 
our OSM database. That means, we defer from using the Microsoft dataset 
and use the much higher quality data from the ODB. This also means that 
we should replace already existing buildings (yet keeping tags and 
history) wherever the ODB footprint is more precise than the existing one.


Just my two cents here,
Tim

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Hi all,

I understand your concerns, John. However, many mappers might not follow 
talk-ca. So, I guess, Daniel's suggestion to contact them, might work 
better than waiting for them to incidentally check talk-ca.


* More to finding local mappers *
By providing the overpass query I just wanted to share a different way 
of contacting active mappers in your area. The advantage of Pascal's 
Who's around me is that you can see the mappers with lots of changesets, 
ie. presumably experienced mappers. The disadvantage is that these 
changesets do not have to be from the area we are interested in 
(however, with activity center in the last 6 months we at least make 
sure they were working in our area); another disadvantage is that you 
cannot collect the names of the mappers easily (or am I missing 
something here?). The advantage of the overpass query is that you get 
that list of names easily and you can see how many objects they have 
added in your area in the past months. The disadvantage, of course, is 
that we don't know how experienced the mappers are (but maybe this 
doesn't matter).


Anyway, either approach works as Daniel already pointed out. Thanks to 
stevea, I now know that I can share Overpass queries easily:

for a geocoded area:
http://overpass-turbo.eu/s/PM9
for a bounding box:
http://overpass-turbo.eu/s/PMb

* Contacting local mappers *
I suggest we design a template letter on the wiki page that can be send 
out to local mappers that include the everything that Daniel suggested 
in his last message below.


Tim


On 2020-01-15 15:54, Daniel @jfd553 wrote:
Hi John, Tim, and the others :-)
John, I understand your concern and if it was not addressed properly, 
this could block the import again.


IMHO, we just need to make sure that we have done everything reasonable 
to inform the concerned contributors, in order to discuss the import in 
case they do not agree with it. That is why I proposed the following, in 
a previous email, concerning local mappers buy-in…


1- We contact them to explain our intentions by referring to the 
appropriate wiki pages.
2- We wait a week or two for them to respond to nothing, have concerns 
or want to help.

3- Without negative answers, we could proceed to the import.

The point 3 above make sure the project is not stalled in case there is 
no or only a few answers. The identification of local contributors using 
Neis’ tool, or the query Tim Elrick just proposed, are what I consider 
reasonable attempts for contacting the local mappers.


Daniel

-Original Message-
From: Tim Elrick via Talk-ca [mailto:talk-ca@openstreetmap.org]
Sent: Wednesday, January 15, 2020 15:12
To: talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Importing buildings in Canada

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a
list of all users in the time period specified in the area specified.

// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
// I collected users active in the last 6 months, but you can
// change that
node(newer:"{{date:6 months}}")(area.searchArea);
way(newer:"{{date:6 months}}")(area.searchArea);
relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then
'raw data directly from Overpass API'. This will generate a csv. You can
then count the number of times a name appears in your list by using
LibreOffice, R, Python or Excel. This will give you the number of
objects a user entered in the last 6 months.

If I do this for Montreal I end up with 106 names who have contributed
20 objects or more in the last half year or 46 names who have
contributed 100 objects and more.

You can then use https://www.openstreetmap.org/message/new/USERNAME by
replacing USERNAME with the names from the list to contact these users.

For areas where there is no geocodeArea in OSM you can use the
boundingbox query below. First, zoom to the area of interest (i.e. your
bounding box), then paste the following code on the left and export:

// overpass query
[out:csv(::user)];
(
node(newer:"{{date:6 months}}")({{bbox}});
way(newer:"{{date:6 months}}")({{bbox}});
relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others).

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick via Talk-ca]

Hi all,

*a) data hosting*
I can offer to host pre-processed data for the building imports as well.

*b) task manager work units*
I find smaller tasks about 20 minutes each more appealing than 1 hour tasks

*c) checking already existing data*
An added tag would certainly help as you can apply a filter in JOSM then.

*d) finding local mappers*
You can use the following query on http://overpass-turbo.eu/ to get a 
list of all users in the time period specified in the area specified.


// overpass query
[out:csv(::user)];
// replace Montreal by any known location in OSM, or see code below
// for bounding box use
{{geocodeArea:Montreal}}->.searchArea;
(
  // I collected users active in the last 6 months, but you can
  // change that
  node(newer:"{{date:6 months}}")(area.searchArea);
  way(newer:"{{date:6 months}}")(area.searchArea);
  relation(newer:"{{date:6 months}}")(area.searchArea);
);
out meta;
// end overpass query

Copy the query into the left side of the window and click Export, then 
'raw data directly from Overpass API'. This will generate a csv. You can 
then count the number of times a name appears in your list by using 
LibreOffice, R, Python or Excel. This will give you the number of 
objects a user entered in the last 6 months.


If I do this for Montreal I end up with 106 names who have contributed 
20 objects or more in the last half year or 46 names who have 
contributed 100 objects and more.


You can then use https://www.openstreetmap.org/message/new/USERNAME by 
replacing USERNAME with the names from the list to contact these users.


For areas where there is no geocodeArea in OSM you can use the 
boundingbox query below. First, zoom to the area of interest (i.e. your 
bounding box), then paste the following code on the left and export:


// overpass query
[out:csv(::user)];
(
  node(newer:"{{date:6 months}}")({{bbox}});
  way(newer:"{{date:6 months}}")({{bbox}});
  relation(newer:"{{date:6 months}}")({{bbox}});
);
out meta;
// end overpass query

Tim

On 2020-01-15 12:55, Daniel @jfd553 wrote:
Thanks for the quick replies!

Now, about...

*a) Data hosting:*

Thank you James, I really appreciate your offer (and that of others). So
yes, I think hosting pre-processed data in the task manager, for
approved regions, is an attractive offer. When we agree on a
municipality for pre-processing, I will contact you to make the data
available.

BTW, I thought ODB data in OSM format was hosted with the OSMCanada task
manager. I understand that ODB data are currently converted on the fly
when requested?

*b) Task manager work units for import:*

I agree with Nate, ~ 200 buildings or ~ 1,500 nodes would be suitable. I
was thinking at the same importation rate, but for an hour of work. It
seems best to target 20-minute tasks.

*c) Task manager work units for checking already imported data*

According to Nate, it is definitely not faster than actively importing.
We should then keep the above setup (b).

However, what if I add a new tag to pre-processed data indicating if a
building was altered or not by the orthogonalization (and
simplification) process? For instance, /building:altered=no/, would
identify buildings that were not changed by the process and that could
be left unchanged in OSM (i.e. not imported); /building:altered=yes/ for
those who were changed by the process and that should be imported again.
The same pre-processed datasets could then be made available for all
cases. Thoughts?

*d) Finding local mappers:*

I agree with Nate’s suggestion to try contacting the top 10 mappers in
an area. Using the "main activity center" would work for most of the
contributors but selecting other overlays (.e.g. an activity center over
last 6 months) could also work great. As long as we identify who might
be interested in knowing there is an import coming.

Comments are welcome, particularly about the proposal on c)

Daniel


___
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] TagInfo for Canada

[Tim Elrick]

After reading the weeklyOSM, I was thrilled to find TagInfo available 
for Canada as well. Thanks to Geofabrik!


You will get the tags used in Canada:
https://taginfo.geofabrik.de/north-america/canada

If you want to find the tags for your province, just add your province 
like that https://taginfo.geofabrik.de/north-america/canada/quebec



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

[Talk-ca] Importation de bâtiments de la Ville de Montréal

[Tim Elrick]

Bonjour à tous, surtout à Montréal,

Comme la discussion sur les importations de bâtiments au Canada reprend 
de plus belle, je voulais lancer la discussion au niveau local comme une 
retombée de la discussion principale sur talk-ca.


J'ai essayé de poster cela sur la liste de Montréal il y a une semaine, 
mais je n'ai pas pu joindre notre modérateur ni mes autres contacts. 
C'est pourquoi je commence maintenant la discussion ici.


*Source des données pour l'importation*
Je suggérerais de suivre plus ou moins l'importation du bâtiment comme 
décrit sur la page principale du wiki. Cependant, je suggérerais 
d'utiliser les données ouvertes de la Ville de Montréal (puisque nous 
avons le consentement de la Ville pour le faire [1]; comme Simon du LWG 
l'a déclaré ici [2], cela devrait être suffisant pour l'utiliser pour 
l'importation). Je le suggère pour deux raisons : lorsque StatCan a 
produit le jeu de données BDOI, il visait un jeu de données cohérent 
dans tout le Canada. C'est pourquoi il manque à BDOI l'information sur 
la hauteur des bâtiments (1).  De plus, il ne contient que les bâtiments 
confondus lorsqu'il y a des maisons en terrasse. Les séparateurs de 
bâtiments individuels sont fournis par la Ville de Montréal, mais dans 
un autre fichier shapefile. StatCan ne les a pas utilisés pour séparer 
les bâtiments. Par conséquent, nous obtiendrions des bâtiments de 
qualité inférieure lorsque nous utiliserions le BDOI (2). En dehors de 
cela, le BDOI est basé sur les données ouvertes de la Ville. Je suggère 
donc d'utiliser les données de la Ville de Montréal. Cela nous a permis 
aussi d'utiliser les empreintes des bâtiments pour créer des modèles 3D 
plus tard.


*Prétraitement nécessaire des données*
Les empreintes des bâtiments de la ville sont de très haute qualité car 
elles ont été dérivées d'images aériennes. Cependant, nous avons encore 
besoin de pré-traiter les données comme suggéré sur la page wiki. En 
outre, nous aurions aussi besoin d'inclure une étape supplémentaire :
la séparation des blocs de construction en bâtiments. À mon avis, les 
bâtiments devraient exister en tant que bâtiments individuels dans OSM, 
et non en tant qu'éléments des blocs. Il faut donc trouver un moyen de 
les séparer. Je sais que les cartographes d'OSM d'Ottawa n'ont pas pris 
la peine de séparer les maisons mitoyennes en bâtiments uniques et ça me 
va. Mais, je pense que cela ne suit pas le principe de la vérité de 
terrain (ground truth) et je suggère de le faire de cette façon à 
Montréal. Nous pouvons soit rechercher une automatisation de cette étape 
par FME, PostGreSQL/PostGIS, QGIS ou le faire manuellement. J'ai déjà 
regardé un peu et j'ai trouvé que c'est assez complexe car il y a 
beaucoup d'exceptions. La simplification (suppression des nœuds 
superflus) pourrait bien fonctionner avec un outil automatisé. J'ai des 
doutes sur la division des bâtiments individuels ainsi que sur 
l'orthogonalisation des maisons mitoyennes.


Qu'est-ce que vous en pensez ?

Allons-y !

Bonne journée,
Tim

+++
AGeographer sur OSM

[1] 
https://wiki.openstreetmap.org/wiki/Montr%C3%A9al/Imports/Ville_de_Montr%C3%A9al

[2] https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Thank you, Daniel, for advancing on the import! I agree with most of 
what you said below (I will reply to some details on the wiki page).


I also agree to separate the different sources as I have great 
reservations about using Microsoft's building footprints for an import 
into OSM (the outlines are simply not good enough in their topology).


Let's get this going,
Tim




On 2020-01-03 15:40, Daniel @jfd553 wrote:
Bonjour groupe, mes excuses pour ce très long courriel !-)

I have reviewed everything that has been written on the ODB import (aka
Canada Building Import) in Talk-ca and the wiki. I proposed changes to
some wiki pages (via talk tabs) to ease the discussions about this
import and the following. Now, in order to restart the import, here are
some thoughts and a proposal on how to proceed to complete the task.

*1. Issues with the ODB Data Import*

Many concerns were raised about the import. One major concern was to
obtain local communities’ buy-in in the Canadian context. Another
concern was to improve the quality of the data prior the import. The
following paragraphs intend to clear most of these concerns.

*1.1. Which data import project?*

According to the import guidelines (steps 3 & 4), a data import
explicitly refers to a single data source (ODB in our case). Discussions
about the availability and quality of Microsoft or ESRI data, while
interesting, are not relevant as they should be dealt with as other
import projects.

*1.2. What has been imported so far?*

According to what I found [1], the ODB import is completed for 21
municipalities. These imports seem to have kept OSM content’s history,
at least for the samples checked, but many problems were found. In some
case, the imports brought swimming pools in OSM because they were
included in the dataset (e.g. Moncton). In other cases, importing
buildings with accurate locations (XY) over content mapped from less
accurate imagery resulted in buildings that now overlap the street
network (e.g. Squamish). It means that all these 21 imports need to be
carefully re-examined and corrected as required.

For 12 other municipalities, the import is partial, either suspended as
requested, or because previous imports had already provided most of the
buildings (often from the same municipal provider). That said the import
will definitely improve OSM accuracy and completeness if done properly.

*2. How should ODB Data be imported?*

I will copy the following paragraphs in the “Canada Building Import”
wiki page [3] for a detailed discussion…

Since the data (ODB, OSM and imagery) differ from one municipality to
another, there can be no imports at the national or provincial level. We
have to work on a municipal basis and make sure to identify all the
problems and the corrective measures to apply when dealing with issues
like those I identified [1].

*2.1 Importing Locally*

According to the import guidelines (step 2), we must not import the data
without local buy-in. However, and contrarily to some European country,
there is usually no such thing as a local OSM community in each
municipality. However, we may find a few local mappers from time to
time. Working on a municipal basis should allow identifying these local
mappers before doing the import. I often use this tool [2] to identify
and contact local mappers. Once identified, I suggest that…

- We contact them to explain our intents by referring to appropriate
wiki pages.

- We wait a week or two to let them respond nothing, that they have
concerns, or wish to help.

- Without negative answers we could proceed to the import.

I first suggest that when a contributor wishes to import ODB for a given
municipality, he first identifies himself as responsible for the import
(we need to create an entry for each municipality somewhere in the
wiki). He can then contact local mappers, as explain above, and go ahead
with the import once everything settled. For those who already made the
import, I suggest that they review their work since many issues were
detected with some of these imports.

Since there are only a few local OSM communities in Canada, and because
Canada is large, I suggest not limiting the import of a given
municipality to the people of the concerned province or region.

*2.2 Pre-processing*

Once local mappers have agreed, some pre-processing can be done if
required.

A few months ago, I developed a tool that could be used to process the
data [4]. Concerns were raised because the application was developed
using proprietary software. So I documented the whole process and
algorithms in order to see courageous coders converting it in open
source software. In the meantime, and as long as I have access to an FME
licence, I could process the data, when necessary, prior to make it
available through the task manager.

Proposed pre-processing [4] includes:

- Reading of original ODB data,

- Removal of near collinear nodes (simplification),

- Orthogonalization of buildings (for corners having 

Re: [OSM-talk-be] Overdreven gedetailleerde mapping ?

[Tim Couwelier]

Toch ook even mijn 'two cents' ertussen gooien.

Ik begrijp de sceptische insteek: moet je zo'n details gaan mappen, terwijl
er nog zoveel meer is wat ontbreekt?.
In geval van een BETAALDE dienstverlening, ben ik het er 100% mee eens dat
het een rommeltje is als je zo te werk gaat, 'resultaatgericht' is dat niet.

Maar dat is het hier niet. Het is een database (en dus meer dan gewoon een
kaart), wat een rommelig datamodel heeft maar waar zeer veel in terecht kan.
En als iemand dat leuk vindt om daar bomen in te mikken, of brievenbussen,
of verlichtingspalen .. dat ie lekker doet. Tuurlijk is dat een beetje
micromappen. Maar ik heb nu eenmaal meer met het groen op mijn wijk, dan
met de verlichtingspalen in Antwerpen.

Wel pleit ik er voor een zeker 'gebiedje' dan wel op een gelijke maatstaf
te behandelen. Als je het doet, zorg dan dat je consequent bent, voor de
wijk of als het even kan je kleine gemeente.



Op ma 4 nov. 2019 om 10:33 schreef Marc Gemis :

> Chris,
>
> je hoeft niet bang te zijn om je mening te geven. Alvast bedankt
> ervoor, goed dat je die quote ivm innovatie aanhaalt.
>
> Je kan de capaciteit van een parking ook taggen via de "capacity" tag
> op amenity=parking. Dat zou een een plaatsbesparende (?) mogelijkheid
> zijn.
> Maar was er onlangs niet ergens de vraag hoeveel vierkante meter er
> aan parking gespendeerd wordt ? Daarvoor heb je meer aan parking
> spaces (als je onderscheid wil maken tussen staanplaatsen en wegen
> ertussen).
>
> Voor bloembakken e.d. denk ik ook weer aan navigatie voor
> slechtzienden, of zelfs rolsstoelgebruikers (tenminste als we de
> voetpaden ook als vlakken zouden tekenen), zodat men nog weet hoeveel
> (of hoe weinig) plaats er is tussen muur en bloembak.
> Ook voor het bepalen van oversteekplaatsen voor voetgangers in het
> algemeen geeft het mappen van grasperken e.d. aan waar er hindernissen
> zijn.
>
> maar we staren ons inderdaad soms blind op data voor de navigatie van
> auto's en in iets mindere mate van fietser en voetgangers zonder enige
> vorm van beperking.
>
> mvg
>
> m.
>
> On Mon, Nov 4, 2019 at 9:44 AM Chris Van Bael 
> wrote:
> >
> > Hallo,
> >
> > long-time lezer hier, af en toe wat bijgedragen, maar vooral OSM
> gebruikt. Dus als jullie mijn commentaar niet belangrijk vinden, ook goed.
> >
> > Om even in te haken op wat wel of niet mappen. Op de OSM wiki staat: "
> The project aims to promote new and interesting uses of this data"
> > Als je geen parkeerplaatsen of zelfs bloemperkjes mapt, dan ga je in
> ieder geval daar nooit een nieuw of interessant gebruik voor krijgen.
> > Zeker voor parkeerplaatsen zie ik al verschillende mogelijkheden:
> > - voor winkels, overheid en andere organisaties nagaan hoeveel
> parkeerplaatsen er zijn in een regio om aan de hand daarvan bepaalde
> beslissingen te nemen.
> > - voor (semi) autonome auto's om te weten of men hier kan parkeren of
> wat de kans is dat er een vrije parkeerplaats is
> > Zelf kan ik niets bedenken voor bloemperkjes, maar misschien een
> milieudeskundige wel? (afstand tussen bloemperken om levensvatbaarheid van
> bijen te onderzoeken?)
> > Ik zou dus zeker niet zeggen om iets niet te mappen omdat we er nu geen
> applicatie voor kunnen bedenken.
> >
> > Waarom zou je iets niet willen mappen?
> > - onderhoud: dit vind ik nog de belangrijkste reden om iets niet te
> mappen: mogelijk heb je liever een kleinere, maar correcte database, dan
> een uitgebreide, maar onbetrouwbare database. Hierover vind ik echter niets
> terug op OSM.
> > - opslag: meer data neemt natuurlijk meer ruimte in, maar we spreken
> hier niet over foto's of films.
> > - performantie: meer nodes kunnen queries vertragen. Maar voor we data
> input gaan beperken, zou er dan eerst naar de queries gekeken moeten worden
> of die juist gemaakt zijn.  Zelfs als die dat zijn, kan je het misschien
> oplossen door er meer hardware tegenaan te gooien. Kost geld? Wel, dan moet
> OSM misschien meer geld zien op te halen ipv de data te beperken.  Ik lees
> nergens op OSM dat men enkel een routeplanner wil zijn.
> >
> > Ivm junk: ik denk dat dat minder speelt dan bij Wikipedia omdat het toch
> wat moeilijker is om een aanpassing te maken en deze ook minder zichtbaar
> is.
> > Maar: het is niet omdat er geen goede procedure is om met junk om te
> gaan, dat men dan maar minder moet gaan mappen.
> >
> > Bedankt om dit te lezen,
> >
> > Chris
> >
> >
> >
> > On Sun, 3 Nov 2019 at 20:04, Karel Adams  wrote:
> >>
> >> Marc,
> >>
> >> (parenthese over mijn conflict met DWG: ik besef dat ik niet altijd even
> >> correct heb gehandeld. En ik had er ook niet zo uitvoerig over moeten
> >> vertellen, alhier, inderdaad. Blijft de frustratie dat er op een
> >> verzoenend bericht mijnerzijds niet werd ingegaan, er kwam zelfs geen
> >> "neen", er kwam gewoon niks... Blijft mijn waarschuwing: "let wat gij
> >> doet, de DWG kan hard en niet altijd even konsekwent ingrijpen."
> >> Communicatie vooraf is erg belangrijk voor die lieden, en daar kan
> 

Re: [OSM-talk-be] fietsstraten in Mechelen

[Tim Couwelier]

Een 'fietszone' is niet meer dan een fietsstraat een 'zonale geldigheid'
gegeven.
In geval van overlap lijkt me de meest strikte bepaling gelding.

Inhaalverbod op fietsers dus, maar met de maximumsnelheid op 20 km/u.
cyclestreet = yes en highway = living_street ?


Er zullen m.i. nog een aantal gemeentes tegen de lamp lopen, met betrekking
tot de regel dat er op elk punt *maximaal 3 geldende zonale beperkingen*
mogen optreden.
Daarbij denk ik aan:
- Zones 30
- Zones parkeerverbod
- Zones tonnagebeperking
- Fietszones
- ...

Zeker in centra is combinatie 'zone 30' / tonnagebeperking /
parkeerreglementering / fietszone niet ondenkbaar.

Het issue is blijkbaar ook al voorgelegd:
http://docs.vlaamsparlement.be/pfile?id=1486490



Op di 29 okt. 2019 om 10:01 schreef Santens Seppe :

> Weet iemand wat dit betekent voor bestaande woonerven?
>
>
>
> *Van:* joost schouppe [mailto:joost.schou...@gmail.com]
> *Verzonden:* maandag 28 oktober 2019 17:55
> *Aan:* OpenStreetMap Belgium
> *Onderwerp:* [OSM-talk-be] fietsstraten in Mechelen
>
>
>
> Hoi,
>
>
>
> Mappers in Mechelen, een klein projectje: de stad heeft het gehele centrum
> aangeduid als "fietsstraten". Zie: https://www.mechelen.be/fietszone
>
>
>
> De tagging wordt hier uitgelegd:
> https://wiki.openstreetmap.org/wiki/Key:cyclestreet#Belgium
>
>
>
> Aangezien echt het hele gebied dus maximumsnelheid 30 en cyclestreet=yes
> krijgt, is het een relatief eenvoudige edit. Anderzijds is het wel
> gemakkelijk om hierbij fouten te maken (bijvoorbeeld per ongeluk ook de
> huizen aan te duiden als cyclestreet ofzo, ik vind het niet uit). Dus vraag
> gerust live hulp via Riot: https://riot.im/app/#/room/#osmbe:matrix.org
>
>
> --
>
> Joost Schouppe
>
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] nieuwe-fiets-en-voetgangerstunnel-in-ekeren

[Tim Couwelier]

Karel,

het is HIER te doen:
https://www.openstreetmap.org/way/31647365#map=16/51.2843/4.4347=N

https://assets.antwerpen.be/srv/assets/api/download/28cef7be-5225-474e-93ff-8d67322be61f/plan_tunnel.pdf
is wat er zou moeten uitgevoerd zijn.

En voor wie houdt van wat info over hoe ze zo'n tunnel daar onder schuiven:
https://www.antwerpen.be/nl/info/5610f78bcaa8a762cd8b4567/bouw-van-een-fietstunnel

Op wo 19 jun. 2019 om 20:12 schreef Karel Adams :

> cfr.
>
> https://www.vrt.be/vrtnws/nl/2019/06/19/nieuwe-fiets-en-voetgangerstunnel-in-ekeren-geopend/
>
> Ofwel kijk ik op de verkeerde plaats, ofwel is deze tunnel nog helemaal
> niet ingetekend in OSM? Wie wie wie?
>
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] bridge or tunnel?

[Tim Couwelier]

I'll agree with everyone else on the given selection here.

As for how I try to decide:
Ideally, you'd have the history of 'what came first'. Whichever level this
one is at goes as the 'baselevel'.
Either a new road / railway / .. goes:
OVER it, making that a bridge
UNDER it, making it a tunnel
AT THE ORIGINAL LEVEL, making the existing road/path a bridge or tunnel
based on how that got adjusted.

That makes this a railway-bridge:
https://www.google.be/maps/@50.9501557,3.1304248,3a,60y,255.18h,91.97t/data=!3m6!1e1!3m4!1sV8dGdG1hKMYxX3JldKdTSA!2e0!7i13312!8i6656
But this, just a bit further, and at the same level as the road shown in
the previous example, a tunnel for cyclists:
https://www.google.be/maps/@50.9516067,3.1299799,3a,48.9y,281.94h,86.62t/data=!3m6!1e1!3m4!1sPooi08Nvz-feFB6XzaibnQ!2e0!7i13312!8i6656

Hope that makes sense, I personally feel it matches with how people tend to
label things.





Op di 28 mei 2019 om 00:04 schreef Pieter Vander Vennet <
pieterv...@gmail.com>:

> Cool collection of bridges (except #2). I too think that if its not dug,
> it's not a tunnel.
>
> I have another cool example, not from belgium though:
> https://www.google.be/maps/@45.5067122,6.6792676,3a,75y,267.08h,77.06t/data=!3m6!1e1!3m4!1stJwtCeCLHlLxMPnVB_ZYdw!2e0!7i13312!8i6656?hl=nl
>
> This view is on a bridge (over a small valley) which acts as ski piste (in
> winter), and continues through a building (which has a ski piste on top).
>
> Met vriendelijke groeten,
> Pieter Vander Vennet
>
>
> Op ma 27 mei 2019 om 22:44 schreef GeDeOn . :
>
>> Hi Stijn and all
>>
>> In my opinion, a tunnel is something that was dug, in a hill or in
>> mountain, under a river, ...
>>
>> Otherwise I would think of a viaduct.
>>
>> In that regard only your case #2 is a tunnel.
>>
>> Just my 2 cents...
>>
>> Pierre
>>
>>
>>
>> Envoyé depuis mon smartphone Samsung Galaxy.
>>
>>  Message d'origine 
>> De : Stijn Rombauts via Talk-be 
>> Date : 27/05/19 20:57 (GMT+01:00)
>> À : OpenStreetMap Belgium 
>> Cc : Stijn Rombauts 
>> Objet : [OSM-talk-be] bridge or tunnel?
>>
>> Hi,
>>
>> 1. This is a bridge: no doubt.
>>
>> https://www.google.be/maps/@50.9628551,5.0810297,3a,75y,328.21h,89.12t/data=!3m6!1e1!3m4!1sXz43z9vWyUiOpCVTschIUQ!2e0!7i13312!8i6656?hl=nl
>>
>> 2. This is a tunnel: sure enough.
>>
>> https://www.google.be/maps/@50.6138142,5.5973887,3a,75y,97.64h,84.03t/data=!3m6!1e1!3m4!1sRvKwojNbhvMdSBWG3zViLw!2e0!7i13312!8i6656?hl=nl
>>
>> 3. This looks like a tunnel, no? Or is the fact that the railway is on an
>> embankment enough reason to make it a bridge?
>>
>> https://www.google.be/maps/@50.5508531,4.7216376,3a,89.9y,51.8h,87.45t/data=!3m6!1e1!3m4!1s4GoklQWnN5bW6ugdo1grmg!2e0!7i13312!8i6656?hl=nl
>>
>> 4. This one looks more like a bridge:
>>
>> https://www.google.be/maps/@50.5923923,4.6668939,3a,75y,57.67h,80.29t/data=!3m6!1e1!3m4!1s4y-C9gvI9ZsUk9jcNQX4eA!2e0!7i13312!8i6656?hl=nl
>>
>> 5. And this? Brunnel or tidge?
>>
>> https://www.google.be/maps/@50.5214486,4.8868137,3a,75y,27.85h,81t/data=!3m6!1e1!3m4!1sx0n9EuFTEx27S4sCQ--GPg!2e0!7i13312!8i6656?hl=nl
>>
>> 6. And if it gets shorter?
>>
>> https://www.google.be/maps/@50.5317414,4.9485687,3a,75y,39.18h,91.35t/data=!3m6!1e1!3m4!1sdTd6puiPIvGKsLBzeCzB6Q!2e0!7i13312!8i6656?hl=nl
>>
>> 7. And this?
>>
>> https://www.google.be/maps/@50.8660892,4.3648486,3a,75y,333.02h,85.73t/data=!3m6!1e1!3m4!1swvUHgLYhl8R5IXGVJ2QWiQ!2e0!7i13312!8i6656?hl=nl
>>
>> 8. A bit more complicated: not only a railway, but also the platforms on
>> a bridge? Or above a tunnel?
>>
>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,63.96h,87.57t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>
>> 9. And if you turn around:
>>
>> https://www.google.be/maps/@50.8101922,4.3991964,3a,75y,258.54h,101.02t/data=!3m6!1e1!3m4!1s2ioHz72P7Ju0aTcMLalGKg!2e0!7i13312!8i6656?hl=nl
>>
>> I am curious about your opinion...
>> But of course, what those things are, is not really the question. How
>> should they be mapped? That's the question.
>>
>> Regards,
>>
>> StijnRR
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Importing polygons of administrative boundaries for Belgium into OSM

[Tim Couwelier]

Ground truth is only as precise as where they can manage to put up a sign
though.
I know a nearby case there a 3-point-border lies in the middle of an
intersection between two secondary roads.

Overruling an existing border just because the sign may be off a bit, seems
pushing it, no?

Op di 21 mei 2019 om 17:56 schreef joost schouppe :

> NGI data is not open as far as I'm aware. Cadastre is not accurate. You
> could look at Statbel nis9 open data. And for Flanders there is the
> "Voorlopig Referentiebestand Gemeentegrenzen", which is generally
> considered the best quality (note how it's called "voorlopig" though).
> So there is no single objective truth about where the borders are. As long
> as this situation persists (and it's Belgium so there is little reason to
> think this will be fixed soon), I don't see why OpenStreetMap should follow
> any of these sources closely. As long as this persists, looking at the
> different datasets (as well as some ground observations) with a human eye,
> seems the best way forward to me.
>
> --
> Joost Schouppe
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-transit] Old Railways

[Tim Saunders]

I suspect I am a lone voice but I don't agree.  The thing that differentiates 
railways from a lot of historical features is they form a network, some if 
which is still an operating railway and a lot of which is still visible in the 
ground.  Having the extant sections in one database and the razed/dismantled 
sections in another is just making it unnecessarily complex to form a picture 
of the entire network, which for the sake of a few additional ways on OSM 
(which I agree would not generally be rendered) can be easily solved.

Regards,

Tim Saunders


Date: Fri, 17 May 2019 16:03:43 +0200 (CEST)
From: Mateusz Konieczny 
Cc: Public transport/transit/shared taxi related topics

Subject: Re: [Talk-transit] Old railways
This is undesirable, OSM is not a place to map historic data. When I encounter 
such mismapped
objects I remove them.
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Bonjour Daniel,

C'est une bonne nouvelle ! Pierre et moi avons déjà commencé à en parler 
dans des messages privés, et Pierre y a déjà beaucoup réfléchi - en 
partie d'un ancien projet, si je comprends bien. Il a également déjà 
publié ses approches précédentes sur github il y a quelques jours.


Voyons comment nous pouvons fusionner tes approches et celles de Pierre 
pour en tirer le meilleur parti pour le processus d'importation. Ce 
serait bien si nous pouvions trouver des méthodes d'orthogonalisation et 
 de simplification pour toutes les données OSM nouvellement importées 
(et peut-être même déjà existantes).


Tim

On 2019-04-30 12:07, Begin Daniel wrote:
Based on previous comments I improved the application and everything
seems right now. I’ll start publishing results/documentation in
following days J

We may then start developing an “open source” version of the application.

Daniel

*From:*john whelan [mailto:jwhelan0...@gmail.com]
*Sent:* Saturday, April 27, 2019 16:41
*To:* Talk-CA OpenStreetMap
*Cc:* Alasia, Alessandro (STATCAN)
*Subject:* [Talk-ca] Importing buildings in Canada

We now have three sources of data with the correct licensing.

I'm proposing that I amend both the import plan and the import mailing
list to include the three alternative sources.

I'm tempted by the idea of splitting the country up into regions of some
sort.

We have a couple of groups currently who I think would like to import
what is available in Alberta and Manitoba.  Are we asking them to hold
off until Pierre and company have come up with a cleansing routine?

Thoughts ladies and gentlemen please.

Thanks John


___
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] NRC building footprints - from lidar

[Tim Elrick]

Hi all,

All those new sources are really exciting! Thanks for making us aware of 
the data, Keith!


I just checked the NRCan LiDAR building footprints for Montreal [1]. 
Unfortunately, they seem to have the same flaws as the Microsoft 
building footprints. The data quality for Montreal cannot keep up with 
the building footprints in the Open Building Database released by 
StatCan - it probably has to do with the altitude the LiDAR sensor was 
flown over the surface, as the OBD data for Montreal was also derived 
from LiDAR (but probably flown at a much lower altitude, hence a much 
more detailed result).


As with the Microsoft building dataset the NRCan data set is probably 
useful for emergency services and desaster relief organisations that 
only need to know the existence of buildings in an area, but not the 
exact shape. I doubt it can be used for import into OSM, however, as 
already stated in another e-mail, in remote areas it still might be good 
enough - I guess, it all depends on how you read the 'ground truth 
principle' and other 'mapping rules' in the OSM cosmos.


Like Pierre, Daniel and Nate have shown for the OBD data the NRCan data 
should at least be simplified and orthogonalized if deemed appropriate 
for importing.


Cheers,
Tim

[1] https://imgur.com/a/4eKDpcj

On 2019-04-27 09:56, keith hartley wrote:
Hi all,
Canadian Geomatics posted this data set a few months back from Natural
Resource Canada.
It's Building footprints from Lidar or high res imagery.
https://canadiangis.com/automatically-extracted-buildings-canadian-open-data.php?fbclid=IwAR22SaWwz7--LarDksVfcQuZ9RDgkVc421n9saJ_Lv8r6xq1qPSrouEF0Ww

https://open.canada.ca/data/en/dataset/7a5cda52-c7df-427f-9ced-26f19a8a64d6

 From what I can tell when placing the data over imagery it's very bang
on. Highly accurate, good shapes (unlike the bing files) and well
placed. As far as I can tell no one else has uploaded these to OSM. The
areas in manitoba are mainly where there's little to no other building
info.
I can write an upload plan on Manitoba wiki as the data is complaint
license wise. Anything else I should be looking for? The local mappers
here are pretty excited about it.

Keith




___
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-GB] multiple GB lists

[Tim Waters]

Hi Jez,

happy to stop talk-gb-thenorth and merge it but how would I do that? it
would be nice if it was kept in archived form

This one has not been used for several years now - it has 60+ subscribers.

Tim

On Thu, 4 Apr 2019 at 10:13, Jez Nicholson  wrote:

> Demonstrating my ignorance, I did not know until recently that there are
> other GB lists, shown here with their last used date:
>
> talk-gb-london/ 2019-03-14 14:35
> talk-gb-midanglia/ 2016-06-17 15:15
> talk-gb-oxoncotswolds/ 2018-11-21 18:43
> talk-gb-thenorth/ 2017-06-22 11:44
> talk-gb-westmidlands/ 2019-03-31 13:52
> talk-scotland/ 2019-04-01 11:48
>
> This may be a perennial discussion, but I'll naively stick my neck out
> (again)
>
> I, for one, would not be offended to read about regional activities in the
> main Talk-GB list. In fact, I would welcome seeing activity around the
> country even if i'm too far away to attend. They do not appear to be high
> volume.
>
> Could the owners of those lists consider culling them and merging with
> Talk-GB?
>
> Regards,
>   Jez
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-ca] Building Import

[Tim Elrick]

D'accord. Attendons que Daniel ait fini de peaufiner le pré-traitement. 
Ensuite, nous pouvons voir comment nous pouvons réaliser cela en open 
source. Je connais pas mal de R et de plus en plus de PostGIS. Bien sûr, 
tout le monde sera le bienvenu.


Tim

On 2019-03-27 16:13, Begin Daniel wrote:
Tim pose une question réaliste...
Qu’est-ce qui se passe si un jour OSM ne m’intéresse plus ?

J’utilise FME parce que le développement se fait de façon 100 fois plus 
rapide pour tester des idées (je n’aime pas la programmation standard - 
je fais trop d’erreurs d’inattention dans les détails ;-)


Alors, une fois que le processus sera mis au point sur FME, ça me fera 
plaisir d’en décomposer chaque étape avec vous et de rendre le tout 
public. On pourra faire ça hors liste :-)


Daniel

-Original Message-
From: Tim Elrick [mailto:o...@elrick.de]
Sent: Wednesday, March 27, 2019 10:33
To: Pierre Béland; talk-ca@openstreetmap.org
Subject: Re: [Talk-ca] Building Import

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à
utiliser des outils propriétaires lors de l'utilisation des données OSM.
Cependant, lors de la création des données OSM, nous devons viser le
processus le plus transparent possible (comme indiqué sur la question de
l'importation si souvent sur cette liste). D'après ce que j'ai vu,
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et
je suis heureux qu'il contribue son temps et ses idées sur l'importation
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou
même nettoyer des données existantes qui ne l'intéressent pas ? Je me
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est
pas mal car tout est documenté sur github.

Donc, je pense que ce serait bien si nous pouvions traduire les
algorithmes que Daniel utilise (avec les documents dans le wiki) en un
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce
qu'il fait.

Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un
exposé sur la façon d'y arriver - hors liste car je pense que le grain
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le
documenterons plus tard dans le wiki.

Qu'est-ce que vous en pensez ?

Tim

[1]
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps

On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

___
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] Building Import

[Tim Elrick]

Bonjour Pierre, Daniel, John et tous,

Je ne doute pas de l'expertise de Daniel. Il n'y a rien de mal à 
utiliser des outils propriétaires lors de l'utilisation des données OSM. 
Cependant, lors de la création des données OSM, nous devons viser le 
processus le plus transparent possible (comme indiqué sur la question de 
l'importation si souvent sur cette liste). D'après ce que j'ai vu, 
l'outil et la chaîne de processus de Daniel fonctionnent très bien. Et 
je suis heureux qu'il contribue son temps et ses idées sur l'importation 
de bâtiments. Mais si Daniel n'est plus là ? Ou nous voulons importer ou 
même nettoyer des données existantes qui ne l'intéressent pas ? Je me 
souviens juste du sort des beaux outils d'histoire de l'OSM de Peter 
(MazderMind) [1] créés il y a quelques années, mais qu'il ne pouvait 
plus maintenir pour des raisons inconnues de moi. Dans son cas, ce n'est 
pas mal car tout est documenté sur github.


Donc, je pense que ce serait bien si nous pouvions traduire les 
algorithmes que Daniel utilise (avec les documents dans le wiki) en un 
outil open source. Cela ne veut pas dire que Daniel doit arrêter ce 
qu'il fait.


Daniel, ce serait bien si toi et moi (et Pierre?) pouvions faire un 
exposé sur la façon d'y arriver - hors liste car je pense que le grain 
de sable n'est pas d'intérêt pour la liste - bien sûr, nous le 
documenterons plus tard dans le wiki.


Qu'est-ce que vous en pensez ?

Tim

[1] 
https://wiki.openstreetmap.org/wiki/User:MaZderMind/Reading_OSM_History_dumps


On 2019-03-26 23:08, Pierre Béland wrote:
Cette discussion sur gis.stackexchange donne le lien vers OpenCarto sur
Sourceforge et vers un document décrivant la méthode.
https://gis.stackexchange.com/questions/25263/is-there-any-open-source-building-squaring-tool

Avec les fonctions PostGIS, à voir comment ST_ShortestLine ou fonction
similaire permettrait de réviser les coordonnées de chaque point du
polygone.
http://postgis.net/docs/ST_ShortestLine.html

Pierre





Le mardi 26 mars 2019 21 h 49 min 17 s HAE, Pierre Béland via Talk-ca
 a écrit :


Bonjour Tim

Mon outil d'analyse Qualité dont les données sont publiées sur
OpenDataLabRDC est basé sur PostgreSQL-Postgis.   Je suis à nettoyer /
documenter le code et prévoit le publier sur github.  J'ai commencé à
regarder les outils possibles, mais peu de documentation disponible. On
parle par exemple de OpenCarto, mais l'info n'est plus disponible. A
voir si possible à l'aide de Grass.
https://gis.stackexchange.com/questions/15612/is-it-possible-to-simplify-orthogonal-polygons-with-opencarto-java-library


Pierre

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

Re: [Talk-ca] Building Import

[Tim Elrick]

I sent Daniel a sample of Montreal (Outrement) from the Open Building 
Database and Daniel's algorithm performed really well. It could reduce 
the vertices count by 13% without loosing or even improving data quality 
(as it orthogonalized the buildings). Even difficult buildings were 
treated well [1].


As OSM is mainly built on open source tools, the OSMF tries to work with 
open source tools only and the process should be reproducible (if not 
for this import, then for the next one somewhere else in the OSM 
cosmos), I suggest, we try to resemble Daniel's pre-processing in open 
source software, e.g. PostGreSQL/PostGIS. I already found the code for 
collinearity; the orthogonalization seems to be a bit trickier, but it 
should be possible to built the process in PostGIS as well, if it was 
possible to built it in FME. What do you think?


Tim

[1] https://imgur.com/a/aCKMVb7

On 2019-03-26 13:45, Jarek Piórkowski wrote:
On Tue, 26 Mar 2019 at 13:10, Begin Daniel  wrote:

There is actually no standard “code” available since I use FME (www.safe.com). 
It is a proprietary ETL application and all operations are done using 
“transformers” (https://www.safe.com/transformers/). I can provide you with the 
workbench I developed (a bunch of linked transformers) but you need a license 
to run it. This is why I tried to describe the operations I run on the data in 
the wiki.

As you did, people may send me coordinates (bounding box) of an area they know 
well. I’ll process the area and send the results back in OSM format. Please, be 
reasonable on the amount of data to process ;-)


Thanks Daniel. Let me know how it looks then!

Coming from an open-source background, the process is unusual to me,
and I have questions about scalability - will you be able to process
and provide updated data files for all of Canada then? - but if others
are comfortable with it then I won't object.

Some general thoughts regarding tooling as raised upthread:

I was initially excited to see building footprints data as they help
two quite distinct purposes:

1. they provide a mostly-automatic source of geometries for the
millions of single-family houses that wouldn't be mapped in the next
decade otherwise

2. they might provide a corrected and fairly accurate source of
geometries in heavily-built-up areas, where GPS signal is not that
reliable and it can be really difficult to get sufficiently accurate
geometries from imagery, whether because it's not sufficiently
high-resolution, two sets of imagery with conflicting offsets (Bing
and Esri are the two best sets in Toronto, and they're off by about
1-2 m on north-south axis from each other - that's not something I can
check with a consumer-grade GPS so I'm left guessing as to which is
true), or non-vertical imagery (I can count the floors on supposedly
top-down imagery in some cases).

 From what I saw, imports in the GTHA initially focused on the first
case, and I think the Tasking Manager setup was mostly sufficient for
those - where there is nothing currently on the map, or a few simple
2D geometries, a 4 sq km area can feasibly be done in under an hour.

However, as raised by others, I would really want the working squares
in Old Toronto for example to be no more than 500 m x 500 m, or no
more than 1 km x 1 km in St. Catharines. I would _love_ to have the
geometries to manually compare and adjust the 3D buildings already
existing in the area, but it will be much slower.

--Jarek

___
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] Building Import

[Tim Elrick]

I think, Montreal's OSMappers would appreciate to discuss the import of 
the buildings there first on the local list. By the way, John, I have 
never said I would be taking the lead for the entirety of Québec (at 
least, at the moment). However, I feel that the import should be 
discussed on the liste OSM de Québec first.


Danny, I disagree with you on the import of building blocks. I find it 
much more tedious to discern them later, then splitting them into single 
buildings first before importing, because, I think, you need to know 
your neighbourhood very well to find unsplit buildings in the OSM 
database. Doing this for a whole town or even city (like Montreal) would 
take much longer than pre-processing.


As for the rest, I have some understanding for the impatience of 
OSMappers about the moratorium on the import - as quite some time has 
passed and the discussion hasn't really moved on nor has the development 
of the countrywide import plan [1] - last change there was beginning of 
February.


Having looked at the Microsoft data and compared quality to the Open 
Building Database in two places (Montréal, QC and Williams Lake, BC), I 
would suggest to refrain from using it as a source for importing, unless 
you verify them for small areas (but then you can almost draw them by 
hand). In dense areas like downtown Montréal the building footprints are 
in many cases plainly wrong (see my contribution to this list on 
2019-03-02, 19h57 EST), in more scattered areas and suburban landscapes 
buildings are randomly aligned and quite some buildings are missing (my 
unverified estimate is about 5-10%).


As for the Open Building database, it is important to discern the data 
by the sources as each municipality that contributed data might have 
used different methods and has different mapping standards. Now add the 
disagreement on this list about orthogonalization and building details. 
I think, this suggests breaking up the import plan in smaller batches; 
for the start it can be cloned from the original one, but the 
pre-processing and import process might differ due to how data sources 
might need to be treated as well as how local OSM communities would like 
to go forward.


What do you reckon?

Tim

[1] https://wiki.openstreetmap.org/wiki/Canada_Building_Import


On 2019-03-15 14:01, John Whelan wrote:
Which I think comes back to defining the local mappers.

There has been discussion on Montreal as well and not all Ontario thinks 
the same way.  Ottawa local mappers for example have different opinions 
to Pierre and Nate on what is acceptable and I'm under the impression 
that not everyone in Toronto agrees with Nate's position.


We seem to be blocking out parts of the country such as Montreal is this 
a reasonable approach?


Can we find someway to loosely define local groups and their areas of 
responsibility and how to contact them?


For example one small Ontario city has to my knowledge one OpenStreetMap 
mapper who maps very occasionally.  My understanding is they would be 
quite happy to see an import happen but many of the buildings have 
already been mapped although not to the accuracy that the Stats Can data 
offers. How do you deal with these smaller cities and townships?


Thanks

Cheerio John

Paul Norman via Talk-ca wrote on 2019-03-15 1:45 PM:

On 2019-03-15 9:07 a.m., Andrew Lester wrote:

I disagree. Silence won't solve anything.

I'm speaking here as a local BC mapper, and I strongly disa gree with 
these recent imports.


I'm also a BC mapper, and have only seen the consultation happen over 
Ontario, not BC.



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


--
Sent from Postbox 
<https://www.postbox-inc.com/?utm_source=email_medium=siglink_campaign=reach>


___
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] Microsoft has released its building outlines for Canada

[Tim Elrick]

Hi Daniel and James,

Sounds good, Daniel. Looking forward to see your tool. However, the Open 
Building Database data for Montreal looks pretty good in terms of number 
of nodes and orthogonalization. I am still working on how to break up 
the building blocks, however, with much less time on my hand than you 
seem to have. I will keep you posted as soon as I had some success.


Thanks, James, for your kind offer. If we decide to import, which we 
will discuss on the local list first, we then will provide an import 
plan and will get back to for the technical implementation of providing 
the tiles on the tasking manager.


I suggest, we continue this conversation on the Montréal list 
(challenging my French capabilities).


Tim

On 2019-03-04 19:48, James wrote:
I could serve the output using the microdataservice and the osncanada
task manager(multiple tasks)

https://github.com/osmottawa/micro-data-service

On Mon., Mar. 4, 2019, 7:16 p.m. Begin Daniel, mailto:jfd...@hotmail.com>> wrote:

    Tim, 

I have plenty of free time and I am interested in this import. I am
about to complete a pre-processing tool that seems to
“orthogonalize” building footprints pretty well using FME (safe
software). I plan to present/discuss its functionalities next week
on this list (vertex filtering, ensuring right angles, sorting
building according to processing results, etc.). I have not examined
how to break up building blocks into single units yet but I am
interested to include it in the pre-processing tool if it is
possible.

__ __

Daniel

__ __

*From:*Tim Elrick [mailto:o...@elrick.de <mailto:o...@elrick.de>]
*Sent:* Saturday, March 02, 2019 19:58
*To:* talk-ca@openstreetmap.org <mailto:talk-ca@openstreetmap.org>
*Subject:* Re: [Talk-ca] Microsoft has released its building
outlines for Canada

__ __

Hi Steve,

__ __

As for Montreal: We will create an import plan on the wiki as soon
as we have expanded the discussion about the Montreal import from
our local face-to-face group to the Montreal OSM list and agreed on
importing. Before we do this, we wanted to test the feasibility of
the pre-processing first, as it involves quite some postgis coding
to break up the building blocks into single buildings. Only
thereafter, we will suggest an import (or not), depending on the
feasibility of extracting single buildings. Otherwise we will follow
the hand-drawn approach as usual (and as it is done on a daily basis
at the moment by a couple of OSMappers).

__ __

The Microsoft data set might still be useful for remote areas. Let's
explore this altogether.

__ __

Cheers,

Tim

__ __


On 2019-03-02 19:17, OSM Volunteer stevea wrote:

On Mar 2, 2019, at 3:47 PM, John Whelan 
<mailto:jwhelan0...@gmail.com>  wrote:


Two years ago a group of Toronto mappers submitted the City of 
Toronto Open Data license to the LWG to see if it was acceptable.  I 
assume they meant to import things such as building outlines.  I also 
assumed as I think others did that this meant Toronto mappers were happy 
to import the City of Toronto's data especially as it was discussed on 
talk-ca first.


Historical info is appreciated for context, however, the LWG found 
Canada-wide city-by-city submissions for ODbL-compliance burdensome, 
given LWG's limited bandwidth.  Assuming about events in the past is 
unhelpful, first because it is assuming (seldom helpful) and second, 
these events are in the past.  How Toronto imported (building) data 
can't really help us first understand and second improve from what we 
learn until we know what we learned.  That isn't presented here, but it 
could be.


__  __

More recently Nate who currently lives in Toronto feels that 
this should be discussed once more in Toronto to work out what is 
desired etc.


I agree with Nate.  Perhaps first in Toronto, perhaps wider in 
talk-ca.  "Once more" seems limiting, though it's possible it could 
suffice.


__  __

Tim I think is organising Montreal open data import.

Please consider adding this (and links to user: wiki or Talk pages) 
to the active Import wiki.  Generate communication using our media!


__  __

I note that Nate and Tim have different ideas about what should 
be imported.  One is happy with bay windows and I think the other feels 
they should be removed.


More discussion often yields consensus, especially as it "goes 
wide" (or as wide as is practical).


__  __

We also have Pierre who is unhappy because the imported 
building outlines available have too many corners that are not right 
angles.


More discussion often yields consensus.

__  __

The local Ottawa mappers are content with their

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[Tim Elrick]

Hi Steve,

As for Montreal: We will create an import plan on the wiki as soon as we 
have expanded the discussion about the Montreal import from our local 
face-to-face group to the Montreal OSM list and agreed on importing. 
Before we do this, we wanted to test the feasibility of the 
pre-processing first, as it involves quite some postgis coding to break 
up the building blocks into single buildings. Only thereafter, we will 
suggest an import (or not), depending on the feasibility of extracting 
single buildings. Otherwise we will follow the hand-drawn approach as 
usual (and as it is done on a daily basis at the moment by a couple of 
OSMappers).


The Microsoft data set might still be useful for remote areas. Let's 
explore this altogether.


Cheers,
Tim


On 2019-03-02 19:17, OSM Volunteer stevea wrote:

On Mar 2, 2019, at 3:47 PM, John Whelan  wrote:


Two years ago a group of Toronto mappers submitted the City of Toronto Open 
Data license to the LWG to see if it was acceptable.  I assume they meant to 
import things such as building outlines.  I also assumed as I think others did 
that this meant Toronto mappers were happy to import the City of Toronto's data 
especially as it was discussed on talk-ca first.


Historical info is appreciated for context, however, the LWG found Canada-wide 
city-by-city submissions for ODbL-compliance burdensome, given LWG's limited 
bandwidth.  Assuming about events in the past is unhelpful, first because it is 
assuming (seldom helpful) and second, these events are in the past.  How 
Toronto imported (building) data can't really help us first understand and 
second improve from what we learn until we know what we learned.  That isn't 
presented here, but it could be.


More recently Nate who currently lives in Toronto feels that this should be 
discussed once more in Toronto to work out what is desired etc.


I agree with Nate.  Perhaps first in Toronto, perhaps wider in talk-ca.  "Once 
more" seems limiting, though it's possible it could suffice.


Tim I think is organising Montreal open data import.


Please consider adding this (and links to user: wiki or Talk pages) to the 
active Import wiki.  Generate communication using our media!


I note that Nate and Tim have different ideas about what should be imported.  
One is happy with bay windows and I think the other feels they should be 
removed.


More discussion often yields consensus, especially as it "goes wide" (or as 
wide as is practical).


We also have Pierre who is unhappy because the imported building outlines 
available have too many corners that are not right angles.


More discussion often yields consensus.


The local Ottawa mappers are content with their Open Data import and find the 
data quality acceptable even though Pierre has expressed reservations about it.


More discussion often yields consensus.  Wide area (large cities, 
province-wide, nationwide) imports are not easy to achieve consensus but can 
often reach something approaching one as data are entered, not liked, improved, 
liked better, et cetera.  These are often an interactive, iterative process.


Someone in Manitoba? mentioned there were no building outlines released for 
Manitoba?  I apologise if I have the province name wrong.


It is spelled correctly.  I am not Canadian and I know that; it isn't hard to 
spell-check Manitoba.


So we have a mixture of expectations which is only to be expected in a large 
group.


More discussion often yields consensus.  It might be part "mixture of expectations" but I'm sure 
that everyone will agree that "high quality data entering OSM" is expected.  What can be difficult 
is "what do we mean by high quality?" (in addition to establishing and communicating clear goals 
for the importation of the data).


Microsoft's Open Data provides another source of Open Data which might meet 
Pierre's data quality expectations.  They may meet Nate's.  All provinces and 
Territories now have Open Data building outlines available.


OK, thanks for the clarification that a "union" of these datasets (Stats Canada-produced building 
data + Microsoft-produced building data) provide an "all provinces and Territories dataset."  That 
truly is helpful as it makes it clear that "if Set A doesn't have your province's or Territory's 
building data, Set B will."


Northwest Territories, Nunavut, and Yukon have populations of around 35,000 
people.  Realistically I don't think they have a group of local OSM mappers.


Please don't "write them off" so easily.  Not only does it seem "not nice," it may not be true.  A 
better approach may be to actively develop community there, difficult as that might seem.  I believe there is usually 
Internet available there in the villages (sometimes via clever and state-of-the-art methodologies) and it may be as 
simple as "shaking the trees" of the right people, then

Re: [Talk-ca] Microsoft has released its building outlines for Canada

[Tim Elrick]

Hi everyone,

Thanks John for pointing out the new dataset!

Steve, John just indicated that there is this new dataset available now. 
I am confident, that after our discussion on importing building 
footprints in Canada, the OSMappers who want to go forward with it, will 
provide the information on the import plan/wiki.


You can download the Microsoft file at the site indicated by John. The 
license information can be found there as well (as mentioned by James it 
is ODbL. It is much more extensive than the Open Building Database 
release by StatCan (> 12 million buildings vs. 4.4 million buildings).


So, I got interested and I had a look at the data for Montreal: 
https://imgur.com/a/PwuZ3Q5
I chose an area where OSM data existed. As you can see OSM hand-drawn 
buildings from Bing imagery are nicely drawn and separated.
When you compare the OSM data to the Open Building Database (OBD) data 
from StatCan (brown in my images) which draws on the données ouvertes de 
Ville de Montréal (extracted from photogrammetric imagery) you can see 
that the OBD data is somehow more precise than the OSM/Bing data, but 
the huge draw back is that the OBD data only captures the building 
outlines of attached/terraced buildings, i.e. of building blocks without 
separating single buildings (as already mentioned by me in a separated 
e-mail to the list - this is why we will have to do some pre-processing 
of the data).
When you then compare this data set to the Microsoft data set (pink in 
my images), you see that their deep neural network approach fails in 
areas with terraced houses big time. Same goes for the the city centre 
of Montreal (not shown in my images).


So, the Microsoft data set might work for areas with single homes and 
that would be helpful to fill in the blanks in remote areas, but for 
areas where we have data from the ODB, importing from the ODB might be 
better. However, caution has to be taken with ODB as well, as every 
municipality that contributed data might have contributed a different 
data source, where the quality should be check each time.


Just my two cents here.

Tim


On 2019-03-02 17:40, john whelan wrote:

Why are you planning to import it?

Cheerio John

On Sat, Mar 2, 2019, 5:26 PM OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly imported into OSM.

   SteveA
   California

> On Mar 2, 2019, at 2:17 PM, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>
> https://github.com/Microsoft/CanadianBuildingFootprints
>
> So now there are two Open Data sources for building outlines in
   Canada.
>
> Cheerio John
> ___
> 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




On 2019-03-02 17:49, James wrote:
M$ released data as ODbL so pretty sure license is compatible

On Sat., Mar. 2, 2019, 5:27 p.m. OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly imported into OSM.

   SteveA
   California

> On Mar 2, 2019, at 2:17 PM, john whelan mailto:jwhelan0...@gmail.com>> wrote:
>
> https://github.com/Microsoft/CanadianBuildingFootprints
>
> So now there are two Open Data sources for building outlines in
   Canada.
>
> Cheerio John
> ___
> 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 <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




On 2019-03-02 17:49, James wrote:
M$ released data as ODbL so pretty sure license is compatible

On Sat., Mar. 2, 2019, 5:27 p.m. OSM Volunteer stevea, 
mailto:stevea...@softworkers.com>> wrote:


   A responsible complement to this would be a link to license
   information, a wiki page about these data, and perhaps an Import
   Plan should those data actually be asserted to be worthy of being
   responsibly im

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Thanks for the heads up. As I said, we are not in a rush here, and will 
first transfer the discussion to the Montreal list, then start a page on 
the import wiki and take it from there. On top, the pre-processing will 
be a bit of work as well.


There is lots of data for the City of Montreal that can be imported: 
fire and police stations, free wifi access, traffic lights, swimming 
pools to name but a few. For now, we are talk about including the 
address and building heights into the building import.


I know from reading the Montreal list that someone else is importing bus 
stops at the moment.


Cheers,
Tim

On 2019-02-16 13:07, John Whelan wrote:
If CC-BY 4.0 works great.  I'd go for any addresses etc and any bus
stops you can get hold of as well.

Just be aware that we had a fairly large number of questions asked about
the license etc when we did Ottawa and one of the people questioning
referred the license to the LWG.  Even the basis of CANVEC licensing
came into question at the time.

Many of the questions came from German and other European mappers.

I understand the City of Toronto's Open Data license was referred as
well but that was about two years ago and I note that the LWG web site
has no mention of it so it is probably still in the queue.

Good Luck

Cheerio John

Tim Elrick wrote on 2019-02-16 12:22 PM:

Hi John,

Thanks for pointing me to the license website. The open data of the 
City of Montreal is licensed CC-BY 4.0 and the City has explicitly 
granted OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original 
open data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

    Hi all,

    After following the building import discussion for a while now, I
    wanted to chime in as well.

    After moving to Montréal from Germany recently, I got more engaged
    with the local mappers here in MTL (beforehand, I was more analysing
    OSM data scientifically).

    I took part in the initial meeting of the Building Canada 2020
    initiative, in which great interest in the project was expressed by
    many institutions, organizations and businesses. However, apart from
    Statistics Canada, municipalities and OSMappers no one seemed to be
    willing to invest into the effort to support the initiative with
    manpower or funding (to my knowledge). Therefore, I found it quite
    impressive what StatCan has achieved with the Open Building Database
    and do not share the view of some on this list that the initiative
    got off on the wrong foot; but that all water under the bridge now.

    So, yes, there seems to be some interest to use the data from the
    Open Building Database in OSM easily. However, I am also hesitant,
    that one massive import can be the answer.

    I'm generally hesitant with imports as such, maybe because I was
    acculturated in OSM in Germany where OSMappers value original
    entries much more than secondary data. Further, I'm skeptical, that
    secondary data is necessary better than original data (even from
    mapathons). I initiated two mapathons with university students in
    the context of Building Canada 2020. Both mapathons resulted in
    mostly nice buildings, I would say - and, when there is the odd
    not-so-nice building, there is still the validation step as we
    always used the tasking manager [1]. By the way, both mapathons used
    the ID editor; and, of course, you can square buildings in ID as
    well; so, I don't really understand the ID editor bashing that
    appears on this list here now and then. That said, of course, I
    prefer JOSM over ID as it is the more versatile tool, but to
    introduce interested persons to editing in OSM, ID is really nice.

    I'm even more skeptical about imports after Yaro pointed us to the
    Texas import [2]. I wonder why there was no outcry there (or maybe
    there was and I did not hear about it) - the imported data is
    te

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

Hi John,

Thanks for pointing me to the license website. The open data of the City 
of Montreal is licensed CC-BY 4.0 and the City has explicitly granted 
OSM the right to use the data on top of that. See: 
http://donnees.ville.montreal.qc.ca/portail/licence/


StatsCan's Open Building Database uses exactly the same data source, 
however, as I pointed out in my last e-mail, it did not split the 
building blocks into actual buildings. The open data of the City of 
Montreal, furthermore, includes building heights which are lost in the 
OBD. These are the reasons why we would like to import the original open 
data.


Cheers,
Tim

On 2019-02-16 11:21, john whelan wrote:
When you look at importing Montreal you might like to look at the
following first.

https://wiki.osmfoundation.org/wiki/OGL_Canada_and_local_variants

Note if the Montreal data in available through Stats Can and the federal
government open data license it might be better to use that data source
from a licensing perspective.

Although data can be given to OpenStreetMap I don't think there in a
foolproof method of recording the fact.  If one person has the paper
record fine but if they are no longer part of the community then there
maybe a problem if the license is challenged.

Cheerio John

On Sun, 10 Feb 2019 at 00:04, Tim Elrick mailto:o...@elrick.de>> wrote:

Hi all,

After following the building import discussion for a while now, I
wanted to chime in as well.

After moving to Montréal from Germany recently, I got more engaged
with the local mappers here in MTL (beforehand, I was more analysing
OSM data scientifically).

I took part in the initial meeting of the Building Canada 2020
initiative, in which great interest in the project was expressed by
many institutions, organizations and businesses. However, apart from
Statistics Canada, municipalities and OSMappers no one seemed to be
willing to invest into the effort to support the initiative with
manpower or funding (to my knowledge). Therefore, I found it quite
impressive what StatCan has achieved with the Open Building Database
and do not share the view of some on this list that the initiative
got off on the wrong foot; but that all water under the bridge now.

So, yes, there seems to be some interest to use the data from the
Open Building Database in OSM easily. However, I am also hesitant,
that one massive import can be the answer.

I'm generally hesitant with imports as such, maybe because I was
acculturated in OSM in Germany where OSMappers value original
entries much more than secondary data. Further, I'm skeptical, that
secondary data is necessary better than original data (even from
mapathons). I initiated two mapathons with university students in
the context of Building Canada 2020. Both mapathons resulted in
mostly nice buildings, I would say - and, when there is the odd
not-so-nice building, there is still the validation step as we
always used the tasking manager [1]. By the way, both mapathons used
the ID editor; and, of course, you can square buildings in ID as
well; so, I don't really understand the ID editor bashing that
appears on this list here now and then. That said, of course, I
prefer JOSM over ID as it is the more versatile tool, but to
introduce interested persons to editing in OSM, ID is really nice.

I'm even more skeptical about imports after Yaro pointed us to the
Texas import [2]. I wonder why there was no outcry there (or maybe
there was and I did not hear about it) - the imported data is
terrible: no parallel to street buildings, no right angles,
sometimes even not the right size of building parts. Fact is that
secondary data buildings footprints can be from many different data
sources - from AutoCAD, handdrawn by a municipal GIS experts to
photogrammetric and satellite machine learning sources; all those
sources have their peculiarities, which I think, you cannot satisfy
in one import plan fits all - especially, as the Open Building
Database in Canada is stitched together from those very different
sources.

In Montreal, e.g., the source for the Open Building Database is the
données ouvertes des batiments. This is photogrammetric imagery
probably turned into AutoCAD files, which then were exported to a
shapefile and geojson. The building outlines are impressively
precise, however, the open data files contain building blocks not
single buildings [3], however, offer building dividers in a separate
shapefile (I assume due to the export from AutoCAD, see second image
in [3]). Unfortunately, the Open Building Database only included
those building blocks in their data set, making it not very easy to
import into OSM (as they do not include the building dividers).
Hence, a bit of non-trivial pre-processing of the original données
ouvert

Re: [Talk-ca] Some feedback on import quality in Toronto

[Tim Elrick]

 
like to see the world as precisely represented as possible in OSM; in 
many parts of the OSM world you now find single trees, mailboxes and 
lamp posts in OSM; isn't that great? As for buildings, I would like to 
see all the bay windows, nooks and crannies - even in Canada.


How to proceed? For Montréal: After we looked more into the challenges 
of pre-processing the Montreal open dataset, I guess, we will propose a 
separate import plan. If anyone would like to join us in discussing the 
pre-processing, please contact me and we can continue on the Montréal 
OSM list. Oh, and by the way, while we all were discussing the import 
since December almost 3,000 buildings were mapped by hand in the Greater 
Montreal region [5].


That all being said, I do not want to stop anyone of you from importing 
buildings. I just think, that we have to do this more bit by bit to 
cater for all the peculiarities of the heterogeneous data sources of the 
Open Building Database.


Happy mapping to everyone,
Tim

[1] see e.g. http://tasks.osmcanada.ca/project/91
[2] https://www.openstreetmap.org/#map=19/32.97102/-96.78231
[3] https://imgur.com/a/S8Nq5rg
[4] https://i.imgur.com/H10360K.png
[5] http://overpass-turbo.eu/s/FWH

On 2019-02-03 18:35, Yaro Shkvorets wrote:
Having reviewed the changeset, here are my 2 cents. OsmCha link for 
reference: https://osmcha.mapbox.com/changesets/66881357/


1) IMO squaring is not needed in most of those cases.
- You can see difference between square and non-square ONLY at high zoom 
level. And even then, it's not visible to the naked eye. We are talking 
about inches here.
- Sometimes squaring is plain wrong to be applied here. Even though you 
paid very close attention you managed to square a couple of non-square 
buildings. Like this facade is not supposed to be square for example: 
https://i.imgur.com/H10360K.png I might be OK with squaring 
almost-square angles if there is a simple plugin for that. The way you 
propose to do it, by going building-by-building and pressing Q is 
completely unsustainable and sometimes makes things bad.
- Another thing, this particular neighbourhood is pretty dense and 
mature and therefore has mostly square buildings. I can only imagine how 
bad it would become if you ask people to square things in newer 
developments where buildings often come in irregular shapes.
- Like mentioned above, many successful import didn't require squaring. 
In this Texas one, 100% of buildings are not perfectly square: 
https://www.openstreetmap.org/#map=19/32.97102/-96.78231



2) Simplification is good to have, sure. Obviously standard Shift-Y in 
JOSM is a no-starter. If we can find a good way to simplify ways without 
losing original geometry and causing overlapping issues we should do it. 
But even then, reducing 500MB province extract to 499MB should not be a 
hill to die on.


3) Manually mapping all the sheds and garages is completely 
unsustainable. Having seen over the last couple of years how much real 
interest there is in doing actual work importing buildings in Canada 
(almost zero) adding this requirement will undoubtedly kill the project. 
Sure you will meticulously map your own neighbourhood, but who will map 
thousands of other places with the same attention to details? Also, you 
did rather poor job at classifying buildings you add, tagging them all 
with building=yes. Properly classifying secondary buildings like sheds 
and garages in a project like this is pretty important IMO. I agree with 
John, we should leave sheds to local mappers to trace manually.


To sum up, yes we can do better. But this is the perfect example when 
"better" is the enemy of "good".


On Sun, Feb 3, 2019 at 12:34 PM Nate Wessel <mailto:bike...@gmail.com>> wrote:


   Hi all,

   I had a chance this morning to work on cleaning up some of the
   already-imported data in Toronto. I wanted to be a little methodical
   about this, so I picked a single typical block near where I live.
   All the building data on this block came from the import and I did
   everything in one changeset:
   https://www.openstreetmap.org/changeset/66881357

   What I found was that:

   1) Every single building needed squaring

   2) Most buildings needed at least some simplification.

   3) 42 buildings were missing.

   I knew going in that the first two would be an issue, but what
   really surprised me was just how many sheds had not been imported.
   There are only 53 houses on the block, but 42
   sheds/garages/outbuildings, some of them quite large, and none of
   which had been mapped.

   I haven't seen the quality of the outbuildings in the source data,
   and maybe I would change my mind if I did, but I think if we're
   going to do this import properly, we're going to have to bring in
   the other half of the data. I had seen in the original import
   instructions that small buildings were being excluded - was there a
   reason for this?

   I also want to say: given ho

Re: [Talk-GB] Possible Unattributed Map on Labrokes Website

[Tim Waters]

I think it's Blipstar  - a UK company who provide store locator tools

Looking at their example map
https://blipstar.com/blipstarplus/examples it seems to be the default
to hide the attribution (via CSS media query) on narrower window
widths

Tim

On Fri, 8 Feb 2019 at 13:31, Robert Whittaker (OSM lists)
 wrote:
>
> On Fri, 8 Feb 2019 at 09:43, Steve Pointer  wrote:
> > >Not sure if this is the right place to ask but is there anyone who can 
> > >look at https://thegrid.ladbrokes.com/en/shoplocator to see if they are 
> > >using OpenStreetmap data without proper attribution?
> >
> > In Firefox if you right click on the map -> This Frame -> Show only this 
> > frame
> >
> >  then the map has OSM tag at the bottom.
>
> Nice spot. The frame is showing
> https://viewer.blipstar.com/map?uid=2470030=10=true=nearest=auto==true=NW1
> . If you vary the width of the browser window it seems that the
> attribution at the bottom disappears if it's narrower than some
> critical value. Also, the attribution that is shown isn't technically
> compliant -- see https://www.openstreetmap.org/copyright . It appears
> the map etc is being provided as a service by http://www.blipstar.com/
> using a Mapbox map. I suspect it's one of those two that we really
> need to convince to do better with the attribution. Did I remember
> reading somewhere else that it was a known issue / bone of contention
> that Mapbox were providing a service with unattributed or incorrectly
> attributed maps to their clients?
>
> Robert.
>
> --
> Robert Whittaker
> https://osm.mathmos.net/
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

[OSM-talk-be] Weekly Riot chat digest - Volume 3 - 24/12/2018 - 30/12/2018

[Tim Couwelier]

Hi all.

New edition is up:
https://forum.openstreetmap.org/viewtopic.php?pid=732083#p732083
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Weekly Riot chat digest - Volume 2 - 17/12/2018 - 23/12/2018

[Tim Couwelier]

Hi all,

a bit later then usual (with the holidays and all):
https://forum.openstreetmap.org/viewtopic.php?pid=731339#p731339

(going with the link this time, as it was pointed out in most replies the
history is copied along, creating overly large e-mails)
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Weekly Riot chat digest - Please switch off copying the original!

[Tim Couwelier]

Point taken. Should it be desired among the mailing-list crowd, I could
just stick to sending a link to an external page with the info, rather then
including it all within the e-mail?
As a demo: Jonathan was kind enough to mirror it here:
https://openstreetmap.be/2018/12/17/weekly-riot.html


Op di 18 dec. 2018 om 09:51 schreef Hubert Christiaen <
hubert.christi...@telenet.be>:

> Colleagues,
>
> I received some long messages (28 Kb) containing only 2 lines of new
> information. Please switch of the copying of the original message when
> it is not needed as in this case. This is mostly an issue for users of
> Outlook, which copies the original message without showing it in the
> answer and in most cases thus without the sender noticing it.
>
> Sincerely,
> Hubert
>
> --
> Hubert Christiaen
> Bloesemlaan  17
> 3360 Korbeek-Lo
> Belgium
>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

[OSM-talk-be] Weekly Riot chat digest - Volume 1 - 10/12/2018 - 16/12/2018

[Tim Couwelier]

First of all, a short introduction. Based on discussion in chat, we feel
it'd be good to open up about what's discussed in the Riot (or IRC) chat
channel, and distribute a summary of it (on a weekly basis) through forum
and mailinglist. For now this is a one-man-operation, we'll see how it
evolves over time.

Input/feedback/extended discussion can be had through talk-be, the riot
channel or the belgian subsection of the openstreetmap.org fora.
(Note: I'm fully aware I'm probably a highly 'unknown' person to many
people within this mailinglist. I've talked through trying to do this with
Joost, and was met with his approval. If anyone has questions about me or
my part in this, do let me know.)







*Monday 10/12/2018*

Glenn informs about how to map a 'tractorsluis' (physical construction to
allow tractors to pass, but not normal cars).
https://wiki.openstreetmap.org/wiki/Tag:barrier%3Dsump_buster

bxl-forever asks about how to map a certain type of barrier/fence.
fence_type = railing seems the best fit (
https://wiki.openstreetmap.org/wiki/Key:fence_type )

Seppe points out there's a Mapillary grant program for camera's.
Requires 50k+ uploaded pictures to be taken into consideration.
https://docs.google.com/forms/d/e/1FAIpQLScrPJcRGlh_FQCQCuZkk0tCK9317odk5RYeYfI2UruCzJW31Q/viewform

Jakka suggests supplying a basic simple template using osm-be tiles to
implement a map into a website.
Most agree this would be good, issue created on the osmbe-website github.


*Tuesday 11/12/2018*

Timcouwelier points out tiles are loading very slow,.
Escada confirms there's indeed issues, linking to the status page (
https://wiki.openstreetmap.org/wiki/Platform_Status )

Jakka asks about how to map mobil telephone antennae attached to power
towers.
Lionel_giard replies *'you only use
communication:mobile_phone/radio/...=yes/no for the transmission equipment.
The others tags are all for the structure. '*


*Wednesday 12/12/2018*

Timcouwelier asks about tagging suggestions for an entrace ramp to a
hospital with an overhead roof.
Tagging as a bridge seems an option, but would not match with using
'tunnel' for the covered part under the building + it's rendered overly
heavy. Consensus is to split the ramp and mark an  'incline = up' and
'incline = down', but to not  add percentage as it's unknown.
https://taginfo.openstreetmap.org/keys/incline#values apparantly shows 2
uses for 'incline = steep_as_hell'

Lionel_giard ask about how to map an 'internaat' (living quarters at school
for students not going home during the week).
This is a recurring question, but there's nothing beyond building =
residential. However, it should still clarify sufficient in combination
with amenity = school around it.

Timcouwelier asks about options in Overpass Turbo: building on a query that
selects all ways based on having a node last touched by a given user, is
there an option to do that for TWO users and style them differently?
Joost offers a workaround through mapcontrib, by using two layers with a
different query, and working with two different styles.

s8evq asks about possible missing attribution to OSM in the maps used by
postnl.be.
Contact is made based on the following input by Joost:
*If you want to deal with it yourself, add it to this list and write
them a message: *
*https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Websites#List_2*
<https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Websites#List_2>

A reply from wegspotter to a question by Glenn on 'slow roads', raises
discussion on how to deal with getting 'complete' info, as the requirements
for the vicinal ref (
https://wiki.openstreetmap.org/wiki/WikiProject_Belgium/Conventions/Slowroads
) requires info that's not visible possible to retrieve in the field.

*Thursday 13/12/2018*

Discussion on the vicinal roads continues.
Neither atlas number, the vicinal_type (sentier vs chemin) can be found
without external sources.
Tim re-links the WMS for the atlas for most provinces, but before editing
them into the wiki, Joost plans to check to what extent they are 'within
license' to use as a source. Suggestion is made (by himself) to remind him
from time to time not to forget about this.

Discussion on the wiki status for the vicinal road tagging, raises issues
about communication of such wiki edits, where escada points out ideally
issues like that should get picked up either in riot channel or through the
mailing list. Timcouwelier adds that ideally, to keep discussion / progress
/ knowledge / information spread widely, it'd probably be a good idea to
created a weekly digest of what's discussed in the riot channel, both for
later reference but also to open up the discussions with those not actively
reading the channel.

That in mind, timcouwelier creates a framapad to start taking notes for a
weekly digest, to be sent to talk-be, and writes up a first prelimary
version for this week.

Lionel_giard asks about rendering status - it's still down, and there seem
to b

Re: [Talk-ca] Multiple university departments in one building

[Tim Elrick]

Thank you, John and James.

Place d'Orleans looks nice. And, of course, we do not map for the 
renderer. However, as the departments that I want to map are on 
different floor levels and not specifically in this or that corner of 
the building, the approach I have taken is still not pleasing.


I guess, I will read into the Simple Indoor Tagging schema then and see 
how it works out.


Cheers,
Tim

On 2018-11-28 07:37, john whelan wrote:
Have a look at OSMand and see what it looks like.

Generally it is considered bad practise to map for the renderer.

As an alternative take a look at Place d'Orleans shopping center in
Orleans Ontario each unit is mapped in outline with the appropriate tags
added.

If you look at mapping a building with floors I've seen office outlines
before now.

Cheerio John

On Tue, 27 Nov 2018, 8:00 pm Tim Elrick mailto:o...@elrick.de> wrote:

Hello,

I am trying to contribute to filling the gaps on McGill campus on
OSM at
the moment and I ran into a problem which I haven't fund a satisfactory
answer for yet.

We have several buildings on campus which are home to multiple
departments, all buildings have a building name.

I looked the OSM wiki feature pages and in the OSM forum and found the
following approach as apparently standard procedure:
1) Map building outline with building = university , name= XYZ
building,
operator=McGill University
2) Add a node inside the building for each department with
office=university, description=department name
This produces irritating blue dots in the outline of the building, see
https://osm.org/go/cIrNt~j2u <https://osm.org/go/cIrNt%7Ej2u>

When I looked at other universities, I found e.g. a node with
amenity=university, name=department name. But when looking at the OSM
wiki feature page for universities[1] it says you only should use
amenity=university for the whole campus.

The office tag I found when looking for multiple businesses in one
building, but the blue dot aren't nice.

Any suggestions on how to map this elegantly?

Thank you,
Tim (aka AGeographer)

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university

___
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] Multiple university departments in one building

[Tim Elrick]

Hello,

I am trying to contribute to filling the gaps on McGill campus on OSM at 
the moment and I ran into a problem which I haven't fund a satisfactory 
answer for yet.


We have several buildings on campus which are home to multiple 
departments, all buildings have a building name.


I looked the OSM wiki feature pages and in the OSM forum and found the 
following approach as apparently standard procedure:
1) Map building outline with building = university , name= XYZ building, 
operator=McGill University
2) Add a node inside the building for each department with 
office=university, description=department name
This produces irritating blue dots in the outline of the building, see 
https://osm.org/go/cIrNt~j2u


When I looked at other universities, I found e.g. a node with 
amenity=university, name=department name. But when looking at the OSM 
wiki feature page for universities[1] it says you only should use 
amenity=university for the whole campus.


The office tag I found when looking for multiple businesses in one 
building, but the blue dot aren't nice.


Any suggestions on how to map this elegantly?

Thank you,
Tim (aka AGeographer)

[1] https://wiki.openstreetmap.org/wiki/Tag:amenity=university

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

Re: [Talk-GB] When is a hedge a wood?

[Tim Waters]

At first look I thought this was a once-hedge, a hedge that's been left to
itself. But each tree is equally spaced, looks the same age, doesn't seem
pollarded or coppiced as what you might expect a tree in a hedge to be, and
so I don't think that's the case now.  So to my mind now, it's a fence,
with individual mappable trees.

A hedge implies a barrier of kinds.



On 26 August 2018 at 20:35, Martin Wynne  wrote:

> Rural boundaries can be extraordinarily difficult to map. For example, is
> this:
>
>  https://goo.gl/maps/FtjMZiwNj542
>
> a) a fence,
>
> b) a hedge,
>
> c) a very narrow wood,
>
> d) all three at the same time?
>
> Is the area in front of it
>
> a) grass,
>
> b) highway,
>
> c) both?
>
> (Not mapping from Google, I walked along there recently.)
>
> Often a wood adjoins an open area such as a water meadow. If there is a
> fence between them, the boundary is clear, even if the wood canopy overlaps
> into the meadow. If there isn't a fence, where do you put the boundary? The
> edge of the canopy? The line of tree trunks? Some imaginary line between
> the two?
>
> Some trees are very large and their branches can extend a significant
> distance - across a river for example.
>
> Thanks.
>
> Martin.
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] Mapping horse steps?

[Tim Waters]

Wikipedia calls them "mounting blocks"
https://en.wikipedia.org/wiki/Mounting_block

I spotted a new ish concrete one the other day which had an official
looking "horse riders may mount here" sign above it, but I don't think
those signs are in the HM Sign Manual.  I prefer "mount" to "dismount" and
it might reflect the intended purpose of it, it's easier to fall off than
climb on the beasts!

Going back to the wikipedia page, these block steps are not only horse
specific, but could have been used to get into carts and buggies, too.


Tim


On 28 August 2018 at 01:32, Warin <61sundow...@gmail.com> wrote:

> On 27/08/18 23:28, Andy Townsend wrote:
>
>> On 27/08/18 13:32, Edward Catmur wrote:
>>
>>> amenity=horse_dismount_block has 4 occurrences, all in the north of
>>> England.
>>>
>>
>> I think I'm responsible for half of those - happy to pick a different tag
>> if someone's got a better idea!
>>
>> There are actually a selection of tags used for this sort of thing:
>>
>> --
>> 
>> 
>> -- Horse mounting blocks
>> --
>> 
>> 
>>if (( keyvalues["amenity"]   == "mounting_block"   ) or
>>( keyvalues["bridleway"] == "mounting_block"   ) or
>>( keyvalues["historic"]  == "mounting_block"   ) or
>>( keyvalues["horse"] == "mounting_block"   ) or
>>( keyvalues["horse"] == "mounting block"   ) or
>>( keyvalues["amenity"]   == "mounting_step") or
>>( keyvalues["amenity"]   == "mounting_steps"   ) or
>>( keyvalues["amenity"]   == "horse_dismount_block" )) then
>>   keyvalues["man_made"] = "mounting_block"
>>end
>>
>> https://github.com/SomeoneElseOSM/SomeoneElse-style/blob/
>> master/style.lua#L2211
>>
>> all very low usage.
>>
>
> horse=* is used as an access thing .. so I'd not encourage its use for
> other things.
> e.g. there exists horse=dismount .. I think that means the rider must get
> off the horse to proceed .. an access condition, not a facility to assist
> dismounting.
>
> I'll raise it on the tagging list and see what they come up with.
> My personal preference at the moment is for man_made=mounting_steps. But
> that is just me.
>
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] Can somebody give me a hint please?

[Tim Frey]

Hi Jeroen,

when it was taken on a mobile, then you have a high likelihood that the picture 
has exif geo tags... 
Do you think that this is the case?

Best
Tim


-Ursprüngliche Nachricht-
Von: Jeroen Baten  
Gesendet: Dienstag, 19. Juni 2018 10:35
An: talk@openstreetmap.org
Betreff: [OSM-talk] Can somebody give me a hint please?

Hi,

This is a newbie question:
so I have an aerial photo of a part of central France but I don't know the 
exact location.
I know it is max 10 minutes from a city.
I want to find the place on the map.
My photo shows two roads in an angle.
Is there a way I can use to locate where this is?
Some sort of low level GIS query maybe?

Looking forward to your answers.

Kind regards,
Jeroen Baten


-- 
Jeroen Baten  | EMAIL :  jba...@i2rs.nl
   _  __  | web   :  www.i2rs.nl
  |  )|_)(_   | tel   :  +31 (0)345 - 75 26 28
 _|_/_| \__)  | Molenwindsingel 46, 4105 HK, Culemborg, the
Netherlands

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


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

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tim Frey]

Hi Tobias,

thanks a lot - I'll give it a  try and see what comes out.

Best
Tim

-Ursprüngliche Nachricht-
Von: Tobias Knerr <o...@tobias-knerr.de> 
Gesendet: Samstag, 19. Mai 2018 14:09
An: Tim Frey <tim.f...@iunera.com>
Cc: talk@openstreetmap.org
Betreff: Re: AW: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - 
Feedback and ideas wanted

Hi Tim,

On 16.05.2018 10:16, Tim Frey wrote:
> I like the Wikipedia and in special the Wikivoyage direction also. 
> Does somebody know the best touchpoints to get in contact with the 
> community there?

I'm not familiar enough with their communities to give a recommendation.
However, Commons does "partnerships" with owners/maintainers of media
collections: https://commons.wikimedia.org/wiki/Commons:Partnerships
You could give the contact listed there a try.


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

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tim Frey]

Hi All,

 

short sum up:

We are discussing about “open sourcing/open contenting” our STAPPZ POI picture 
mapping APP for the OSM community and what prerequisites we need to fulfill to 
make this a success.

 

@Kathleen

Thanks a lot for your insights Kathleen, those helped a lot in our internal 
discussions. I appreciate that a lot!

 

@Milo
Thank you so much Milo. Yes, please do!

 

We discussed in our company about the next steps that we would need to take to 
contribute to OSM.

At the end, our discussions boil down to the acceptance and contributions of 
OSM mappers to the picture POI database. 

Logically, it only makes sense for us to take the effort to open source in a 
step by step way, when we have enough support from the community.
In order to make it a sustainable success, we’d like to have a group of people 
or fellow companies who would contribute and help to spread the word. 

 

Therefore, I’d like to ask who would we open minded to support our efforts and 
contribute?

 

If someone has additional thoughts or ideas, please add. 

Best

Tim

 

 

Von: Milo van der Linden <m...@dogodigi.net> 
Gesendet: Freitag, 18. Mai 2018 15:13
An: Kathleen Lu <kathleen...@mapbox.com>
Cc: Tim Frey <tim.f...@iunera.com>; OSM Talk <talk@openstreetmap.org>
Betreff: Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - 
Feedback and ideas wanted

 

@Tim,

I can get you in touch with the people at  <http://healthsites.io> 
healthsites.io, they have a model that is complimentary to OSM to maintain a 
lot of information about healthcare around the world where not all attributes 
can be added to OpenStreetMap.

 

2018-05-17 1:17 GMT+02:00 Kathleen Lu <kathleen...@mapbox.com 
<mailto:kathleen...@mapbox.com> >:

Tim - 
For GDPR, there's not a lot of clarity yet because the regulation is only going 
into effect next week. I suspect in practice, the answer with be that the 
processing is legal because it is to fulfill the contractual terms (of the 
creative commons license requiring attribution, which is a contract with the 
data subject that basically anyone can accept), and then if removal is later 
requested, then you can remove the image in question (or just the attribution, 
if that's what the person prefers) from your site/app (this is polite anyway). 
The person will have to ask each place for removal, since each place is using 
the image is issuing it for their own purposes. (Generally, with an open 
dataset, you're not going to have a list of everyone who got the dataset so you 
can't send them an update.)

I'm not sure if a photograph catching someone in the background would be a 
problem or not, since they are inadvertently captured and there's no other info 
about them, but I suppose it would be polite to remove or blur the photo if 
someone objected. 

-Kathleen

 

On Wed, May 16, 2018, 1:16 AM Tim Frey < <mailto:tim.f...@iunera.com> 
tim.f...@iunera.com> wrote:

Thank you Kathleen and Tobias,

This is some very valuable insight.

 

>From our terms of use, we could likely open the content, but you are right – 
>it is about what users think. Hence, we will and can ask them. Thanks a lot 
>for rising this point. 

One rising concern, when I read your text, Kathleen, is the GDPR – what happens 
if a user wants content deleted and it is already copied all over the web by an 
open license. Or even worse, a user uploads a picture of a scenery and there 
are human faces in the scenery .. and this picture is distributed. I see 
potential problems here for us and the organizations using the pictures. 
Additional thoughts please? 

 

I like the Wikipedia and in special the Wikivoyage direction also. Does 
somebody know the best touchpoints to get in contact with the community there?

 

In general, I agree to what you said that manual work for content filtering and 
legal issues would be needed – what is also one point for us to discuss with 
the community first: We can provide the software and open source the stuff, but 
to create valuable content for the specific use cases, we’ll need the community 
and partners who share common goals to get this successfully going. So all 
ideas in this direction are welcome, too.

Best

Tim

 

Von: Kathleen Lu <kathleen...@mapbox.com <mailto:kathleen...@mapbox.com> > 
Gesendet: Mittwoch, 16. Mai 2018 00:25
An: Tobias Knerr <o...@tobias-knerr.de <mailto:o...@tobias-knerr.de> >
Cc: Tim Frey <tim.f...@iunera.com <mailto:tim.f...@iunera.com> >; 
talk@openstreetmap.org <mailto:talk@openstreetmap.org> 


Betreff: Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - 
Feedback and ideas wanted

 

Hi Tim,

Your app and what you hope to do with it both sound interesting. I hope you are 
successful.

Here's some more information on the open licensing front to consider:

 - In order to have the legal rights necessary to "open" the mat

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tim Frey]

Thank you Kathleen and Tobias,

This is some very valuable insight.

 

>From our terms of use, we could likely open the content, but you are right – 
>it is about what users think. Hence, we will and can ask them. Thanks a lot 
>for rising this point. 

One rising concern, when I read your text, Kathleen, is the GDPR – what happens 
if a user wants content deleted and it is already copied all over the web by an 
open license. Or even worse, a user uploads a picture of a scenery and there 
are human faces in the scenery .. and this picture is distributed. I see 
potential problems here for us and the organizations using the pictures. 
Additional thoughts please? 

 

I like the Wikipedia and in special the Wikivoyage direction also. Does 
somebody know the best touchpoints to get in contact with the community there?

 

In general, I agree to what you said that manual work for content filtering and 
legal issues would be needed – what is also one point for us to discuss with 
the community first: We can provide the software and open source the stuff, but 
to create valuable content for the specific use cases, we’ll need the community 
and partners who share common goals to get this successfully going. So all 
ideas in this direction are welcome, too.

Best

Tim

 

Von: Kathleen Lu <kathleen...@mapbox.com> 
Gesendet: Mittwoch, 16. Mai 2018 00:25
An: Tobias Knerr <o...@tobias-knerr.de>
Cc: Tim Frey <tim.f...@iunera.com>; talk@openstreetmap.org
Betreff: Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - 
Feedback and ideas wanted

 

Hi Tim,

Your app and what you hope to do with it both sound interesting. I hope you are 
successful.

Here's some more information on the open licensing front to consider:

 - In order to have the legal rights necessary to "open" the material your 
users contributed, you would likely needed to have gotten a perpetual 
irrevocable royalty-free license with an unlimited right to sublicense (not 
limited to only your affiliates, etc), or an assignment, though the latter is 
far more than needed.

 - But would use of the photos/text outside of the STAPPZ app be consistent 
with your users' expectations for their photos/text? If no, then even if you 
can legally do it you may be passing an unwelcome burden to an open community.

 - What open license would you provide the photos/text under? CC-BY is a common 
one for photos, though it is not inherently compatible with ODbL (the license 
for OSM). There is however a waiver template that makes CC-BY it compatible 
with ODbL: https://blog.openstreetmap.org/2017/03/17/use-of-cc-by-data/

There is the separate issue with CC-BY that users are supposed to attribute the 
author. Do your users expect/want their names to be attributed to the photos if 
they are used outside the App? This may raise data privacy issues a well 
(especially with GDPR coming into enforcement).

 - As for open source of the code, you'll have a choice between a permissive 
license (e.g. MIT, BSD, ISC, DWTFYW) or a copyleft license (e.g. GPL, LGPL) or 
something in between (MPL, Apache). Permissive licenses make it easier for 
someone else to take over the project, though there is the possibility that 
they will take it in a direction you do not like (e.g., build a new version but 
not open the code to the new version). Copyleft licenses are intended to guard 
against this, but most companies do not like working with copyleft code and 
many ban it, so there would be a smaller pool of potential interest.  

You can see OSMF's current open source projects here: 
https://github.com/openstreetmap. The licenses currently used are ISC, BSD, 
DWTFYW, Apache 2.0, and GPL.

Best of luck! 

-Kathleen

 

On Tue, May 15, 2018 at 2:45 PM Tobias Knerr <o...@tobias-knerr.de 
<mailto:o...@tobias-knerr.de> > wrote:

Hi Tim,

On 11.05.2018 17:19, Tim Frey wrote:
> Out of this, we consider, heavily, to “open source” the licensing of the
> user created STAPPZ content for the OSM community. In addition, we also
> consider to open source the backend of STAPPZ and the IOS and Android
> app to make a community project out of it.

I'm going to split this reply into two parts: About the content, and
about the software itself.


As for the content, a lot depends on if you can publish the images under
the terms of an open license.¹ That's a legal question, but probably
also a bit of a social one (i.e. would this be in line with what the
creators expected when they shared their images on your app, or would
they be unpleasantly surprised/unhappy about this).

Assuming the answer is that yes, you can publish them, the next question
is what to do with the images. OSM does not currently have an image
hosting platform, so if we're only talking about contributing the
images, they would need to be donated to a separate platform.

The obvious recipient for such an image donation would be Wikimedia
Commons, as they're the most 

Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tim Frey]

Hello Milo,

 

thanks a lot for your long and detailed feedback. I appreciate that a lot.

 

The use cases you described with waste, hazards and so on are interesting – for 
such cases, we implemented a first version to tag posts… so in theory it would 
be possible with the current API.

My key thought is: How and where do we get more users who tell the stories and 
get started with this? Someone has suggestions?

 

The POI database – my original key thought was to link the OSM POIs like 
fountains, restaurants – barely everything to descriptions and pictures to 
provide the most value added to the community.
I’m not certain if this is what you meant by sustainable development goals. 
Therefore, please elaborate if I got this right?

Best
Tim

 

Von: Milo van der Linden <m...@dogodigi.net> 
Gesendet: Sonntag, 13. Mai 2018 13:43
An: Tim Frey <tim.f...@iunera.com>
Cc: OSM Talk <talk@openstreetmap.org>
Betreff: Re: [OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - 
Feedback and ideas wanted

 

Hello Tim,

thank you for the broad explanation of your product!

I like the concept and me have some particular use cases for which we now use 
Flickr. I would love to have an alternative to that which could be maintained 
by a community that is closely related to OpenStreetMap. My usecases are 
particular for non-google-dominated areas; where users not only enter travel 
pictures; but also pictures related to particular causes; for instance waste, 
standing water, hazards and more. They are users which are not so tech-savvy 
but have an urgent need to tell "a story" to government, officials, police or 
other matters of public interest.

So a POI database with the possibility to enter pictures and information that 
relate to the Sustainable Development Goals would be awesome. I would love to 
collaborate on such a project.

Kind regards

Milo

 

 

2018-05-11 17:19 GMT+02:00 Tim Frey < <mailto:tim.f...@iunera.com> 
tim.f...@iunera.com>:

Greetings OSM community,

 

my name is Tim and I’m one of the creators of the STAPPZ app. We want feedback 
from the community about our open sourcing plan of the STAPPZ app content.

 

What is STAPPZ: 

STAPPZ is in short an app and a server backend application. The original idea 
was to create crowdsourced version of an insider travel guide, where each user 
can contribute content.

That means, you open the app and you post some pictures and a text at a 
geolocation and when you are online, then the content is uploaded to the server 
and is available on a webmap. This way, you can create a personal travel diary 
map. Our original plan was to extend STAPPZ step by step to create not only 
travel guides, but to also add pictures of POIs

Example:  <https://maps.stappz.com/region/sicilia> 
https://maps.stappz.com/region/sicilia 

Android App demo video:  <https://www.youtube.com/watch?v=MDBh-VrU2Ig> 
https://www.youtube.com/watch?v=MDBh-VrU2Ig 

Explanation slides:  
<https://de.slideshare.net/TimFrey2/travel-guides-are-old-news-being-a-local-insider-everywhere-is-today>
 
https://de.slideshare.net/TimFrey2/travel-guides-are-old-news-being-a-local-insider-everywhere-is-today
 

Background:

We managed to get featured with the app at conferences and in a lot of 
magazines (e.g. Computer Bild, Chip) and got over 10k downloads for Android, 
but, frankly speaking, we did not get mass adaption to create a sustainable 
ecosystem. Therefore, we as company had to focus on other projects to earn 
money for living ☹ . 

 

Feedback wanted:

We poured a lot of our personal tears and sweat in coding and marketing STAPPZ 
and today we think that STAPPZ could be used to create picture POI content for 
OSM. We see that need in special, because google maps is offering more and more 
picture POI content from users, and I, personally, do not know such an open 
datapod for open streetmap.

Out of this, we consider, heavily, to “open source” the licensing of the user 
created STAPPZ content for the OSM community. In addition, we also consider to 
open source the backend of STAPPZ and the IOS and Android app to make a 
community project out of it. However, we are a very small company and we cannot 
do that completely alone, we will need help and advice from the community. 

 

Technical details:

Internally, in the app and the backend, we use only OSM data and maps to ensure 
not being bound to legal contracts to google. The Android version is far more 
developed than the IOS version and has complete offline and caching 
functionality to allow posting of pictures form the gallery and to position the 
pictures on a map. Currently, the maps part of the app does not work for 
Android, but we want to enable it as soon as we have time. 

STAPPZ supports gallery uploads with exif data, cached content and many more 
things – if you got questions please ask.

 

Questions to the community:

What do you think about open sourcing

[OSM-talk] Open sourcing of POI pictures for OSM App/STAPPZ - Feedback and ideas wanted

[Tim Frey]

Greetings OSM community,

 

my name is Tim and I’m one of the creators of the STAPPZ app. We want feedback 
from the community about our open sourcing plan of the STAPPZ app content.

 

What is STAPPZ: 

STAPPZ is in short an app and a server backend application. The original idea 
was to create crowdsourced version of an insider travel guide, where each user 
can contribute content.

That means, you open the app and you post some pictures and a text at a 
geolocation and when you are online, then the content is uploaded to the server 
and is available on a webmap. This way, you can create a personal travel diary 
map. Our original plan was to extend STAPPZ step by step to create not only 
travel guides, but to also add pictures of POIs

Example: https://maps.stappz.com/region/sicilia 

Android App demo video: https://www.youtube.com/watch?v=MDBh-VrU2Ig 

Explanation slides: 
https://de.slideshare.net/TimFrey2/travel-guides-are-old-news-being-a-local-insider-everywhere-is-today
 

Background:

We managed to get featured with the app at conferences and in a lot of 
magazines (e.g. Computer Bild, Chip) and got over 10k downloads for Android, 
but, frankly speaking, we did not get mass adaption to create a sustainable 
ecosystem. Therefore, we as company had to focus on other projects to earn 
money for living ☹ . 

 

Feedback wanted:

We poured a lot of our personal tears and sweat in coding and marketing STAPPZ 
and today we think that STAPPZ could be used to create picture POI content for 
OSM. We see that need in special, because google maps is offering more and more 
picture POI content from users, and I, personally, do not know such an open 
datapod for open streetmap.

Out of this, we consider, heavily, to “open source” the licensing of the user 
created STAPPZ content for the OSM community. In addition, we also consider to 
open source the backend of STAPPZ and the IOS and Android app to make a 
community project out of it. However, we are a very small company and we cannot 
do that completely alone, we will need help and advice from the community. 

 

Technical details:

Internally, in the app and the backend, we use only OSM data and maps to ensure 
not being bound to legal contracts to google. The Android version is far more 
developed than the IOS version and has complete offline and caching 
functionality to allow posting of pictures form the gallery and to position the 
pictures on a map. Currently, the maps part of the app does not work for 
Android, but we want to enable it as soon as we have time. 

STAPPZ supports gallery uploads with exif data, cached content and many more 
things – if you got questions please ask.

 

Questions to the community:

What do you think about open sourcing the content, the app and so on? Do you 
see a value added for the OSM community?
Would you support the project to open source it?

Do you know companies who would be interested in participating? We are open for 
collaborations here.

Do you have own thoughts and points about it? 

 

I’d really like to learn more here. STAPPZ is a really personal baby for us, 
and we’d like that it continues to live. 

 

Thanks a lot for everyone in advance who reads that – and even more thanks to 
the ones who are going to reply with feedback and thoughts.

Even if you just think the idea is good or bad – please tell us that we get a 
picture how the whole community sees it.

Mit freundlichen Grüßen / Kind regards

Tim Frey

 

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

Re: [OSM-talk] Android program with a custom map style

[Tim Teulings]

Hello Mateusz,

I am looking for an Android application that has bicycle-focused map 
style available offline.



I am looking for features like
- ability to distinguish road based on surface (=sand =dirt =asphalt 
should be easy to distinguish)

- oneway arrows displayed based also on oneway:bicycle, cycleway=opposite,
cycleway=opposite_lane tags, not only oneway tag
- displaying bicycle routes
- displaying detailed info about ferries across rivers (at least fee, 
opening_hours,

seasonal and description tags)

I am not expecting that application like this exists and I checked
https://wiki.openstreetmap.org/wiki/Comparison_of_Android_applications


You can use libosmscout (http://libosmscout.sourceforge.net/), which is 
a C++ framework/library for writing application using rendering, 
location lookup, routing, which should allow you to do most of the above.


Challenge: C++ under Android can be tricky, if you not use Qt (which is 
supported) and it is a framework, so you have to write your own 
application based on the libosmscout APIs around it.


--
Gruß...
   Tim

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

Re: [Talk-ca] Emergency Request for Tasking Manager Trainer

[Tim Elrick]

Hi Jonathan & Rob,

As John mentioned task #91, the one that we set up last, and we are
about to set up another one for our next mapathon on March 20th (on
Khairpur in Pakistan though), I am happy to help out too.

For preparing the areas of interest (aoi) the project manager needs
either a geojson or a kml or a shapefile. If you want to draw on James'
offer to set up the tasking manager and just don't have the aoi as
geojson, I am happy to convert it and send it to James.

All the best for your mapathon (if Durham wasn't so far from MTL, I
would have joined in)!,

Tim

On 2018-03-08 14:44, Jonathan Brown wrote:

Excellent. The OSM community’s support is much appreciated.

 

Jonathan

 

*From: *john whelan <mailto:jwhelan0...@gmail.com>
*Sent: *Thursday, March 8, 2018 2:16 PM
*To: *Jonathan Brown <mailto:jonab...@gmail.com>
*Cc: *Matthew Darwin <mailto:matt...@mdarwin.ca>; Talk-CA OpenStreetMap
<mailto:talk-ca@openstreetmap.org>; Rob Halko
<mailto:rob.ha...@durham.ca>; Brock Baker <brock_ba...@kprdsb.ca>
<mailto:brock_ba...@kprdsb.ca>; Alasia, Alessandro (STATCAN)
<mailto:alessandro.ala...@canada.ca>
*Subject: *RE: [Talk-ca] Emergency Request for Tasking Manager Trainer

 

I think Matthew or James are the people to talk to.  I suspect it might
take them an hour or so which means there is an excellent chance of it
being made available before March 29th.

 

Cheerio John

 



___
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-be] Where to suggest/discuss the renderer?

[Tim Couwelier]

The problem is - whenever you try and get changes for the renderer - the
argument is they don't feel they should change the renderer to try and
influence the tagging. They care about rendering 'the tags that actively
get used'.

Be very carefull how you pitch the argument, or it'll instantly get a big
red 'denied' stamp on it merely based on that argument.

2018-02-23 8:22 GMT+01:00 marc marc :

> Le 23. 02. 18 à 07:44, Karel Adams a écrit :
> > Whence my repeated question: where or with whom can this be discussed?
>
> the tagging mailing for the schema
> https://lists.openstreetmap.org/listinfo/tagging
>
> github to use a current schema
> https://github.com/gravitystorm/openstreetmap-carto/
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] Fwd: [OSM-talk] Highway=trunk : harmonization between countries ?

[Tim Couwelier]

There's always an inherit 'gap' between 'what does government intend the
road for' and 'how does the road actually look'.
Terms such as 'primary' and 'secondary' roads have meaning in planning
context.
In Flanders we have the 'Ruimtelijk Structuurplan Vlaanderen' which
classifies which roads are 'hoofdwegen' and which are primary (divided in
classes I and II)
Each Province has a 'Provinciaal Ruimtelijk Structuurplan', which
clasfficies which roads are secondary. (divided in classes I, II and III)
Each city/town is also supposed to have a 'Gemeentelijk Mobiliteitsplan'
which states which classification 'local' roads get, divided in classes I,
II and II)

There's potential for a very close match:

E and A roads are 'hoofdwegen'  => Tag as 'motorway'
The primary roads (regardless of their 'collecting' or 'connecting'
subtyping)  => tag as primary
The secondary roads (also regardless of their subtyping) => tag as secondary
The local roads types I and II => tag as tertiary
The local roads types III (aka 'the rest') => multitude of tagging options.

With the current tagging system and how it's applied in Belgium, we go
somewhere in between, but it's fairly 'clean' as it stands.
We don't look at what the government says, we go by 'how it looks' and link
that to the road numbering system for the' gewestwegen'.
Key point to decide on is if we SHOULD bother with 'intent' rather then
'reality', as 'mapping what's on the ground' is a basic principle.


Relating back to the post Joost distributed:
I do agree with most of the points, although 'trunk' is the odd part out.
'trunk' we don't use as a hierarchical classification, but to point out
it's a strech with a certain setup, i.e. forbidden for cyclists and such.


To end I'll repeat the example I've given in the riot channel about the
subtle difference between 'intended' and 'assumed':
The R32 ringroad around Roeselare.
Given it's a 'ringroad' it's classified in OSM as 'primary' all around.
But from the 'planning context' viewpoint, only the last stretches towards
the E403 are 'primary', and the majority is only 'secondary'. While the
road goes around Roeselare, it's function is to get people from and towards
the E403 'in either direction'. Due to the E403 being present, it's never
the intention to use the R32 to go around the entire end, as the E403 helps
cover that function.

PS:
If you have a look at said area, you'll also notice a part of 'trunk'.
Rendering wise, it 'feels' like the classification is different, and in
reality it looks different, but its function isn't really different at all.
Along with the aforementioned nuance primary/secondary, it's a second
example on how you could interpret on the same road.


2018-02-22 21:45 GMT+01:00 joost schouppe :

> Hi,
>
> Not wanting to change current consensus in Belgium, but I wonder how close
> this would be to current mapping practice in Belgium, and if it would be a
> way of thinking that could help in some current edge cases.
>
> -- Forwarded message --
> From: Fernando Trebien 
> Date: 2018-02-15 19:14 GMT+01:00
> Subject: Re: [OSM-talk] Highway=trunk : harmonization between countries ?
> To: t...@openstreetmap.org
>
>
> Landing on this discussion several months late. I've just heard of it
> by reading a wiki talk page [1].
>
> Since 13 February 2009, the wiki [2] criticises highway classification
> as problematic/unverifiable. This has also been subject to a lot of
> controversy (and edit wars) in my local community (Brazil), especially
> regarding the effect of (lack of) pavement.
>
> In trying to achieve greater consensus some years ago, I decided to
> seek opinions elsewhere and finally I arrived at this scheme [3] which
> I think is very useful, if not perfect yet. It can be easily
> summarised like this:
> - trunk: best routes between large/important cities
> - primary: best routes between cities and above
> - secondary: best routes between towns/suburbs and above
> - tertiary: best routes between villages/neighbourhoods and above
> - unclassified: best routes between other place=* and above
>
> For example, the best route between two villages would be at least
> tertiary. So would be the best route between a village and a town or a
> city. Parts of this route might have a higher class in case they are
> part of a route between more important places.
>
> It surely raises the problem of determining optimal routes. Maybe a
> sensible criterion would be average travel time without traffic
> congestion. A number of vehicles may be selected for this average -
> could be motorcycle+car+bus+truck, or simply car+truck.
>
> Early results in my area [4, in Portuguese] seem promising and have
> produced more consensus than any previous proposals. To me, this
> method seems to:
> - resist alternations in classification along the same road
> - work across borders (where classification discontinuities are
> expected because each country is 

Re: [OSM-talk-be] temporary cycle routes

[Tim Couwelier]

I'll go with a 'no' here.

Let me explain why:
Both the main routes (fietsostrade, fietssnelweg, whatever you wish to call
it) and the 'BFF' ('Bovenlokaal functioneel fietstroutenet) are by no means
an indication of actual infrastructure being present, nor is it a measure
of quality for the infrastructure that's there.
The point of a map is to show what's there. Neither BFF nor the structural
network of 'bike highways' are relevant in that aspect, they only show
where we'd eventually like to see proper infrastructure.

Don't get me wrong, if there's a suitable way to give the proper bike
highways a little lovin' on the map, I'm all for it. But only when it's
actually there.
Stretches that aren't  there, or that are on the BFF but the cycleways are
mapped as part of the other infrastructure there, probably shouldn't be
mapped as such.

Let me illustrate with an example, the connection 'Roeselare - Torhout',
along the train line:
- between Spoorweglaan and Mandeldreef the trajectory is drawn very badly.
- The stretch between Mandeldreef and Koning Leopold III-laan is yet to be
constructed (but at least building permit is in, afaik)
- Along the Regina Woutersweg there's so seperate bike infrastructure
- North of the Wijnendalestraat the bike path suddenly stops. The extension
of the currently present trajectory would run right across a (trucking)
transport company, and there's no opening in sight.
- it assumes a crossing below a bridge (R32), where there's no room between
the current road and train tracks (concrete bridge pillars in the way)
- the entire remaining stretch up to Stationsstraat in Gits is NOT THERE.
- 

How would one suggest mapping a such vision?



I will however state I'm in favor of covering the proper stretches through
relations, very much like the node networks, and what's on OpenCycleMap.
Sticking to 'mapping what's on the ground' would - to me - seem the best
way to go.
If there's clear intent on finishing missing links (like a piece in
Zwevegem, on the Guldensporenroute) could probably very early onwards get
mapped as 'under construction'.





2018-02-01 16:29 GMT+01:00 Ben Abelshausen :

> In London some of the routes are mapped as proposed, it's a bit annoying
> if you don't know that they are just proposed and not actually there:
>
> https://www.openstreetmap.org/relation/6691788
>
> Rendering is a dotted version of the normal line on the cycle layer:
>
> https://www.openstreetmap.org/#map=18/51.54524/-0.01871=C
>
> So, not sure if we should be mapping this if they don't exist yet... but
> if it's an 'official' detour why not? Some of these routes are only virtual
> anyway and not signed at all.
>
> Cheers,
> Ben
>
> On Thu, Feb 1, 2018 at 2:55 PM, joost schouppe 
> wrote:
>
>> Hi,
>>
>> I got an interesting question today. As the Flemish "fietsostrades"
>> (fietssnelwegen, or cycle highways) are taking shape, so they are being
>> mapped in OSM. People are already using the data, even though in reality,
>> this is till very much a project.
>>
>> In more and more places, parts are completely ready, but then just stop.
>> And in some cases, there is an "official detour" of the fietsostrade. So
>> while the infrastructure is not there yet, in a sense the route is already
>> there.
>>
>> How do you think this should be mapped, if at all?
>>
>> --
>> Joost Schouppe
>> OpenStreetMap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-be] How to avoid that names are on all buildings

[Tim Couwelier]

Pitching in for a second, as it's my initial tag that got the ball rolling.

The name 'Clintonpark' indicates the combined area of the buildings and
their respective parkinglots, and is actually used as such.
It's not a 'street name', as the buildings have house numbers referencing
'Ter Reigerie', the street passing next to it.

At present, all the seperate buildings are tagged with the name
'Clintonpark', which is cluttered (and looks a bit messy), but isn't
entirely correct either.




2018-01-17 12:49 GMT+01:00 Marc Gemis :

> To answer how you have to map this, you first have to answer: what is
> "Clintonpark" ?
>
> - an area
> - a collection of buildings ?
> - a collection of identically named buildings ?
>
> m.
>
> On Wed, Jan 17, 2018 at 9:24 AM, Jakka  wrote:
> > Hi,
> >
> > Every building with a different house number is a office and named
> > "Clintonpark". Is this not to much same names on map.
> > I tried to put it in relations but validator do not liked it, building,
> > parking there are sharing same highways.
> > Is there a need solution.
> >
> > https://www.openstreetmap.org/note/1263904#map=17/50.95775/
> 3.10242=N
> >
> > thx
> >
> >
> > ___
> > Talk-be mailing list
> > Talk-be@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-be
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Tim Elrick]

There are in fact, quite some German based mappers, mapping in Canada.
So, you are right: let's just get more active mappers - worldwide; it
is, however, still easier to activate them locally.

I will pass on your positive experience with JOSM to my group for the
next event.

Cheers, Tim

Am 23.11.2017 um 10:32 schrieb john whelan:
>>I would have to run a query now to find out if the relative number of
active mappers is higher in one country than the other, but that's not
my point.

But how do you determine where a mapper lives and don't forget many
armchair mappers map in a different location to where they live.

JOSM and the building_tool plugin worked very well for our lot.  We did
ask them to come with JAVA installed and we only taught them enough JOSM
to map a building with the plugin.  Well we showed them a few more
things as they got more comfortable with it.

Cheerio John

On 23 November 2017 at 10:26, Tim Elrick <o...@elrick.de
<mailto:o...@elrick.de>> wrote:

Hi John,

Thanks for your feedback and background information.

I think, we are on the same page. I am concerned with quality too, while
mapping should remain enjoyable.

We shied away from JOSM for newbies because it seemed more technical to
my groups members. I personally like JOSM better, and the building
plug-in is great. Maybe I manage to convince the group to use it
next time.

I did not intend to call for experienced mappers to do all the
validation (I know it is tedious; however, correcting and esp. updating
makes OSM great and in some place much better than the official
sources). I think, that the group who initiated the mapping should
'clean up after themselves' (and I just wanted to affirm that we will do
that). I just wanted to express gratitude to mappers how do help out.

Once I am more into it, I am happy to help out validating other's work.

I did not mean to cheery pick when I quoted the validation website (I
very much appreciate the wiki page). I just wanted to make a point about
timing.

Regarding Canada, as a geographer I am fully aware of the fact Canada
having relatively less population, however, it has still almost half of
the population of Germany and the urban areas, which most of OSM mappers
are concerned with, might be relatively (to population) similar in size
(that's just a guess). I would have to run a query now to find out if
the relative number of active mappers is higher in one country than the
other, but that's not my point. The relative numbers do not matter, as
actual people do the mapping. And there, I hope we agree, the Canadian
OSM community could do with more active mappers.

Tim


Am 23.11.2017 um 07:54 schrieb john whelan:
The issue is the quality of the mapping, nothing else. I attended one of
these geoweek events and we used JOSM with the building_tool plugin. 
The mapping of buildings was accurate even though 75% of the mappers had
never used JOSM before.  There was no formal validation done but I
verified each mappers work as they did it.  I got the impression that
the mappers enjoyed the exercise and I think for me that was the most
important thing.  Mapping should be fun.

There was no mention of the work would be validated nor did we record
the mappers userids to ensure which mappers had mapped.  Other mappers
had marked tiles done on the grid.

I was under the impression that Stats Canada was involved but was later
assured by them that this was not the case.

The problem of lots of new mappers producing low quality work really
reared its head during the Nepal crisis.  I do mainly validation on HOT
projects in Africa and I ended up pulling in chunks of Africa and just
trying to clean up the map.  Currently I'm looking at one mapper who has
added more than a thousand ways with one tag I think it says
source=PGS.  Data quality is a major issue in OpenStreetMap.  Recently
someone gave up when looking for area=yes or buildings drawn in iD but
left untagged for the most part.  I think in Europe it was 100,000 or
more worldwide it was far higher and that's when the person looking at
it gave up.

There are many examples in Africa of groups of buildings being mapped as
one building and labelled building=house.  That's what we are trying to
avoid.  It is possible to correctly map a building in iD I've seen it
done but it takes time.  It is far easier to sort of roughly get it
right and roughly means not accurately.  I think the thing we need to
avoid is a feeling the mapper needs to get a tile done. That's when they
start to rush things.

Building validation?  I can think of no validator who enjoys having to
take two or three times longer to correct someones's work than it would
take them to map it in JOSM with the building_tool in the fir

Re: [Talk-ca] Mapping buildings in Canada by 2020

[Tim Elrick]

Hi John,

Thanks for your feedback and background information.

I think, we are on the same page. I am concerned with quality too, while
mapping should remain enjoyable.

We shied away from JOSM for newbies because it seemed more technical to
my groups members. I personally like JOSM better, and the building
plug-in is great. Maybe I manage to convince the group to use it next time.

I did not intend to call for experienced mappers to do all the
validation (I know it is tedious; however, correcting and esp. updating
makes OSM great and in some place much better than the official
sources). I think, that the group who initiated the mapping should
'clean up after themselves' (and I just wanted to affirm that we will do
that). I just wanted to express gratitude to mappers how do help out.

Once I am more into it, I am happy to help out validating other's work.

I did not mean to cheery pick when I quoted the validation website (I
very much appreciate the wiki page). I just wanted to make a point about
timing.

Regarding Canada, as a geographer I am fully aware of the fact Canada
having relatively less population, however, it has still almost half of
the population of Germany and the urban areas, which most of OSM mappers
are concerned with, might be relatively (to population) similar in size
(that's just a guess). I would have to run a query now to find out if
the relative number of active mappers is higher in one country than the
other, but that's not my point. The relative numbers do not matter, as
actual people do the mapping. And there, I hope we agree, the Canadian
OSM community could do with more active mappers.

Tim


Am 23.11.2017 um 07:54 schrieb john whelan:
The issue is the quality of the mapping, nothing else. I attended one of
these geoweek events and we used JOSM with the building_tool plugin. 
The mapping of buildings was accurate even though 75% of the mappers had
never used JOSM before.  There was no formal validation done but I
verified each mappers work as they did it.  I got the impression that
the mappers enjoyed the exercise and I think for me that was the most
important thing.  Mapping should be fun.

There was no mention of the work would be validated nor did we record
the mappers userids to ensure which mappers had mapped.  Other mappers
had marked tiles done on the grid.

I was under the impression that Stats Canada was involved but was later
assured by them that this was not the case.

The problem of lots of new mappers producing low quality work really
reared its head during the Nepal crisis.  I do mainly validation on HOT
projects in Africa and I ended up pulling in chunks of Africa and just
trying to clean up the map.  Currently I'm looking at one mapper who has
added more than a thousand ways with one tag I think it says
source=PGS.  Data quality is a major issue in OpenStreetMap.  Recently
someone gave up when looking for area=yes or buildings drawn in iD but
left untagged for the most part.  I think in Europe it was 100,000 or
more worldwide it was far higher and that's when the person looking at
it gave up.

There are many examples in Africa of groups of buildings being mapped as
one building and labelled building=house.  That's what we are trying to
avoid.  It is possible to correctly map a building in iD I've seen it
done but it takes time.  It is far easier to sort of roughly get it
right and roughly means not accurately.  I think the thing we need to
avoid is a feeling the mapper needs to get a tile done. That's when they
start to rush things.

Building validation?  I can think of no validator who enjoys having to
take two or three times longer to correct someones's work than it would
take them to map it in JOSM with the building_tool in the first place. 
I'm unable to even think of a case where a project has been validated
and the buildings corrected.  When I validate I'm trying to correct the
mapper's work and give them feedback so they will map more accurately in
future.  There is no point in doing this to someone who will map once. 
It's a waste of my time.

The wiki page you pointed to, I wrote much of it. the most important
part which you skipped is feedback from a user. 


  Why do we validate?

“OpenStreetMap is often the only source of maps, but the data quality is
very uneven.  I wish they’d put their more experienced mappers onto
validation.”  This is a quote from an individual who used OpenStreetMap
data (HOT) in the field.

Note the comment the data quality is very uneven and that's what we are
trying to address.  Your particular maperthon may have produced good
work, my lot certainly did but many mappers using the tag did not and
that is the issue.

By the way we do have fewer mappers per square kilometre than Germany
does and we have used CANVEC data to get a basic road network in.  In
Ottawa we've used Open Data to bring in the bus stops. The basic
Canadian map isn't bad but if we had as many mappers per square
kilometre as Germany does then no doubt

[Talk-ca] Mapping buildings in Canada by 2020

[Tim Elrick]

Hello all,

As you know Open Mapping Group McGill (OMG McGill) organized one of the
mapathons last week for the town of Williams Lake, BC. For the turnout
please turn to Julia's website published earlier today on the list.

As a mentor of the group I might be the 'director' of this event
according to the proposed policy by the OSMF board. In this role, I want
to assure you that we tried to do our best to teach new mappers how to
do their job properly, as Charles stated on this list yesterday. And
judging from a preliminary analysis of the data I conducted with the
overpass api, the participants did a pretty good job.

Of course, the data needs validation, which we will conduct in the next
couple of days. However, I do not see the rush proposed on this list
earlier. Ideally, validation would happen right after the mapping event
(as set out in this manual for HOT tasks [1]). In the real world, we all
have our jobs, families and other voluntary engagements, that sometimes
do not allow to act accordingly. I further think it is not even
necessary for tasks that are not related to immediate disaster response
or include ways tagged with a highway tag (in the later case it might
confuse navigation apps if not validated right away). In many cases,
validation, or better, correction of data entered by individual mappers
(not part of group events) was (and still is) done many days or even
months after the data was entered, depending on whether an experienced
mapper has an eye on a certain region or not. With regards to buildings
in areas where there existed no respective data before, I do not see any
need for rushing.

The important thing is that the organiser of a group event makes sure
that the data entered by participants of the event *is* validated to
ensure data quality. And we will. To this end, I appreciate that
long-term members already offered to help us there (thank you, Charles!).

I still consider mapathons a legitimate way to draw attention to OSM, to
advocate for open data, and to show the potential of OSM data and the
lack thereof in many parts of the world, including Canada. From the
experience of our first mapathon I got the impression that we instigated
a vast interest in open mapping (which, I think, is a valid goal on its
own right) and I expect quite a couple of returning participants to our
next events, in which we will train them further on the complexities to
produce good OSM data. By continuing, we might be able to motivate one
or two persons to turn into long-term mappers; this is, by the way,
totally in line with the long-tail phenomenon researchers found in all
crowd-sourcing projects.
All those reasons I mentionend, are, I think, worth it continuing doing
what we did. I would appreciate, if the attitude towards group mapping
events were less hostile on this list and on OSM as such (I am aware of
less fortunate attempts conducting group mapping events recently; but
try not blame them, but give them a hand to do it better next time - and
I know you did, but some of them apparently did not understand how
communication works in OSM). Try to give them the benefit of the doubt:
most mappers, even in group event, do this voluntarily and because they
want to enjoy extend this great geodatabase!

IMHO, OSM cannot do without those events, because we do not want to
leave the future of OSM only to businesses and their paid mappers (and
we have seen that in some countries, including Canada, there might not
be enough people who find their way to OSM without those events).

Tim


[1]
http://wiki.openstreetmap.org/wiki/OSM_Tasking_Manager/Validating_data#When_do_we_validate.3F


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

Re: [OSM-talk] Directed Editing Policy

[Tim Waters]

I've a couple of examples, and a couple of questions which might aid the
discussion.

I recently did some work which would label me as both a directee and a
director. For each changeset I added a custom changeset tag which I thought
was the sensible thing to do. It was also helpful for me to be able to
track the work I did, amongst my other edits at that time. I'm assuming
that this bundle of changesets could be searched for an clustered, and that
I wouldn't need to create another changeset tag for a similar tranche of
work in the future. At the time I did actually briefly consider writing a
wiki page about the work, but thought that too onerous (it was a short
project) and against the spirit of OSM (the world should be free to edit
the free map). I thought I shouldn't have to document all my actions to
contribute. If the policy was adopted, I'd have to go along with it. I
would feel less of an equal, or more under scrutiny if I did.

Some time last year I ran a mapping workshop where participants were
mapping a specific type of feature, using custom presets using established
tags. The use of the presets helped ensure that the tags were consistent.
We didn't really use any specific changeset comments or any new tags, but
when Field Papers was used, I believe this was recorded. The custom editor
was able to add changeset tags too. Again the tools help record the custom
sources involved. Before I ran the workshop, although it was free, public
and publicised, and although the project itself was documented on the wiki
and elsewhere, I did not feel any need to document the actual directed
mapping.

These are just my two experiences, the policy as a whole reads well and I
understand that there is an issue which needs addressing, I hope our
discussions can bring some nuance and improve matters.

Now - the questions:
When I was reading the draft policy, I imagined the state of the Wiki.
Would it be polluted full of stale pages of small directed mapping projects
after a few years?
As the suggestion is that a timeframe is added to the page - is this easily
machine readable and parseable within the Wiki software?
Would it be easy to just see currently active projects, or just see those
projects which were upcoming?


Regards,

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

[Talk-ca] Planning mapathon @ McGill in OSM Geo Week

[Tim Elrick, Dr.]

Hello OSMappers,

I am Tim Elrick, heading the Geographic Information Centre at McGill. I am 
involved with organizing a mapathon at McGill in Montreal in OSM Geo Week in 
November. I am reaching out to you to find local experienced mappers to support 
us in the mapathon (I followed the discussion on talk-ca in the last couple of 
weeks).

It would be great if someone could get me in touch with local OSMappers? (My 
idea was to go to the next OSM event in Montreal; however, unfortunately, it 
seems too close to OSM Geo Week, to start the contacts only then.)

Beside the mapathon, McGill students who worked as volunteers at the last HOT 
summit are currently setting up a mapping group (OMG McGill, Open Mapping Group 
McGill). They slowly want to build up OSMapping expertise to work on HOT tasks, 
Building Canada 2020 tasks as well as adding to OSM in Montreal. The group 
would appreciate to have a contact to established OSMappers here as well.

Thanks a lot!

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

Re: [Talk-br] [OHM] Possibility to build a new Historic Project to OSM

[Tim Waters]

Hi Rodrigo,

Speaking of OpenHistoricalMap I think historic events bound to
geography would be welcome. The Historic Event proposal was for the
different but of course bigger OSM project.The example given in the
wiki page was historic battlefields which would be suitable.

I think there could be discussion about notability. For example, if a
city records and notifies that an event occured in a place (e.g. Blue
Plaques) then we can say it's notable for sure. At any rate the event
should be able to be verified by another mapper.

I don't think that more general events such as "crimes in 1930s" would
be appropriate in OHM however - at one geographical level this is
statistical information, and one that might be better linked to the
historic geographic area. At individual level it may not be notable -
but a prominent assasination might be.

So I think OHM could fit some of your needs. Getting the historic
geodata and basemap in could be more of a challenge!

regards,

Tim

On 6 August 2017 at 16:58, Rodrigo Mariano <rodmarian...@gmail.com> wrote:
> To whom it may concern,
>
>
>
> My name is Rodrigo and I am doing a Master's degree in Applied Computing at
> the brazilian National Institute for Space Research (INPE).
>
> I am part of the Pauliceia's project that aims to develop a computational
> platform to manipulate historical data in a collaborative way, focusing on
> the city of São Paulo. For more information:
> https://wiki.dpi.inpe.br/pauliceia/doku.php
>
> In our context, historical data may be objects (e.g. building or monument)
> or historical events (e.g. crimes in 1930).
>
> I would like to know: is there a possibility the Pauliceia's project have
> integration with a Historic Project? Like Open Historical Map (OHM) [1]?
>
> I know that OHM is just to historical objects and the Historic Event [2] was
> rejected. Even so, is there a chance to build it? To save the information in
> OSM?
>
> The Pauliceia's project is in a initial fase, so there is not a lot of
> things to show to all you.
>
> I created a wiki page do the Pauliceia's project in OSM wiki [2], however
> the detailed is in the original wiki of INPE yet [4] and I am reading the
> Import/Guidelines [5].
>
> I would like to want to talk, with all you, before to start to develop the
> database, to know the opinion of the community.
>
>
>
> Thank you in advance.
>
>
> [1] http://wiki.openstreetmap.org/wiki/Open_Historical_Map
>
> [2] http://wiki.openstreetmap.org/wiki/Proposed_features/historic_event
>
> [3] https://wiki.openstreetmap.org/wiki/Pauliceia2.0
>
> [4] https://wiki.dpi.inpe.br/pauliceia/doku.php
>
> [5] http://wiki.openstreetmap.org/wiki/Import/Guidelines
>
>
> PS: I sent this email with my official email, however I forgot that I am in
> the lists with this email.
>
>
> Regards,
>
>
> --
>
> Rodrigo M. Mariano
>
> ___
> Historic mailing list
> histo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/historic
>

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

Re: [OSM-talk] OSM Stats site kickstarter

[Tim Waters]

At time of writing this email, the Kickstarter project has reached its
goal with $1,085 and 18 hours left. This would mean in this case that
the Universe cares about this project, but wouldn't in my mind
indicate that this would mean that volunteers would magically appear
to work on it!

Regards,

Tim

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

[OSM-talk] The New Cloud Atlas - Mapping Physical Infrastructure of the Internet with OSM

[Tim Waters]

Hi folks,

with Ben Dalton, I'm happy to properly launch The New Cloud Atlas
project at http://newcloudatlas.org

I've written a blog post to explain it in more detail:
https://thinkwhere.wordpress.com/2016/08/17/the-new-cloud-atlas-mapping-the-physical-infrastructure-of-the-internet/

It's a project to collect and make a map to better understand what
"The Internet" means, physically and geographically. The site has a
tweaked iD editor with custom telecoms presets, it creates a couple of
map tilesets showing these features from OSM, with clickable features
on the map.

We encourage you to map your local data centres, street cabinets,
telephone exchanges, telephone poles, manhole covers and more!

Telecoms features in OSM are not consistently mapped with regards to
each other which could provide an opportunity for some consolidation
or making new taxonomies. I've created WikiProject Telecoms to help
with this tagging discussion:
https://wiki.openstreetmap.org/wiki/WikiProject_Telecoms

Cheers and I look forward to your comments!

Tim

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

Re: [OSM-talk] Uber most likely using OSM data

[Tim Waters]

Hello,

given they may well have a very large body of GPS traces, they may be
using these to route along.

The way to check if they are using OSM is if the OSM map has
intentional errors - a kink in the road where there is none on aerial
imagery or on our GPS traces, for example.  Some of my early edits
were done just by phone and a bluetooth GPS mouse - in the days before
aerial imagery, and some of the roads had a few bends which were not
there in reality, and this assisted me in identifying some of the
previous users of our database.

Another way is perhaps by comparing the resolution of the data, a bit
like in the examples, showing where the bends meet up - comparing a
road with lots of bends, nodes in a short distance. Seeing if the
vertices match up.

Cheers,

Tim.

On 27 July 2016 at 11:06, Mishari Muqbil <mish...@mishari.net> wrote:
> Hi,
>
> I checked the about page. There's licensing information for a bunch of
> software and Google maps but nothing for OSM.
>
>
> On Jul 27, 2016 5:02 PM, "Christoph Hormann" <chris_horm...@gmx.de> wrote:
>
> On Wednesday 27 July 2016, Mishari Muqbil wrote:
>> Hi,
>>
>> I wrote a blog post
>> <https://www.mishari.net/2016/07/uber-using-osm-data/> comparing
>> Uber's rendering of a sample route displayed in it's app with Google
>> Maps and OSM Mapnik, it seems Uber is using OSM data for this
>> function without any visible attribution to OSM.
>
> Looks like it.
>
> The area shown by the way is here:
>
> http://mc.bbbike.org/mc/?lon=100.565099=13.736474=17=3=nokia-map=mapnik=google-map
>
> Is there any mentioning of OSM in the app?  Like hidden on some 'about
> page' or similar?
>
> --
> Christoph Hormann
> http://www.imagico.de/
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>

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

Re: [OSM-talk] What pointing device you use for mapping?

[Tim Waters]

I use a trusty Microsoft Intellimouse (although I do not customise the
buttons), but I'm really replying to an observation about a helpful
tip for mapping parties and workshops.

When putting on a mapping party / workshop where people bring their
own laptops, bring a bag of mice for participants to use! The Missing
Maps  / OSM London do this and it seems as if all of them get used.

(I also find it funny, how, several years ago at mapping parties we
used to pass around a bag of GPS units to map, now it's a bag of
mice!)

Back on topic, I'd be curious to hear if the assorted map teams in
companies like Mapbox etc use any specific hardware to point and map
and increase productivity...

Cheers,

Tim

On 13 July 2016 at 07:34, Oleksiy Muzalyev <oleksiy.muzal...@bluewin.ch> wrote:
> I also noticed that often moderately priced items are more reliable than
> high-end expensive ones. Probably because they are more widespread, and
> consequently deficiencies in design are noticed, reported, and corrected
> faster. The Nexus Silent Mouse costs about 20 USD. I got so accustomed to a
> soundless mouse that I cannot use normal mice anymore, and not only for
> mapping, each click sounds to me as a gunshot. That is why I keep a spare
> one ready. But I work sometimes in a library where it is very quiet.
>
> I also received an e-mail where it is written that a graphics tablet is
> being used for mapping by a correspondent's acquaintance; that a graphics
> tablet is really precise, helps to map quicker, and that it is so convenient
> that it is impossible to map without it. And that a graphics tablet must be
> with a zoom control.
>
> If such a graphics tablet increases productivity by say twenty or even ten
> percent, then it makes sense to invest in it. Because our working time costs
> much more in the long run. It would be interesting to hear from someone who
> has got firsthand experience of using a specific model of a graphics tablet
> for mapping.
>
> Best regards,
> Oleksiy
>
>
> On 12/07/16 22:10, Andreas Vilén wrote:
>>
>> Nothing fancy. Heavy osming has a tendency to break mice so I only use
>> cheap stuff.
>>
>> Once I bought a fancy one but the precision was so bad I had to change
>> back to the standard Ms mouse...
>>
>> /Andreas
>>
>> Skickat från min iPhone
>>
>>> 12 juli 2016 kl. 10:18 skrev Oleksiy Muzalyev
>>> <oleksiy.muzal...@bluewin.ch>:
>>>
>>> I use Nexus Silent Mouse SM-8500B [1]. This mouse does not produce a
>>> "click" sound, though there is a tactile click. This type of soundless mouse
>>> makes a difference while working in an OSM editor. I like SM-8500B. I own
>>> three of them, including a spare one. It works fine on Mac and W10.
>>>
>>> There are numerous innovative pointing devices available nowadays, -
>>> graphics tablets, vertical mice, pencil mouse, etc. If you have a positive
>>> experience employing an innovative pointing device design for mapping,
>>> please, let me know.
>>>
>>> [1] https://nexustek.us/mice/sm-8500
>>>
>>> Best regards,
>>>
>>> Oleksiy
>>>
>>>
>>> ___
>>> talk mailing list
>>> talk@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [OSM-talk] What3words

[Tim Waters]

Heather and folks who are often perplexed,

are you actually perplexed or do you understand but disagree? I ask
because I have heard some mappers say the opposite: "I don't
understand why people would choose w3w!!11". Is it a turn of phrase?
Or a genuine plea for illumination? I often disagree with blind
vitriol, but I try to understand why it exists. The words we say often
give different responses. For example in the UK many people said "I
don't understand why people voted for Brexit" and some of them
genuinely did not know of any reasons why people voted that way
(filter bubble doesnt help), whilst others said that phrase, but could
understand why others voted that way but simply disagreed with the
reasons. Some people simply could not put themselves in the
oppositions shoes. The cognitive dissonance hurts too much.  I
therefore think its not just a turn of phrase for all. So here's a
response which I hope covers both angles:

In this example of w3w should the OSM community or the OSM Foundation
provide reasons why people disagree to help those who do not
understand community responses to product, or, should the OSM
Community or the OSM Foundation communicate better so that differences
of opinion are valued and can coexist with each other? Should reasons
on both sides be listed, or should we work so that blind vitriol and
anti vitriol statements be lowered? Is the problem the thing, or is it
that the thing cannot be easily understood?

Personally, I like w3w, I don't think the promise to release the code
if it goes belly up means anything. Contracts and terms of conditions
can be changed whenever, and it looks like they are aiming to be
acquired. Also, if they are successful it would never be released, so
why should we wait for it? They are VC funded, after all so they want
to grow and get a profit. I disagree mostly with the proprietary 3rd
party access. It's not open and not the OSM way. Its a proprietary
gatekeeper of information, something diametrically opposed to our
little mapping project. Would someone say the proceeding few sentences
was vitriolic? I don't think so. Critical yes. Was it offensive? Maybe
their investors don't like it, but I think it should be allowed to be
said, right?

However, I also disagree with criticism from mappers directed at
Mongolia which is patronising at best. To go with w3w is similar to
any proprietary software contract, which big businesses and big
countries do every day. It's not something I would promote generally,
it's not an open way forward is it? However it gives people jobs, and
its the money making capitalist world we live in. I believe w3w whilst
being a poor choice is a workable choice. And it may be a great choice
for the country if it works for them. If the country asked me, I would
not have recommended w3w, but dont hold it against them! Just like
using closed data, or proprietary software is a poor choice, it does
actually work. Microsoft or Esri products actually work pretty well!
(and so do their better FOSS alternatives of course). I do reserve my
vitriol to protect open data and open source, as this protects this
OSM community and foundation and what I think we stand for. Mongolia,
I believe made a good choice in their eyes for their country.

I hope this helps the perplexity, if there is genuine perplexity. Many
people do not understand the issues, and that's okay, and I want to
help people understand things if they are open to learn. And i hope
this helps understand some of the issues why people disagree with the
project if there is a genuine need to learn about some of these. I
want to help people empathise with others, to put themselves in their
opponents shoes and see that they are not actually opponents after
all!. I suspect the reality in many people's cases with controversial
subjects it is a mixture :)

best regards,

Tim

On 12 July 2016 at 12:12, Heather Leson <heatherle...@gmail.com> wrote:
> Well, slightly off-topic but I am often perplexed by the vitriol in OSM. I
> even shudder to post this statement because the environment has shown itself
> to be hard.
>
> Maybe we can have conversations at SOTM about how to turn this tide in a
> collaborative way.
>
>
> Heather
>
> Heather Leson
> heatherle...@gmail.com
> Twitter/skype: HeatherLeson
> Blog: textontechs.com
>
> On Tue, Jul 12, 2016 at 2:04 PM, Jóhannes Birgir Jensson <j...@betra.is>
> wrote:
>>
>> I don't know if they are using the English version in Mongolia but I doubt
>> it. You can already swap to 8 other languages on their website (top right
>> option).
>>
>> I did discuss Icelandic with Mapillary and they looked into available word
>> sets and concluded that it was more than sufficient to make Iceland itself
>> work in an Icelandic w3w implementation.
>>
>> The circle-jerk is strong here about w3w, they have a human readable
>>

Re: [Talk-GB] Night Time Aerial Imagery?!?

[Tim Waters]

This is great! Thanks for putting these online.

I've been trying to find the source on the EA website - as I was
wondering whether they were also recording other bands (infra red etc)
which could, I imagine, be used to map vegetation.

Also, I was curious to find out why they chose these specific towns
and cities, and not others - or in other words, why they captured
these images in the first place.

Tim

On 10 July 2016 at 22:45, Grant Slater <openstreet...@firefishy.com> wrote:
> Hi OSM-GB,
>
> The Environment Agency recently release a massive trove of Open Data,
> which I am slowly started to process.
>
> One of the smaller and quicker to process datasets is the Night Time
> aerial imagery which I've now tiled and put online here:
> http://ea.openstreetmap.org.uk/
>
> Birmingham: http://ea.openstreetmap.org.uk/#zoom=12=52.4831=-1.8772
> Peterborough: http://ea.openstreetmap.org.uk/#zoom=13=52.5743=-0.2588
> Northhampton: http://ea.openstreetmap.org.uk/#zoom=13=52.2458=-0.8871
> Swindon: http://ea.openstreetmap.org.uk/#zoom=13=51.5793=-1.7931
> London (Mostly South):
> http://ea.openstreetmap.org.uk/#zoom=11=51.5266=-0.0636
>
> Unsure how useful the Night Time aerial imagery is for OpenStreetMap
> proposes, but it sure does look good ;-)
>
> Kind regards,
>
> Grant
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] UK OSM final articles of association

[Tim Waters]

Hi Rob,

Great news, it's good to see that things are becoming more and more concrete!

May I ask, does the red text in the document indicate simply that they
were the last changes made?

Also - for initial directors, to remind folks, these are just in name
only for a little while before the elections when they all resign and
new ones are elected?

Regards,

Tim

On 7 June 2016 at 22:42, Rob Nickerson <rob.j.nicker...@gmail.com> wrote:
> Hi all,
>
> As noted by Brian, please find the proposed Articles of Association for the
> UK OSM company:
>
> https://drive.google.com/file/d/0B6J5ZA1hu93bSUFIdERMNHZhM1U/view?usp=sharing
>
> If you want to be a founding member then there is an email address
> (hopefully Gregory will share this as I can't remember it at the moment).
>
> We are also looking for initial Directors. Much of the boring work is now
> over (the articles) so now looking forward to getting this going :-)
>
> Rob
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-GB] Quarterly Project (Health): Pharmacies and Defibrillators

[Tim Waters]

Are the some hospitals that do not have pharmacies?  Would these be
the smaller clinics, or would they be tagged differently anyhow?

Tim

On 15 May 2016 at 21:51, Andrew Black <andrewdbl...@googlemail.com> wrote:
> I notice the list of registered pharmacies includes hospital pharmacies.
> Not sure these are worth adding as the area should already be marked as a
> hospital. And i don't believe the process GP prescriptions.
>
> On 9 May 2016 7:36 p.m., "Rob Nickerson" <rob.j.nicker...@gmail.com> wrote:
>>
>> Nice work Robert.
>>
>> Out of interest how does that data compare to the healthcare data is all
>> available at:
>>
>> http://systems.hscic.gov.uk/data/ods/datadownloads
>>
>> For example, do the reference numbers match?
>>
>> Rob
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [OSM-talk] Upload slowness - what's going on?

[Tim Waters]

I believe the Dev mailing list may have some of your technical answers
https://lists.openstreetmap.org/pipermail/dev/2016-May/thread.html

It appears from that list that the database servers are now a few
hundreds of miles from where the web servers are, causing the increase
in latency. I do not know if this is a permanent change, the thread on
osm-dev does seem to indicate that things are still in flux.

Tim



On 13 May 2016 at 06:02, Ben Discoe <bdis...@gmail.com> wrote:
> Several of us have noticed radically slowly upload speed for
> changesets, roughly since the server move on May 9.  Like, as
> painfully slow as it used to be, it's now several times slower.
>
> It's been discussed with @OSM_Tech on twitter, in this thread:
> https://twitter.com/OSM_Tech/status/730857486618664960
>
> Before I get too hysterical, can somebody tell me what happened, and
> can it be fixed?
>
> OSM_Tech's mysterious message:
>   "Large uploads will take around 3 times longer. Small uploads extra
> delay should be minimal."
>
> Does this mean that something did change?  It is database writes that
> are taking so much longer?  Changesets with as few as 400 object are
> taking several times longer, what constitutes "large" vs. "small"?
> Can it be fixed?  Can I donate large sums of money somewhere to help
> it get fixed?
>
> Thanks,
> Ben
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk

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

Re: [Talk-de] Auftrag für Foto-Tapete

[Tim Kober [Kober-Kümmerly+Frey]]

Hallo Markus,

das lässt sich machen und wir können auch fertig bedruckte Tapete liefern.

Wie Harald schon richtig sagte, wären allerdings einige Details hilfreich, 
damit die Karte dann tatsächlich Euren Vorstellungen entspricht. Reicht ein 
"Standarddesign" oder braucht ihr eine individuelle Optik und angepasste 
Inhalte?

Mit vielen Grüßen,

Tim Kober


> Am 26.04.2016 um 15:41 schrieb Markus <liste12a4...@gmx.de>:
> 
> Liebe OSMer,
> 
> Wer kann sowas? zu welchem Preis?
> 
> - - - -
> Für ein Innenarchitektur Projekt möchten wir gerne eine Seekarte der
> Kieler Förde als Tapete für eine große Wand, Länge 10 m x Höhe 3 m
> verwenden. Könnten Sie uns mit eine entsprechenden Datei (hochauflösend
> zum Druck) zur Verfügung stellen und wenn ja, was würde das kosten?
> - - - -
> 
> Mit herzlichem Gruss,
> Markus
> 
> ___
> Talk-de mailing list
> Talk-de@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-de



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Talk-de mailing list
Talk-de@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-de

Re: [Talk-GB] OSGR & OSM

[Tim Waters]

There are a few tools out there which may do the job, I seem to recall
a few. http://nearby.org.uk/ might have it.

The search keywords which might help is "os national grid spherical
mercator". Do remember that a tile is not the same square as an os
grid square, but you should be possible to click on a point and get
that point in whatever coordinate system you need.

Cheers,

Tim

On 5 April 2016 at 14:59, Stuart Reynolds
<stu...@travelinesoutheast.org.uk> wrote:
> Is there a site or tool somewhere where I can click on a point on an OSM
> tile and get back the OSGR? I want the quality of OSM, but need OSGR
> unfortunately.
>
> Thanks
> Stuart
>
>
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>

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

Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland

[Tim Teulings]

Hallo Uwe,


du scheinst ja ein richtiger Spätaufsteher zu sein.
In der Zeit vom 10. - 16.03.2016 haben hier einige in der Liste an  
der Diskussion teilgenommen.


Richtig. Habe ich auch gelesen. Allerdings hatte mir mein Mailclient  
vorgegaukelt, dass die referenzierte Nachricht neu wäre :-/ War nicht  
so, mein Fehler...ich jetzt aber auch nicht sooo lange her.


Die Seite http://www.mobil-im-rheinland.de/lkw-navigation/index.html  
hast du wohl auch noch nicht gelesen, sonst hättest du dir einiges  
an Text ersparen können.


Nein habe ich nicht. Beantwortet aber jetzt auch nicht gerade  
detailliert meine Fragen, oder?


Für ein LKW-Routing ist erst einmal nötig dass die Daten dafür  
bereitgestellt werden, das fängt bei Tonnagebegrenzungen an und hört  
bei Gefahrgutrouten auf.


Na ja, mann kann auch vorher LKW-Routing machen, aber mit mehr  
Informationen wird es besser, da bin ich vollkommen bei dir :-) ich  
sehe da aber auch keinerlei Widerspruch zu meinem Kommentar? Außerdem  
hatte ich nicht den Eindruck, als wenn es nur um das Mappen von  
zusätzlichen Daten in OSM geht, ich hatte das Gefühl, dass der Plan  
des Autor ein anderer - vielleicht weniger sinnvoller - gewesen wäre.


Wie oft hast du denn schon ein priority_road=designated oder  
hazmat=designated  gemappt ?


Noch nie. Muss ich das? Wie viele Router hast du schon geschrieben  
oder LKWs gefahren ;-)?

--
Gruß...
   Tim


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

Re: [Talk-de] Datenerfassung für stadtverträgliches LKW-Routing im Rheinland

[Tim Teulings]

Hallo,


Hallo zusammen,

es ist echt toll, dass so Viele sich an der Diskussion beteiligen.


Ist das ironisch gemeint, in der Mailingliste habe ich schon länger  
nichts mehr darüber gelesen?



Vielleicht nochmal zu den Zielen des Projekts. Der Leidensdruck in

[...]

Das Problem habe ich verstanden. LKWs fahren teilweise nicht daher, wo  
sie sollen. Fahrer sind nichts ortskundig und nutzen vielleicht ein  
Navi, was ggf. denkt, es handelt sich um einen normalen PKW. Das führt  
dazu, dass LKWs gehäuft die gleiche und für LKWs schlecht geeigneten  
Strecken nehmen. Worst case ist dann ein LKW ist einer (für LKWs)  
Sackgasse, aus die er nicht mehr rauskommt ;-)


Die Vorrangrouten werden vom jeweiligen  
Straßenverkehrsamt/Ordnungsamt vorgeschlagen und politisch  
abgesegnet. Es malt also nicht einfach irgendjemand in den Kommunen  
irgendwelche Vorrangrouten auf, die dann gelten sollen. Die  
Zuständigkeiten sind nicht in allen Kommunen gleich geregelt, da es  
in vielen kleineren Kommunen kein eigenes Straßenverkehrsamt gibt.  
Vorrangrouten müssen sich natürlich immer an die vorhandenen  
Schilder/Restriktionen halten, da Diese natürlich nicht gegen die  
StVO verstoßen dürfen.


OK, aber was ist definiert eine Vorrangroute? Ist das einfach eine  
vorgegebene Abfolge von zu fahrenden Straßen? So etwas wie eine  
Bus-Route?


Der Vorteil ist, dass im Routing im nachgeordneten Straßennetz  
(Autobahnen und Bundesstraßen sind eh Vorrangrouten) so erst einmal  
auf Vorrangrouten geroutet wird, bis deren Ende erreicht ist und  
dann die Restriktionen greifen. Wenn es zwei Strecken gibt, die  
theoretisch in Frage kommen, kann somit die verträglichere der  
Beiden als Vorrangroute definiert werden und so verhindert werden,  
dass LKW-Verkehre beispielsweise durch Wohngebiete geleitet werden.


Wieso? So ein Routing-Algorithmus macht eine  
Kosten-Analyse/Optimierung. Will ich die schnellste Route, betrachte  
ich z.B. Geschwindigkeitsbegrenzungen, Ampeln (also alles was  
verhindert, dass ich Höchstgeschwindigkeit fahren kann) als  
zusätzliche Kosten. Der Algorithmus sucht dann die billigste Strecke.  
Ich kann auch verbieten, bestimmte Straßen zu fahren (sehr große  
Kosten). Will ich die kürzeste (nicht schnellste) Strecke, sind die  
optimalen Kosten ("weniger geht nicht) die Km Luftlinie und für alle  
Straßen sind Kosten=Strecke in Kilometer. (Für A* ist es wichtig, dass  
ich die minimalen Kosten vorab festlegen kann, was auch noch  
Einschränkungen bzgl. der Kosten ergibt).


Was für mich unklar ist: Wie sollen nun Vorrangrouten dem Router und  
dem Nutzer des Navis helfen? Mann will ja sicherlich nicht, dass der  
Router die Vorrangroute nur noch sklavisch abfährt, oder? Das kann man  
einfacher haben ;-) Tue ich bei der schnellsten Route einfach so, als  
wenn ich 10Km/h schneller fahren kann als tatsächlich erlaubt (die  
Kostenfunktion kann ja komplexer sein sein, als nur die fahrbare  
Geschwindigkeit abzubilden)? Was ist aber, wenn ich wo anders eben  
mehr als 10km/h schneller fahren, als auf der eigentlichen  
"Vorrangroute"? Oder die Vorrangroute so ein großer Umweg ist, dass  
ein algorithmischer "Bonus" eben aufgezehrt wird? Die Vorrangroute  
wird ja sicherlich nicht von Natur aus für LKWs optimal sein, oder?  
Sonst hätten wir bei (schlauen) Navis ja gar kein Problem :-) D.h.  
selbst eine Berücksichtigung von Vorrangrouten im Algorithmus wird  
nicht zwingend dazu führen, dass das Navi diese auch tatsächlich  
ausspuckt. Und wenn der LKW Fahrer schnackelt, dass die LKW Route weit  
ab von aus seiner Sicht optimal ist, wird er das entsprechende Routing  
auch gar nicht nutzen (scheiß Navi) ;-)


Ergo: Es wäre schlauer durch verkehrstechnische Maßnahmen dafür zu  
sorgen (Beschilderung, Verbote), dass die Vorrangsroute sich als  
"natürliche" optimale Route ergibt, sonst werden (OpenSource) Router  
und OSM das Problem nicht grundsätzlich lösen - es sei denn, man  
erzwingt die Nutzung.


Es würde sicherlich auch erheblich weniger Diskussion geben,  
entsprechende Beschilderung in OSM einzubringen. Den "on the ground"  
ist ja nicht das Problem (im Gegensatz zu virtuellen Routen deren  
praktischer Nutzen unklar ist) und der allgemeine Nutzen ist dann  
offensichtlich.


Der Vorschlag, dass wir oder die Kommunen die Vorrangrouten in OSM  
beobachten und auf Änderungen reagieren wäre auch denkbar. Kann man  
sich die Änderungen an bestimmten Attributen/Objekten herausfiltern  
lassen, so dass man sich den händischen Abgleich spart?


Man sicherlich filtern. Aber ein händische Prüfung des Deltas wird  
sich nicht umgehen lassen, sonst wäre man bei einer automatischen  
(Rück-)Korrektur (eine Variante des Imports) - die die OSM Community  
nach meinem Verständnis nicht will.

--
Gruß...
   Tim


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

Re: [Talk-GB] [UK Chapter] Definition of OSM.

[Tim Waters]

Frederik is correct in saying that OpenStreetMap Project does not
appear in the OSMF Articles of Association.

However, on the OSMF website, the following words are used: "The
Foundation supports the OpenStreetMap Project."

So the wider OSM "thing" is the OpenStreetMap Project rather than the
OpenStreetMap Community. I quite like that differentiation, even
though I cannot find the definition of what the project is!

"supports" is also a quite different meaning than "managed by"

If we wanted to have a definition that includes the OSMF: "The
OpenStreetMap Project as currently supported by the OpenStreetMap
Foundation Ltd" perhaps?

Tim

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

Re: [Talk-GB] UK Chapter: Who will be the "we"?

[Tim Waters]

Hi Dave,

I think that the "we" would be the members of the organization.

Tim

On 21 March 2016 at 00:40, Dave F <davefoxfa...@btinternet.com> wrote:
> Hi all
>
> OK, this a genuine, non rhetorical, non cynical question.
>
> I've loosely been following the discussions of setting up a UK:chapter of
> OSM.
>
> After you've decided upon the process you all want to take & when you've
> started writing documents & sending emails out to the wider world, who will
> be the "we", as in "we feel OSM is doing this incorrectly/correctly?
>
> Who are the OSM contributors you believe you will represent?
>
> Thanks
> Dave F.
>
>
>
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] UK war office maps of Africa digitised

[Tim Waters]

Hi Richard,

Are you still having issues? That map appears to be okay now, last
rectified 3 days ago and was able to rectify it just now. I've a
screenshot here:
http://imgur.com/bOjMnWq  http://warper.wmflabs.org/maps/261#Preview_tab

Find me on IRC as chippy sometime if you are still encountering problems.

regards,

Tim

On 9 February 2016 at 18:44, Richard Symonds
<richard.symo...@wikimedia.org.uk> wrote:
> Tim,
>
> A lot of these maps won't rectify, even though I've completed all the
> control points. The one I've just come up with is
> http://warper.wmflabs.org/maps/261 - can someone try and preview it, or tell
> me what I'm doing wrong?
>
> Richard Symonds
> Wikimedia UK
> 0207 065 0992
>
> Wikimedia UK is a Company Limited by Guarantee registered in England and
> Wales, Registered No. 6741827. Registered Charity No.1144513. Registered
> Office 4th Floor, Development House, 56-64 Leonard Street, London EC2A 4LT.
> United Kingdom. Wikimedia UK is the UK chapter of a global Wikimedia
> movement. The Wikimedia projects are run by the Wikimedia Foundation (who
> operate Wikipedia, amongst other projects).
>
> Wikimedia UK is an independent non-profit charity with no legal control over
> Wikipedia nor responsibility for its contents.
>
>
> On 9 February 2016 at 17:30, Jez Nicholson <jez.nichol...@gmail.com> wrote:
>>
>> I tinkered with the "Kilimanjaro to Tsavo Stn. U.R.. WOOS-8-3-1" map a
>> fair bit. Started by using recognisable locations (features on lakes, etc.)
>> but eventually settled on tagging the grid lines and using online conversion
>> tools to give me the WGS-84. The ones with hills in look great in Google
>> Earth, e.g. http://warper.wmflabs.org/maps/629.kml Difficult to get the map
>> spot on.
>>
>> On Tue, 9 Feb 2016 at 16:28 Tim Waters <chippy2...@gmail.com> wrote:
>>>
>>> Hi folks,
>>>
>>> so after a fix was applied to the Wikimaps Warper the collection of
>>> 581 maps from Wikimedia Commons was re-imported and added to a mosaic
>>> (layer)
>>>
>>>
>>> https://commons.wikimedia.org/wiki/Category:War%20Office%20Archive%20%E2%80%93%20British%20East%20Africa
>>>
>>> The mosaic:
>>> http://warper.wmflabs.org/layers/4
>>>
>>> The Tiles link is http://warper.wmflabs.org/layers/tile/4/{z}/{x}/{y}.png
>>> and the WMS details can be found at
>>> http://warper.wmflabs.org/layers/4#Export_tab
>>>
>>> and of course individual maps have their own WMS and Tiles endpoints too
>>>
>>> Cheers,
>>>
>>> Tim
>>>
>>> p.s. Note that loading up a map for the first might take a once only
>>> period of a couple of minutes as the map gets requested from commons
>>> and is loaded up in the warper ... you should see a progress bar in
>>> that case!
>>>
>>> p.p.s. There's an issue with the warper not getting the correct
>>> thumbnail for some of the maps, but it shouldn't affect how it works
>>> in the warper.
>>>
>>> On 2 February 2016 at 13:58, Jez Nicholson <jez.nichol...@gmail.com>
>>> wrote:
>>> > The export tab http://warper.wmflabs.org/maps/629#Export_tab includes a
>>> > WMS
>>> > link "for JOSM OpenStreetMap Editor"
>>> >
>>> > I haven't tried it yet as my company have firewalled the office with an
>>> > https whitelist.
>>> >
>>> > On Mon, 1 Feb 2016 at 17:34 Andy Mabbett <a...@pigsonthewing.org.uk>
>>> > wrote:
>>> >>
>>> >> On 1 February 2016 at 13:02, Tim Waters <chippy2...@gmail.com> wrote:
>>> >>
>>> >> > Great stuff. I think a few hundred maps (if not all) from this
>>> >> > collection
>>> >> > are already in the wikimaps warper.
>>> >> > However there was an issue with making a mosaic (stitched layer) for
>>> >> > the
>>> >> > category, so this will be fixed soon.
>>> >>
>>> >> Once that's done, how can people see the layer in JOSM?
>>> >>
>>> >> > I think the British Library also has control points for the maps
>>> >> > which
>>> >> > could
>>> >> > be added to the warper when ready (I'd have to double check on this
>>> >> > point
>>> >> > though).
>>> >>
>>> >> My contact tells me they (BL & Indigo Trust) want to see the maps
>>> >> reused; if there's a speciific request, I can forward it to them.
>>> >>
>>> >> --
>>> >> Andy Mabbett
>>> >> @pigsonthewing
>>> >> http://pigsonthewing.org.uk
>>
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>

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

Re: [Talk-GB] UK war office maps of Africa digitised

[Tim Waters]

Hi folks,

so after a fix was applied to the Wikimaps Warper the collection of
581 maps from Wikimedia Commons was re-imported and added to a mosaic
(layer)

https://commons.wikimedia.org/wiki/Category:War%20Office%20Archive%20%E2%80%93%20British%20East%20Africa

The mosaic:
http://warper.wmflabs.org/layers/4

The Tiles link is http://warper.wmflabs.org/layers/tile/4/{z}/{x}/{y}.png
and the WMS details can be found at
http://warper.wmflabs.org/layers/4#Export_tab

and of course individual maps have their own WMS and Tiles endpoints too

Cheers,

Tim

p.s. Note that loading up a map for the first might take a once only
period of a couple of minutes as the map gets requested from commons
and is loaded up in the warper ... you should see a progress bar in
that case!

p.p.s. There's an issue with the warper not getting the correct
thumbnail for some of the maps, but it shouldn't affect how it works
in the warper.

On 2 February 2016 at 13:58, Jez Nicholson <jez.nichol...@gmail.com> wrote:
> The export tab http://warper.wmflabs.org/maps/629#Export_tab includes a WMS
> link "for JOSM OpenStreetMap Editor"
>
> I haven't tried it yet as my company have firewalled the office with an
> https whitelist.
>
> On Mon, 1 Feb 2016 at 17:34 Andy Mabbett <a...@pigsonthewing.org.uk> wrote:
>>
>> On 1 February 2016 at 13:02, Tim Waters <chippy2...@gmail.com> wrote:
>>
>> > Great stuff. I think a few hundred maps (if not all) from this
>> > collection
>> > are already in the wikimaps warper.
>> > However there was an issue with making a mosaic (stitched layer) for the
>> > category, so this will be fixed soon.
>>
>> Once that's done, how can people see the layer in JOSM?
>>
>> > I think the British Library also has control points for the maps which
>> > could
>> > be added to the warper when ready (I'd have to double check on this
>> > point
>> > though).
>>
>> My contact tells me they (BL & Indigo Trust) want to see the maps
>> reused; if there's a speciific request, I can forward it to them.
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk

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

Re: [Talk-GB] UK war office maps of Africa digitised

[Tim Waters]

On 1 February 2016 at 12:30, Jez Nicholson <jez.nichol...@gmail.com> wrote:

> I've copied my control points over to http://warper.wmflabs.org/maps/629
>

Great stuff. I think a few hundred maps (if not all) from this collection
are already in the wikimaps warper.
However there was an issue with making a mosaic (stitched layer) for the
category, so this will be fixed soon.

The "warped" parameter in the wiki page enables the button for users to get
from the wiki to the warper. You can add it to the pages, or you can search
for them within the warper itself.

I think the British Library also has control points for the maps which
could be added to the warper when ready (I'd have to double check on this
point though).

Regards,

Tim



>
> On Mon, 1 Feb 2016 at 11:51 Grant Slater <openstreet...@firefishy.com>
> wrote:
>
>> On 31 January 2016 at 20:04, Richard Fairhurst <rich...@systemed.net>
>> wrote:
>> >
>> > For individual sheets like this, I think Mapwarper (mapwarper.net) is
>> going
>> > to be your best bet. It's not the sort of task that's well suited to the
>> > techcentric skillset of OSM Operations (by which I mean Grant :) ) and
>> I'd
>> > be surprised if there were any local chapters willing to take it on,
>> though
>> > you could try HOT, perhaps.
>> >
>>
>> Agreed. I am only really setup to handle imagery/maps which have known
>> coordinates and projections. Maps with custom or eccentric
>> coordinates/projections are best manually geotagged and warped.
>>
>> Kind regards,
>>
>> Grant
>>
>> ___
>> Talk-GB mailing list
>> Talk-GB@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb
>>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb
>
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [OSM-talk] OpenRandomMap

[Tim Waters]

Great site! I got OpenRiceMap which you could actually imagine happening
(although with maybe the same likelihood happening as OpenSantaMap)
You could add an affiliate link to namecheap or something and give profits
to OSMF!

On 23 January 2016 at 19:04, Russ Nelson <nel...@crynwr.com> wrote:

> If the goal of having a map on the front page of osm.org is to
> illustrate the extent of our data...
>

I think it was Gregory Marler who said that what he'd really like to see in
the front page is a wireframe view, showing everything at every zoom level
but very minimally styled, points, lines. I think that would look great.

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

Re: [OSM-talk] Is there a OSM map viewer program to dynamically view OSM data?

[Tim Teulings]

Hello Wuzzy,


I was wondering if there is some standalone application (preferable for
PC) to view OSM data as a map, but dynamically and locally (not
from some random computer on the Internet) rendered.


[...]


What I want is an application which renders OSM data directly and based
on configurable user settings, i.e. switching on and off certain
features (like country borders) is as simple as clicking a checkbox.


You build such a tool with libosmscout (libosmscout.sf.net). It is  
designed for offline mobile rendering, routing and location search.  
But of course desktop application can also be build :-)


Libosmscout allows you to generate a (local) database from a given  
*.osm.pbf file with a user definable content. You can then render the  
data in a map using a custom style which can render any subset of the  
data contained in the database. It would also allow you to modify the  
style sheet dynamically (at least this can be very easily added).


The current demo however only shows the main base features so this is  
not yet part of the demo, but a proof of concept should be very easy  
and quick to achieve.

--
Gruß...
   Tim


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

Re: [Talk-GB] OSM UK group - Sign up to mail lists

[Tim Waters]

Hi Rob,

I've read over the minutes. Things look good.

On 17 December 2015 at 22:02, Rob Nickerson <rob.j.nicker...@gmail.com>

> As noted I would like to set up mailing lists as a replacement to the
> current system (mailing those who submitted an email address in the
> original survey). Please sign up via the following form. Page 2 (diversity)
> is entirely optional and I will only share annonymised results with the
> officers elect.
>

The minutes do not state that people agreed to set up non OSM mailing lists
as a replacement to the current system. I couldn’t find any discussion
about emails or mailing lists. All I could find was one action point:

"Rob: We should get e-mails. I’ll put a form on the talk-GB list."

Could you tell us who didn't attend the meeting and may be missing out on
some background, what is this form for?

For example, what were the attendees views on this mailing list talk-gb?
Why should people sign up on this new form, what benefits to signing, what
potential losses to not signing up etc. Is this new list private, non
public, or public and open to all? Is the intention to have it as members
only (similar to HOT-membership) or not?

Sorry if it may seem like you would be repeating yourselves from previous
discussions, but I feel it could be useful to get all potential interested
members on board :-)

Best regards,

Tim
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-de] Karten für Flüchtlinge

[Tim Kober [Kober-Kümmerly+Frey]]

> Ich bin da jetzt nicht auf dem Laufenden, deswegen die Frage: Gibt es da
> schon funktionierende Projekte? Webanwendungen, gedruckte Karten oder was für 
> Smartphones? 

Wir hatten auch schon einige Anfragen.

Falls die Kombination online/mobil/print gefragt ist, können wir unsere 
mapz-API anbieten (basiert auf OpenLayers 3). 

Damit können die gleichen Karten, die online interaktiv angezeigt werden, auch 
in bis zu 400 dpi ausgedruckt werden.

Ein fertiges Projekt gibt es aber noch nicht, d.h. es braucht Entwickler, die 
sich darum kümmern.

Meldet Euch bei Bedarf für einen API-Key. 

Tim



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

Re: [OSM-talk] What3words

[Tim Waters]

As an infrequent poster to osm-talk I think I'm excluded from Colin's "3 or
4 people" and "most active participants" and am not in the Fetted Inner
Core (at least I wasn't the last time I checked!) - however my views are
similar to the ones previously, in this case, very sorry Colin! :-)

In short, What Three Words does initially appear to be a "wow that's cool"
techy project, but given closer inspection it's not that suitable for an
open data project. It is not open or ground verifiable *at the moment*. Yes
it has got recently millions in funding. I frankly would expect more public
pressure to get it used in OSM than there has been. Perhaps they are
avoiding direct pressure until their board demands it, or perhaps they are
approaching the Foundation obliquely. I do know that they have been doing a
lot of work promoting the service to development and humanitarian
organisations, and they really are good at promoting their product. Very
many good quality proprietary data and software for profit companies make
healthy profits from working in the development and humanitarian
industries. One could think that such good causes should be the preserve of
Libre Software and non profit organizations, but that's a fallacy. Anyhow
I'm digressing, sorry!

So, if my local shops start to use it in the future, if "people on the
ground" use it, then I would say it could be added then - but there's no
benefit to mappers, or people on the ground for adding it before that stage.
At that stage, before people actually use it, it's just another way of
encoding location, and therefore redundant. Futhermore in both cases, the
only way for another mapper to tell if the reference is correct is to use
the third party API.

Given their approach and closedness however, I very much doubt that most
people will start using it. Perhaps they will buy into getting a developing
country to use it nationally, but we will have to see what happens. So, in
the future, if normal folks use it on the ground, it may be useful to add
it, in my humble opinion. Perhaps they will open source their algorithm but
keep their APIs and services closed, again we will have to see. Perhaps *if
and when it is used by people on the ground* we can pressure the company to
open up enough of their solution to make it OSM friendly and for them to
still please their board of investors?

But the main reason I don't see it being used in OSM is that it goes
against the spirit of the project.
This spirit of openness, collaborativeness and Libre software. It's closed,
it doesn't look like it will ever be open and it ties the usage of the
system through a closed API.  It's a closed data project, and OSM is *the*
open data project.

Cheers,

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

Re: [Talk-GB] Environment Agency LIDAR datasets OGL licensed now available

[Tim Waters]

Could subtracting between the DSM and DTM where we have buildings
already in OSM give the height of the buildings?



On 23 September 2015 at 15:08, Chris Hill  wrote:
> On 23/09/15 14:18, Phil Endecott wrote:
>>
>> Has anyone reviewed how useful this LIDAR data would be for 3D city
>> mapping?
>>
>> Chris Hill wrote:
>>>
>>> The slippy map with relief tiles made from the data and optionally
>>> contours also made from the data is here: http://relief.raggedred.net.
>>
>>
>> Thanks Chris.  I've just been looking at Hull city centre.  It doesn't
>> look great; is this the difference between the "terrain model" and the
>> "surface model" that they mention? Which are you using?  Have you looked
>> at the other one?
>
>
> It looks pretty realistic to me, I guess you mean it doesn't show building
> outlines, but that's why I chose the DTM version.
>>
>>
>> Of course I know that the rationale for the data is for flood risk
>> evaluation so recording building profiles was not the objective - but
>> you never know how something could be re-purposed!
>>
>
> In the blog article
> (http://chris-osm.blogspot.co.uk/2015/09/more-lidar-goodness.html) I explain
> a bit about the difference between DSM and DTM. DSM does include building
> outlines. I've processed a small part of the data to see them. Here's an
> example of a TIFF of DSM data with the building outlines:
> http://raggedred.net/shared/ta0230.tif
>
> Suitably processed this could provide a source of building outlines.
>
> I'm not sure about the age of some of the data. Some recently-built flood
> alleviation measures do not show on this EA data but do show on the Bing
> aerial imagery
>
> --
> Cheers, Chris
> user: chillly
>
>
> ___
> Talk-GB mailing list
> Talk-GB@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb

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

Re: [Talk-GB] Environment Agency LIDAR datasets OGL licensed now available

[Tim Waters]

Ahh correction, there *is* data at 25cm and 50cm in some areas (where
flooding is a threat) but it looks as if the 1m and 2m covers the
country.

Chris has written a post here also:
http://chris-osm.blogspot.co.uk/2015/09/more-lidar-goodness.html so
we're already playing with it.

Tim

On 22 September 2015 at 10:34, Tim Waters <chippy2...@gmail.com> wrote:
> Hello,
>
> back in June we had a thread announcing that this LIDAR data was due
> to be released. Well some of it has.
>
> https://environmentagency.blog.gov.uk/2015/09/18/laser-surveys-light-up-open-data/
>
> http://environment.data.gov.uk/ds/survey#/
>
> I think it's just for England, and appears to be 1m and 2m composite
> DTM and 1m and 2m DSM They do intend to release a Tiled version next,
> and I think 50cm and 25cm are coming also
>
> What can we do with it?
>
> Cheers,
>
> Tim

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

Re: [OSM-talk] Abandoned Rails

[Tim Waters]

I'd like to recommend OpenHistoricalMap.org (OHM) which will welcome
all types of historical, disused and abandoned features. Please, go
add every abandoned railway to OHM, and then together we can
eventually get an accurate map of 1880s railway network compared to a
1940's, compared to yesterdays world!

Tim



On 22/08/2015, Jason Remillard remillard.ja...@gmail.com wrote:
 Hi

 I'd therefor like to propose that abandoned railways be treated like
 borders.  Even if you can't see it along a given stretch there are people
 who can and they have put a huge amount of effort into that work.  Lets
 respect that and strengthen the community rather than deleting it and
 doing
 the opposite.

 I 100% agree. The amount of data required to map abandoned railroads
 is tiny. An occasional way through a new development is not going to
 hurt anybody or impair normal mapping activity.

 Apparently, the people that like to map railroads think OSM is the
 best place to do this. We are not in any position to be chasing them
 off. OSM has a long, long way to go still. Above all else, it needs to
 more active mappers if we are serious about being the best map for the
 entire world. Also, It seems likely they are also mapping non
 controversial things like roads while working on the railroads.

 Dave F, OSM is doing just fine. It is full of contradictions,
 redundancies, disagreements, and broken rules (see the tagging list).
 It is not some kind of business database that requires normalization,
 strict schema definitions, and vigilant protection. It can't have any
 once sentence rules defining its boundaries. It is a great big blank
 sheet of paper, relax and let the railroad people draw on it a bit.
 Nobody is going to get hurt.

 Jason

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


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

Re: [OSM-talk] When to celebrate OSM birthday?

[Tim Waters]

In previous threads discussing the anniversary, and there have been a few,
there was a generally accepted agreement that the birthday is the time when
the openstreetmap.org domain was first registered, 9 August, which happily
fell on a Saturday last year for the 10th Anniversary.  (This year it's on
a Monday)

Regards,

Tim

On 25 May 2015 at 22:30, Michael Reichert naka...@gmx.net wrote:

 Hi,

 when should we celebrate OSM birthday this year?

 It was a weekend in August in 2013 and 2014 I remember. How did you
 calculate the date?

 It would be nice to know this date early.

 Best regards

 Michael


 --
 Per E-Mail kommuniziere ich bevorzugt GPG-verschlüsselt. (Mailinglisten
 ausgenommen)
 I prefer GPG encryption of emails. (does not apply on mailing lists)


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


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

Re: [OSM-talk] OSM services

[Tim Waters]

cheers!

Glad that mapwarper proved a little bit useful, it was built for OSM.

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

Re: [Talk-GB] Fwd: Underground services

[Tim Waters]

I'm also interested in underground cables and mapping communications
routes, in particular the major internet trunk cables.

My question would be, similar to tunnels and other somewhat hidden
underground features -  how would we represent lengths along the route
where the positioning is unclear.
Before better sources of positions become available, would straight lines
in the database from A to B be allowed, or desired?
Shouldn't these unclear, holding lines never be rendered?

And, more interesting: how can we get better positioning information?
Could the scars along roads be used to help interpolation of positions?
Could we develop hand held instruments to detect various things?
Does dowsing work?
Can we use the markings sprayed on the pavement by utility companies to
identify what's there?

Cheers,

Tim
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-GB] [OSM-talk] OpenStreetMap ten years on, and why it's time for a fresh slate

[Tim Saunders]

What would suit me is an Android app that allowed me to see what needs to be 
fixed in a particular area, so that I could check some things out if I had a 
spare half hour in the area…..so Notes, FixMes, Musical Chairs, OSM Inspector 
and other GB specific stuff (e.g. post boxes, cycle routes, land registry 
addresses as examples I recall being discussed in this group).  Is there 
anywhere that these are all pulled together, even in a non-mobile friendly way? 
 As OSM coverage improves, I would suggest that there is more opportunity to 
fix things not mapped correctly than map things not mapped at all (although in 
my experience one leads to another anyway) and seeing something that is wrong 
is often more of a spur to get involved than something that is missing 
altogether.

 

From: Nick Whitelegg [mailto:nick.whitel...@solent.ac.uk] 
Sent: 25 October 2014 20:40
To: Richard Fairhurst
Cc: t...@openstreetmap.org; talk-gb@openstreetmap.org
Subject: Re: [Talk-GB] [OSM-talk] OpenStreetMap ten years on, and why it's time 
for a fresh slate

 

I can recite a few of them. We have very little mobile presence, even 
though smartphones are ideal surveying devices; a 5% intervention here 
would bring so many more people to our 95%.

 

Interesting points. I'd hope most of us, though, remain idealistic beyond our 
20s and don't turn into some sort of technophobic Farage-loving bore. ;-)

 

Regarding your point here, I've always wondered (and I think I mentioned this 
some time ago) whether there would be room for an easy footpaths editor 
(sorry to go on about footpaths but it's my pet OSM thing). The user simply 
records their GPS trace on their phone via a custom app, and selects, via a 
simple dropdown etc, the current right-of-way type (footpath, bridleway etc). 
The trace is simplified (e.g. Douglas-Peucker) and converted directly to an OSM 
file (I think this is what I did way back with osmeditor... anyone remember 
that?) 

 

When back home the data is uploaded. This could be done in a number of ways 
e.g. OSM data could be downloaded and then some sort of algorithm applied to 
detect which part of the trace is new. Those segments which are new are then 
joined - initially automatically but with option to change - to existing data 
and then uploaded to the server. Alternatively, one could throw some OSM data 
at the server and have the server figure out which parts are new and which are 
not - though that would of course involve an extension to the API.

 

Is this something that could be of interest? (cc to talk-gb as it's slightly 
UK-centric but could be used elsewhere potentially)

 

Nick

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

Re: [OSM-talk-nl] [Dutch] PostGIS Workshop door OSGeo.nl

[tim . blokdijk]

Dat zou ik best interessant vinden.. kan ik ook een keer kijken wat het 
GeoFort is.

Wel even een vraag, in de mail staat 8 okt. op de meetup site staat 9 okt.?
En de kosten zijn 12,50?

/Met Vriendelijke Groeten,/

*Tim Blokdijk*

ICT en Procescoördinator
Stichting Thuiszorg De Sleutel
Nieuwe Fellenoord 38,
5612 KD Eindhoven
Tel. 040-2489669
Op 11-09-14 om 12:16 schreef Just van den Broecke:

Beste Mensen,

We hebben een tijd en een plaats gevonden voor de PostGIS Workshop: 8 
oktober 18:30-22:30 in Het GeoFort (met dank aan Geo-Academie voor 
beschikbaar stellen). Je kunt je inschrijven via de Meetup:

http://www.meetup.com/OSGeoNL/events/202043712
of door een mail aan eve...@osgeo.nl.

Geef ook door aan collega's. Hartelijke groet,

Just

On 17-08-14 17:23, Just van den Broecke wrote:

Beste Mensen,

Ja een cross-post, maar PostgreSQL/PostGIS, kortweg PostGIS hier, wordt
door ons allen gedeeld...

Op de OpenTopo workshops door JW van Aalst bleek er behoefte te zijn aan
workshops door OSGeo.nl http://osgeo.nl rond basis tools: met name
PostGIS en QGIS.
Twee grote specialisten zijn bereid een PostGIS workshop te geven:
Michel Sijmons (Nibble IT) en Wouter Boasson (RIVM/HAS).

Tijdstip/plaats ergens tussen 15 sept en 1 nov 2014, centrale plek, in
de avond plm 3 uur.

Wat zou je graag in zo'n workshop zien? Er staat een poll op de OSGeoNL
Meetup http://www.meetup.com/OSGeoNL/polls/352 maar je kunt mij ook
direct max 6 van onderstaande opties mailen.

  Installatie: hoe en wat: Mac/PC/Linux
  Beheer tools: PGAdmin III, PhpPgAdmin
  Inladen van data: commando's, ETL tools
  Ruimtelijke (spatial) queries
  Gebruik binnen QGIS
  Map/feature (WMS/WFS) web services realiseren
  Ruimtelijke analyse
  Praktijk-cases
  Ik wil vooral hands-on met laptop
  Nieuwe functies: Raster, PointCloud etc
  Opschalen: replicatie, EnterpriseDB etc
  Maakt niet uit: verras me

Ik hoop van jullie te horen!

Hartelijke groet,

--Just

Just van den Broecke
Secretaris Stichting OSGeo.nl






___
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


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

Re: [Talk-GB] Update: Deploying our own version of NYPL Building Inspector

[Tim Waters]

Hi folks,

here's my thoughts

Moving forward:
Remember that people will fix the automatic vectorisations if they are off
- they can also add extra buildings if need be also.
I think we have enough to move it forward and see what happens. As the NYPL
Building Inspector says: Don't let perfect be the enemy of good

Branding:
Yes I think it should be branded an OHM project - but with space for donors
and supporters particularly if other organisations apart from NLS want to
get involved.
I've also forked the project into the OpenHistoricalMap repo
https://github.com/OpenHistoricalMap/building-inspector as I think that's
the best place for it (not sure why I didn't do that at first, tbh)

cheers,

Tim


On 1 June 2014 18:25, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Hi All,

 An update on progress deploying our own version of NYPL's historic map
 vectorizer/building inspector tool [1].


1. Chris Fleet from National Library of Scotland (NLS) has kindly
provided a couple of GeoTiff example scans from their London 1890's maps
[2].
2. Using the NYPL map-vectorizer [3] I am able to get initial building
outlines from these maps.
3. Tim Waters has managed to get a copy of the NYPL website up ready
for loading NLS's maps/vectorized buildings. This is at [4]. Meanwhile he
has opened initial conversations with the British Library who also have a
good collection of historic maps.
4. I am concerned that the initial building outlines end up leaving
gaps between terraced buildings. This is due to the way that the NYPL
map-vecotrizer works to trace the _inside_ of buildings. I'm no GIS expert
so may be missing a simple solution. However I have noticed that we could
use the Strava Slide tool [5] to 'slide' the building polygons onto the
building walls. In essence this works by using pixel blackness of the map
scan (rather than GPS traces as per the initial Strava Slide tool).
5. I have contacted Paul at Strava to ask about this. He thinks the
idea is a really good one and is hoping to add the functionality we will
require. He's a bit busy at the moment but is presenting at FOSS4G (in
September?) and would like to use this as an example of what's possible
with slide.

 So, where does this leave us? Well we're at the same place as NYPL so
 could go ahead with adapting the website Tim put up to our needs and then
 launch when ready. Or, we could hold off until Paul at Strava is able to
 add the functionality we need to the Slide tool.

 Thoughts?

 Also, are folks happy for this to be branded as an OpenHistoricalMap
 project? (Chris at NLS is okay with this).

 Regards,
 Rob

 [1] http://buildinginspector.nypl.org/
 [2] http://maps.nls.uk/os/london-1890s/index.html
 [3] https://github.com/NYPL/map-vectorizer
 [4] http://leatherwood.herokuapp.com/
 [5] http://labs.strava.com/slide/

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

Re: [Talk-GB] [OHM] New York Public Library - Building Inspector

[Tim Waters]

Hi folks,

I've heard back from the British Library - they are hugely interested with
the Map-Vectorizer work - it's really encouraging.

In brief they said that they were positive but that they'd need to get some
things sorted first, looking at licensing, formats etc and they would
update me soonish.

In the meantime I suggest we go ahead with the NLS maps and see if we can
get our stack up and running with those maps?

Cheers,

Tim


On 18 May 2014 23:01, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Nice work Tim.You're right about the traced and centroid JSON files.They
 do indeed come out of the NYPL map-vectorizer [1]. I've got a version of
 this up and running on my computer and have successfully vectorized the
 test file.

 Chris Fleet (from NLS) has sent me some test maps, however these are Jpeg
 2000 files and are causing quite a bit of trouble so far. At first I
 thought it was a bug in my computer (in the jasper library that's
 responsible for opening jp2 files), but I tried a second computer today and
 that failed to. I'll get in touch with Chris again. Meanwhile those BL Goad
 maps look great. Let us know if you hear back from BL.

 Thanks for your help,
 Rob

 [1] https://github.com/NYPL/map-vectorizer


 On 18 May 2014 22:35, Tim Waters chippy2...@gmail.com wrote:

 Couple of things - building inspector update and British Library Goad
 maps.

 Building Inspector update:

 I've got it working and have put up an instance on heroku for the moment
 - Works well and it can handle 10K rows in the database for free.

 http://leatherwood.herokuapp.com/
 * It's just got about half of the NYPL data in it
 * Only Twitter log in will work for it.
 * Initially only the Check Polygons task will work until there's enough
 that's been checked, and then the other tasks become unlocked.

 The code is here: https://github.com/timwaters/building-inspector

 So, it does require some configuring. We need:
 * a tile set for the basemap
 Also - some files like what's in
 https://github.com/timwaters/building-inspector/tree/master/public/files:
 * ingestor_config_builder.py run on the geotiffs
 * The traced and centroid json files which I imagine are generated by the
 vectorising process.

 We'd also need to tweak the website blurb etc

 Overall it should be quite easy to get a pilot area done.

 -

 British Library Goad Maps

 Like the NYPL's maps - these are fire insurance maps of the 19th century
 - they have various colours, addresses etc and great detail. They are the
 perfect thing for our Building Inspector. In addition, the coverage is
 immense. Major towns and cities in Ireland and the UK.

 http://www.bl.uk/onlinegallery/onlineex/firemaps/fireinsurancemaps.html

 I've reached out via Twitter and via email to the Library asking for a
 couple of maps for a pilot area to look at.

 Cheers,

 Tim




 On 16 May 2014 19:57, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Thanks for you help Tim,

 The NYPL code is here:
 https://github.com/NYPL/building-inspector/

 I'm assuming it's rails as that's mentioned in some of the code commits,
 but I don't know any more than that.

 Best,
 Rob

 p.s. The code for vectorizing maps is also on GitHub. Chris has sent me
 a couple of GeoTIFs so I'm going to have a go with them this weekend.



 On 16 May 2014 12:51, Tim Waters chippy2...@gmail.com wrote:

 I might have some time this weekend to look at the Rails side of things
 (that is, if no one else has made any progress)

 Will ping back in a couple of days

 Tim


 On 12 May 2014 21:08, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Hi Steven,

 Thanks for the offer of help. Yesterday I managed to get the NYPL
 vectorizer working (this is the tool that has a first stab at creating
 vectors from the map). I did this on a small screenshot of NLS's London
 maps. I've asked Chris if he could send me a GeoTIF to do a larger scale
 test.

 Some of the key areas that I think need addressing:

 * Improving the automated vectorizer. Currently the vectorizer creates
 polygons of the inside of buildings (rather than following the wall). For 
 a
 terraced street this produces a row of detached buildings. Some processing
 could improve this. I guess this could be done before, after, or both
 before and after the polygon has been processed by the human volunteers on
 the website.
 * The website looks like it's a Rails site. I would need a lot of help
 with this as it's an area I know very little about.

 Are you able to help with either of these?

 Kind regards,
 Rob


 On 12 May 2014 16:26, Steven Horner ste...@stevenhorner.com wrote:

 Hello,

 I would be happy to help in anyway and have previously had a
 conversation with Chris at NLS regarding helping georeference some of 
 their
 maps.

 I had been looking into creating my own historical version of OSM for
 a local personal project, when I looked a few weeks ago Open Historical 
 Map
 was down and was never very usable before that. It sounds like from the
 WIKI

Re: [Talk-GB] [OHM] New York Public Library - Building Inspector

[Tim Waters]

Couple of things - building inspector update and British Library Goad maps.

Building Inspector update:

I've got it working and have put up an instance on heroku for the moment -
Works well and it can handle 10K rows in the database for free.

http://leatherwood.herokuapp.com/
* It's just got about half of the NYPL data in it
* Only Twitter log in will work for it.
* Initially only the Check Polygons task will work until there's enough
that's been checked, and then the other tasks become unlocked.

The code is here: https://github.com/timwaters/building-inspector

So, it does require some configuring. We need:
* a tile set for the basemap
Also - some files like what's in
https://github.com/timwaters/building-inspector/tree/master/public/files :
* ingestor_config_builder.py run on the geotiffs
* The traced and centroid json files which I imagine are generated by the
vectorising process.

We'd also need to tweak the website blurb etc

Overall it should be quite easy to get a pilot area done.

-

British Library Goad Maps

Like the NYPL's maps - these are fire insurance maps of the 19th century -
they have various colours, addresses etc and great detail. They are the
perfect thing for our Building Inspector. In addition, the coverage is
immense. Major towns and cities in Ireland and the UK.

http://www.bl.uk/onlinegallery/onlineex/firemaps/fireinsurancemaps.html

I've reached out via Twitter and via email to the Library asking for a
couple of maps for a pilot area to look at.

Cheers,

Tim




On 16 May 2014 19:57, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Thanks for you help Tim,

 The NYPL code is here:
 https://github.com/NYPL/building-inspector/

 I'm assuming it's rails as that's mentioned in some of the code commits,
 but I don't know any more than that.

 Best,
 Rob

 p.s. The code for vectorizing maps is also on GitHub. Chris has sent me a
 couple of GeoTIFs so I'm going to have a go with them this weekend.



 On 16 May 2014 12:51, Tim Waters chippy2...@gmail.com wrote:

 I might have some time this weekend to look at the Rails side of things
 (that is, if no one else has made any progress)

 Will ping back in a couple of days

 Tim


 On 12 May 2014 21:08, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Hi Steven,

 Thanks for the offer of help. Yesterday I managed to get the NYPL
 vectorizer working (this is the tool that has a first stab at creating
 vectors from the map). I did this on a small screenshot of NLS's London
 maps. I've asked Chris if he could send me a GeoTIF to do a larger scale
 test.

 Some of the key areas that I think need addressing:

 * Improving the automated vectorizer. Currently the vectorizer creates
 polygons of the inside of buildings (rather than following the wall). For a
 terraced street this produces a row of detached buildings. Some processing
 could improve this. I guess this could be done before, after, or both
 before and after the polygon has been processed by the human volunteers on
 the website.
 * The website looks like it's a Rails site. I would need a lot of help
 with this as it's an area I know very little about.

 Are you able to help with either of these?

 Kind regards,
 Rob


 On 12 May 2014 16:26, Steven Horner ste...@stevenhorner.com wrote:

 Hello,

 I would be happy to help in anyway and have previously had a
 conversation with Chris at NLS regarding helping georeference some of their
 maps.

 I had been looking into creating my own historical version of OSM for a
 local personal project, when I looked a few weeks ago Open Historical Map
 was down and was never very usable before that. It sounds like from the
 WIKI things maybe starting to happen, date slider planned, etc.

 regards,
 Steven


 On Sat, May 10, 2014 at 10:04 PM, Rob Nickerson 
 rob.j.nicker...@gmail.com wrote:

 Hi All, Historic Map folks,

 I have now heard from Chris at National Library of Scotland (NLS). He
 is very supportive* of the idea of using something similar to the NYPL
 Building Inspector software and website for digitizing some of NLS's
 historic maps. As NYPL have made all their software Open Source, it should
 be relatively easy to roll this out with NLS's (or other) maps.

 Who's interested in getting involved? You lot set the pace of this :-D

 Regards,
 Rob

 * NLS would be able to supply the scanned and geo-rectified maps. As
 with everyone else their ability to do any more is limited by their level
 of funding. This should not be a problem as we can self host the website.







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

Re: [Talk-GB] [OHM] New York Public Library - Building Inspector

[Tim Waters]

I might have some time this weekend to look at the Rails side of things
(that is, if no one else has made any progress)

Will ping back in a couple of days

Tim


On 12 May 2014 21:08, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Hi Steven,

 Thanks for the offer of help. Yesterday I managed to get the NYPL
 vectorizer working (this is the tool that has a first stab at creating
 vectors from the map). I did this on a small screenshot of NLS's London
 maps. I've asked Chris if he could send me a GeoTIF to do a larger scale
 test.

 Some of the key areas that I think need addressing:

 * Improving the automated vectorizer. Currently the vectorizer creates
 polygons of the inside of buildings (rather than following the wall). For a
 terraced street this produces a row of detached buildings. Some processing
 could improve this. I guess this could be done before, after, or both
 before and after the polygon has been processed by the human volunteers on
 the website.
 * The website looks like it's a Rails site. I would need a lot of help
 with this as it's an area I know very little about.

 Are you able to help with either of these?

 Kind regards,
 Rob


 On 12 May 2014 16:26, Steven Horner ste...@stevenhorner.com wrote:

 Hello,

 I would be happy to help in anyway and have previously had a conversation
 with Chris at NLS regarding helping georeference some of their maps.

 I had been looking into creating my own historical version of OSM for a
 local personal project, when I looked a few weeks ago Open Historical Map
 was down and was never very usable before that. It sounds like from the
 WIKI things maybe starting to happen, date slider planned, etc.

 regards,
 Steven


 On Sat, May 10, 2014 at 10:04 PM, Rob Nickerson 
 rob.j.nicker...@gmail.com wrote:

 Hi All, Historic Map folks,

 I have now heard from Chris at National Library of Scotland (NLS). He is
 very supportive* of the idea of using something similar to the NYPL
 Building Inspector software and website for digitizing some of NLS's
 historic maps. As NYPL have made all their software Open Source, it should
 be relatively easy to roll this out with NLS's (or other) maps.

 Who's interested in getting involved? You lot set the pace of this :-D

 Regards,
 Rob

 * NLS would be able to supply the scanned and geo-rectified maps. As
 with everyone else their ability to do any more is limited by their level
 of funding. This should not be a problem as we can self host the website.





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

Re: [talk-au] Proposed data import. Queensland peaks and mountains

[Tim Ney]

Hi Jason,  there are 250k topographic map datasets at geoscience that contain 
contour information.  I can't remember if they are 20 or 50m intervals. They 
are free, and available as shape files all over Queensland.  Tiles are normally 
40 x 40km.  I have found this very useable particular in the Connors range area 
where peaks are not obvious because of the heavy vegetation.  

I hope this helps

Sent from my iPhone

 On 5 May 2014, at 10:41 am, Jason Ward jasonjwa...@gmail.com wrote:
 
 Hi Tim,
 
 Agree with a zoned verification approach.  To your point about accuracy would 
 the OpenCycleMap countours be a valid positional accuracy check?  If I read 
 this link [1] correctly they are =/- 16m in vegetated areas and +/-5m.
 I note that this maps tiles have implemented at 10m intervals as well and if 
 I were verifying this peak (Mt Toby) I'd suggest it could be made more 
 accurate (moved left approx 150m).
 
 Would that be a better approach?  [3]: FYI.
 
 [1]: 
 http://www.nrm.qld.gov.au/services_resources/item_details.php?item_id=34171
 [2]: http://www.openstreetmap.org/#map=16/-21.1074/148.8531layers=CN
 [3]: http://wiki.openstreetmap.org/wiki/SRTM
 
 
 Cheers,
 
 Jason
 
 
 I don't want to be a downer but I found the information to be so inaccurate 
 as to border on useless.
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-GB] [OHM] New York Public Library - Building Inspector

[Tim Waters]

Those are some good examples - they appear to be around the same scale
also.
They are monochrome and don't have addresses which should limit a couple of
the types of the tasks.  Could be worth trying the Building Inspector with
this dataset.

I wonder if there's anyone from the NLS on list?


On 1 May 2014 19:11, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Yes, all Open. It's great.

 In terms of how we could use it here in the UK, the best data I can think
 of is the OS Town Plans for Scotland that NLS have as individual map sheets
 and as a slippy map:


 http://maps.nls.uk/geo/explore/#zoom=19lat=57.14443lon=-2.1054layers=B0TFF

 There is also some great London data:


 http://maps.nls.uk/geo/explore/#zoom=19lat=51.52008lon=-0.12473layers=B0FTF

 We have a pretty good relation with NLS. Is there any interest in our
 community to enquire about working with them?

 Rob


 On 30 April 2014 15:46, Tim Waters chippy2...@gmail.com wrote:

 Hi Rob,

 it has been on the list before - but they have recently revamped it and
 added many more features, and maps! In my opinion it's a shining example of
 how geo crowdsourcing applications should be.

 I believe it has been developed internally with the library - and I think
 they are just using Mapbox to host the tiles (originally coming from the
 warper at maps.nypl.org)

 The code is on github: https://github.com/NYPL/building-inspector and
 the data is available to download as well.
 http://buildinginspector.nypl.org/general/data

 Cheers,

 Tim


 On 29 April 2014 22:44, Rob Nickerson rob.j.nicker...@gmail.com wrote:

 Don't think I've spotted this on the historic mailing list so I'll post
 it.

 NYPL digitizing old maps using crowd sourcing. I just gave it a go and
 it works very well.

 http://buildinginspector.nypl.org/

 Looks like Mapbox has some involvement, or at least the map display has
 a similar style to mapbox's. I wonder whether the software is open as we
 can use this to help OpenHistoricMap.

 Rob

 ___
 Historic mailing list
 histo...@openstreetmap.org
 https://lists.openstreetmap.org/listinfo/historic




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