date:20190118

John,

I'm sorry to keep saying this, but I really do not think this is an 
acceptable import approval process.

You're saying there was no wiki describing the plan when this went to 
the imports mailing list - only a link to a similar plan with related 
data. You did not follow the import guidelines and you need to go back 
and read that page line by line and follow the procedures that we have 
in place.

https://wiki.openstreetmap.org/wiki/Import/Guidelines
I'll go ahead and add a mention of this plan to the imports catalogue to 
get us started. I'll also add some sections to the wiki and try to leave 
some indication of where things can be better documented.

You may think I'm quibbling over procedural details, but I think this 
process is really important. If we were talking about importing 
buildings in one neighborhood, I would look the other way, but this is 
all of Canada. This is a huge, huge import and we need to take the time 
to do things right, and especially to document the process so people can 
get involved that aren't already.

Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 3:48 PM, John Whelan wrote:
The import mailing list was pointed to the correct page of the wiki.  
The initial post was to say this is what we were thinking of and there 
was a comment saying we needed to change the comment line.

>There is no mention of this proposed import on the import catalogue

The import process was reviewed by the person who set up the Ottawa 
import did we miss that step on the Ottawa import as well?  Neither 
was it raised as a concern on the import mailing list. I think this is 
very minor and can be corrected.

We learnt a fair bit on the Ottawa import and my expectation is since 
we are using experienced mappers to do the import conflation would be 
either handled by them or the building not imported. We aren't using 
new mappers in a mapathon here and with experienced mappers then I 
think you have to trust them. The world isn't perfect. Think in terms 
of service level.

>There are 2X more nodes than needed to represent the building accurately.

The problem with correcting this is you are introducing 
approximations.  This will vary according to the source and this can 
be simplified or corrected once its in OSM. I think this is a 
different issue of a mechanical edit that needs to be considered 
separately.

If we are concerned with database size then I suggest we change the 
instructions to say put the source comment on the change set rather 
than on the building outline.

Cheerio John

Nate Wessel wrote on 2019-01-18 3:06 PM:

John,

You seem to be playing the long game with this data - it sounds like 
you've been working with this a lot longer than I have, and you've 
put in the time and effort to help make this 
actually-quite-incredible dataset available to us. I don't want to 
stop the import from happening - quite the opposite. I just want to 
make sure that the time is taken to do this right. OSM deserves that. 
Your (our) long awaited victory will be the sweeter for our patience 
now.

There are several specific issues I see where the I's are not 
crossed, nor the t's dotted. I've mentioned several already, so I'll 
try to be brief (I really need to get back to working on my 
dissertation).

1) There was extremely limited discussion on the imports mailing 
list. The initial email did not make clear the scope of the project. 
I read the email and did not think twice at it, thinking it was 
entirely about Ottawa. The link in that email was actually to the 
Ottawa import, and not this one, which seems to have been only in 
draft at the time. 
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list, 
which is a requirement for proceeding with the import.

2) There is no mention of this proposed import on the import 
catalogue (https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other 
guidelines have not been followed.

3) The wiki page describing the import is not adequate to assess the 
quality of the data or of the proposed import. See for example: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
The import guidelines call for a description of how conflation will 
be handled. The fact that two of the major importers seem to have a 
substantial disagreement about how to handle existing data indicates 
this was not well discussed and I can see that it isn't well documented.

4) The buildings need to be simplified, quite a bit actually. Most 
buildings have multiple nodes representing straight lines. This 
bloats the database and makes things harder to edit by hand later. 
There are probably 2x more nodes than are needed to represent the 
data accurately, making it

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted


Hi Yaro,

Thanks for marking this as on-hold in the tasking manager. I know I came 
in like a wrecking ball and I really appreciate y'all holding things up 
while we discuss.


I'd be happy to validate data and help import the rest of central 
Toronto once we're up and running again! I use the data in this area a 
lot in my work... so I have a vested interest in keeping it at it's best :-)


As to the conflation issue, one of the things we're doing in the other 
import I'm working on is that we've essentially split it into two parts. 
First we're importing buildings that don't conflict with OSM at all - 
this is the easy part - and only later will we go in a bit more 
surgically and try to add tags to existing ways and replace geometries 
with better data. We haven't started that part yet, though I imagine it 
will be a real slog. IMO, it seems like a lot to ask that editors do 
both things at once as these are really very different tasks, especially 
given the size of the tasks here.


I wonder if you'd have any interest in a similar separation of tasks for 
this import? I think one of the benefits is that less experienced 
mappers can get their hands dirty on the easier new-data-import part, 
without having to be expert on which geometry is better, how to preserve 
way histories and tags, etc. Like I said, we haven't started this part 
yet in the other import, but even I find the prospect a little daunting!


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:15 PM, Yaro Shkvorets wrote:

Nate,
I'll change the project name to reflect that the import is on hold. As 
a local mapper, if you want to take a lead on the Toronto import 
that'd be great.
I did review some of DannyMcD's edits last night 
(Mississauga-Brampton-Vaughan) and to be honest was rather 
disappointed with the quality. It appears Danny chose to import only 
new buildings (i.e. residential homes mostly), leaving most of the 
existing hand-traced non-residential building outlines in OSM 
untouched. That's unfortunate, the dataset offers some really good 
data and leaving half of it behind makes it more difficult to revisit 
in the future.
In my edits (Markham-Scarborough-East York) I was aiming to replace as 
many existing geometries with outlines from the import as possible. I 
think that's what we should be trying to do going forward.

Looking forward to your comments and discussion.



On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel > wrote:


Hi all,

I've just joined the talk-ca list, so please accept my apologies
for not addressing this list earlier. I'm happy to take this
thread off the imports list for now and onto talk-ca until things
are ready to begin again. The next person to reply can please feel
free to remove that email if they agree.

I've just made a note on the draft import plan wiki page noting
that the import has been stopped:


https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

I would really appreciate it if the person with admin access to
the tasking manager projects could please take those offline for
the moment, or perhaps place them in a validation-only mode if
that's possible.

Like I said in my last email, which perhaps didn't make it to the
talk-ca list
(https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
I'm now proposing that we leave the data that has already been
imported and enter a phase of thorough validation on that data.

My plan, over the next several days, is to do a general survey of
the quality of the data that has been imported so far and make a
list of systematic issues I see that should be addressed before we
can consider moving forward again. I'll add those comments to the
conversation in talk-ca and on the wiki page (link above), as I
feel is appropriate. As I said before, I'm of the mind that this
import did not get adequate review or approval and did not follow
all the import guidelines. I think therefore we need to take
stock, cross the t's, dot the i's, and move this thing back toward
where it needs to be. Step one is a thoroughly documented wiki
page outlining the proposal and responding to everything required
in the import guidelines.
https://wiki.openstreetmap.org/wiki/Import/Guidelines

I know there are people excited about this import, and people who
are eager to get back to work bringing buildings in, but I think
everyone will be happier in the end if we take the time to do this
right. We don't need to stop forever - we just need to stop until
we get things right. I sincerely respect the good intentions of
everyone involved in this and I hope we can all work together to
make OSM a map known for it's coverage AND it's quality.

Best,

[Talk-TW] 千里步道繪製

2019-01-18 Thread Dennis Raylin Chen

Hi All,

很久以前曾在Talk-TW提過千里步道

但還沒加到 OpenStreetMap 裡

現在實際把路線用關係的方式編輯

看到千里步道網站提供的路徑，有時候跑到農田裡，或是路徑跑到河對岸去

不知道是不是當年GPS沒那麼好相當容易漂走

後來看到UrMap發現他們贊助的千里步道路線版本，狀況好多了，至少不會跑去奇怪的地方

目前有兩條線編輯上去了

環島山線: https://www.openstreetmap.org/relation/9141839
基隆支線: https://www.openstreetmap.org/relation/9173937

歡迎大家一起來繪製，還有海線以及好幾條地方支線沒有編輯上去

https://trello.com/c/bdvcmzrk/1166-%E5%8D%83%E9%87%8C%E6%AD%A5%E9%81%93%E9%97%9C%E4%BF%82%E5%BB%BA%E7%AB%8B

Dennis
___
Talk-TW mailing list
Talk-TW@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-tw

Re: [Talk-cr] Eliminar 51 puntos extraños

2019-01-18 Thread Leo Arias

On Fri, Jan 11, 2019 at 05:49:35PM -0600, Jaime Gutiérrez Alfaro wrote:

> Yo creo que esos puntos deben haber subido a osm por error y no deberían de
> estar ahí, así que propongo eliminarlos todos. ¿qué opinan?

De acuerdo con borrarlos.


signature.asc
Description: PGP signature
___
Talk-cr mailing list
Talk-cr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cr

Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)

2019-01-18 Thread Pavel Zbytovský

Takový účet už dokonce existuje, používali jsme ho na rozeslání pozvánek k
SotMu 2016 a vydržel.
Kdyby byl zájem, rád poskytnu radě heslo (ikdyž Tom ho myslím má taky).

https://www.openstreetmap.org/user/osmcz



On Fri, Jan 18, 2019 at 12:24 PM Marián Kyral  wrote:

> Tohle by se možná dalo řešit speciálním OSM účtem, ke kterému by měli
> přístup všichni členové rady.
> Jen nevím, jestli by nevadilo, že by pod tím účtem nebyly žádné
> changesety. Aby nám účet při nějaké čistce nesmazali :-D
>
> Marián
>
> -- Původní e-mail --
> Od: Tom Ka 
> Komu: OpenStreetMap Czech Republic 
> Datum: 18. 1. 2019 11:54:59
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)
>
> Nezavrhlo se to uplne, ale je tam zasadni nevyhoda, ze je to smerovano
> na jednoho konkretniho cloveka, ne na celou radu, coz pri zmene rady
> neni idealni. GPG je obecnejsi, takze vim, ze se bude dat pouzit.
> Navic neni zavisly na zadne 3 strane.
>
> Bye
>
> pá 18. 1. 2019 v 10:56 odesílatel Pavel Zbytovský  napsal:
> >
> > Ještě bych měl podnět ke GPG klíči: na úvodní schůzi se mluvilo o
> možnosti hlasování zkrze messaging system osm.org - já bych tuhle verzi
> preferoval, protože to bude fungovat všem a míra bezpečnosti je přibližně
> stejná. (Když to srovnám s používáním pro lidi neznáme technologie, kterou
> jinak na nic nevyužijou.)
> >
> > Proč se to vlastně zavrhlo?
> >
> > P.
> > ___
> > talk-cz mailing list
> > talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

I'm not familiar with the tool, but that is essentially what I'm asking 
for -  nothing all that complicated. We would need to make sure we're 
not losing any valuable detail though, and ensure that topology is 
preserved where buildings share nodes.

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 4:24 PM, James wrote:
I can run all the shapefiles through qgis simplify tool if this 
resolves the issue...

On Fri., Jan. 18, 2019, 4:08 p.m. Nate Wessel  wrote:

With default settings in JOSM, sure. In the import I was working
on, we used a Douglas-Peucker algorithm with a 20cm threshold
(before the import started) and it worked beautifully. We had many
points that seemed to have been introduced in the shapefiles as
some kind of data artifact - they didn't add any detail to the
shape at all. This procedure removed almost all of them with no
discernible reduction in quality.

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban
Planning
NateWessel.com 

On 1/18/19 4:03 PM, James wrote:

dare you to run simplify tool on anything remotely round, it will
make it look like garbage

On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan
mailto:jwhelan0...@gmail.com> wrote:

The import mailing list was pointed to the correct page of
the wiki.  The initial post was to say this is what we were
thinking of and there was a comment saying we needed to
change the comment line.

>There is no mention of this proposed import on the import
catalogue

The import process was reviewed by the person who set up the
Ottawa import did we miss that step on the Ottawa import as
well?  Neither was it raised as a concern on the import
mailing list. I think this is very minor and can be corrected.

We learnt a fair bit on the Ottawa import and my expectation
is since we are using experienced mappers to do the import
conflation would be either handled by them or the building
not imported. We aren't using new mappers in a mapathon here
and with experienced mappers then I think you have to trust
them.  The world isn't perfect. Think in terms of service level.

>There are 2X more nodes than needed to represent the
building accurately.

The problem with correcting this is you are introducing
approximations.  This will vary according to the source and
this can be simplified or corrected once its in OSM. I think
this is a different issue of a mechanical edit that needs to
be considered separately.

If we are concerned with database size then I suggest we
change the instructions to say put the source comment on the
change set rather than on the building outline.

Cheerio John

Nate Wessel wrote on 2019-01-18 3:06 PM:

John,

You seem to be playing the long game with this data - it
sounds like you've been working with this a lot longer than
I have, and you've put in the time and effort to help make
this actually-quite-incredible dataset available to us. I
don't want to stop the import from happening - quite the
opposite. I just want to make sure that the time is taken to
do this right. OSM deserves that. Your (our) long awaited
victory will be the sweeter for our patience now.

There are several specific issues I see where the I's are
not crossed, nor the t's dotted. I've mentioned several
already, so I'll try to be brief (I really need to get back
to working on my dissertation).

1) There was extremely limited discussion on the imports
mailing list. The initial email did not make clear the scope
of the project. I read the email and did not think twice at
it, thinking it was entirely about Ottawa. The link in that
email was actually to the Ottawa import, and not this one,
which seems to have been only in draft at the time.

https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports
list, which is a requirement for proceeding with the import.

2) There is no mention of this proposed import on the import
catalogue (https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many
other guidelines have not been followed.

3) The wiki page describing the import is not adequate to
assess the quality of the data or of the proposed import.
See for example:

Re: [Talk-ca] [Imports] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread Kevin Kenny

On Fri, Jan 18, 2019 at 2:54 PM Yaro Shkvorets  wrote:
> JOSM offers very convenient way to do it called "Replace geometry". Select 
> both ways, old and new, press Ctrl-Shift-G, merge any conflicting tags and 
> you preserve the history, tags and have new improved outline in a couple of 
> clicks.

Good point. I use that a *lot* when updating the New York public land
boundaries. Is it in a stock JOSM now? You used to have to install a
plugin (with some uninformative name like 'Utilities') to get it. It's
an absolute necessity for importers.

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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread John Whelan


I agree and we are sensitive to Quebec's position.

I think the hope was we would make the data available and that local 
mappers would be involved in the import over time as happens with 
CANVEC.  One comment I heard early on was this isn't so much an import 
as a marathon.


What seems to have happened is a lot of buildings have been imported 
very quickly.  In rural areas or places where there are few buildings 
this isn't so much of a problem. Certain locations have run in very 
smoothly.


I think the data quality is considerably better than iD and Mapathons 
with new mappers.


The original data files are available on an Open Data portal with a 
license that is compatible with OSM and to be honest we have very little 
control over who can download them or what they do with them.


What we do have is a process that was used in Ottawa and is fairly 
robust. Data quality is very dependent on the individual mappers doing 
the import though.


Looking at the stats I don't think much has been done in Quebec and I 
feel James would be happy to restrict access Quebec in someway if that 
would make you happier for the moment.  It has been set up as a separate 
set of tiles so can be isolated fairly easily.


Could you be nice and chat to the Quebec mappers and sound them out on 
what they would like to do?  The data for Quebec is from Quebec 
municipalities by the way.  Please bear in mind that Microsoft are 
rumoured to be about to release building data for Canada in the same way 
as they have for the US.  This is scanned from images data and I suspect 
the data quality will not be as high as the Municipal data.  I 
understand there are multiple imports going on with the US Microsoft 
building outline data currently.


I seem to recall that Daniel Begin, who I believe is a Quebec mapper, 
made comments on the project in talk-ca some time ago.  I also seem to 
recall it was his suggestion that we made it a single import plan.


Thoughts?

Thanks John

Pierre Béland wrote on 2019-01-18 6:54 PM:

John,

Il y a local et local. Compte-tenu des différences culturelles Québec 
vs Canada en général et que les contributeurs du Québec ne fréquentent 
pratiquement pas cette liste, vous ne devriez pas prendre pour acquis 
que vous représentez cette communauté et pouvez démarrer des projets 
en son nom.



Pierre


Le vendredi 18 janvier 2019 13 h 11 min 37 s HNE, john whelan 
 a écrit :



I know of no other way to contact him but he made an interesting 
comment that the project is on hold in the wiki pending review.


Would he care to comment on who is supposed to be reviewing the project?

My understanding is that the import was raised in talk-ca before it 
commenced for comment and these were generally favourable.  I took 
that as the local mappers to Canada had been consulted and they are 
the "local mappers" authority in this case.


I understand he has concerns about local mappers making decisions but 
in Canada we have been importing similar data through CANVEC for some 
time.  CANVEC data comes from a number of sources including municipal 
data.


Is he suggesting that each of the 3,700 municipalities in Canada 
should form a group of local mappers who can make individual decisions 
on whether their municipal data should be imported and we should end 
up with 3,700 import plans?


Thanks John


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


--
Sent from Postbox 

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

Re: [OSM-talk] OpenStreetMap Carto release v4.19.0

2019-01-18 Thread Doug Hembry

This is great news! "The Map" continues to get even better, and the 
protected_area rendering is especially welcome. Thanks to Daniel and the 
whole team!

- Doug Hembry

On 1/18/2019 3:59 AM, Daniel Koć wrote:
> Dear all,
>
> Today, v4.19.0 of the OpenStreetMap Carto stylesheet (the default
> stylesheet on the OSM website) has been released. Once changes are
> deployed on the openstreetmap.org it will take couple of days before
> all tiles show the new rendering.
>
> Changes include
> - Adding rendering for boundary=protected_area (#3509)
> - Nature reserve boundaries revision (#3574)
> - Adding support of amenity=vending_machine (#3601)
> - Adding more barrier icons (#3602)
> - Changing allotments color and adding outline (#3625)
> - Reducing priority of tourism=attraction and rendering from z17 (#3603)
> - Changing tourism outline color (#3582)
> - Making country borders thicker at z8 and z9 (#3563)
> - Rendering parking from z14 (#3612)
> - Starting to render most patterns at z13 instead of z14 (#3610)
> - Changing zoom level and text size for place=hamlet (#3626)
> - Rendering airport gate refs black instead of purple (#3620)
> - Updating zoom levels by height for masts, towers and telescopes (#3536)
> - Hiding underground parking (#3600)
> - Rendering ref of minor roads more than once (#3627)
> - Adjusting width of highway=construction (#3580)
> - Selecting only motorway_link to tertiary_link as link (#3567)
> - Reducing tertiary-link width (#3570)
> - Changing certain amenity icons to grey (#3586)
> - Converting springs to use ST_PointOnSurface and reformatting SQL (#3233)
> - Adding "religious-icon" as color variable for #00 (#3642)
> - Adding "barrier-icon" color variable in #3f3f3f for barriers (#3643)
> - Fixing inconsistency of leisure=ice_rink (#3598)
> - Fixing label opacity for tourism features (#3616)
> - Reverting lowzoom nobuilding test change (#3622)
> - Removing trailing whitespace (#3637)
>
> Thanks to all the contributors for this release.
>
> For a full list of commits, see
> https://github.com/gravitystorm/openstreetmap-carto/compare/v4.18.0...v4.19.0
>
> As always, we welcome any bug reports at
> https://github.com/gravitystorm/openstreetmap-carto/issues
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [talk-cz] přihláška do spolku v6

On Fri, Jan 18, 2019, 17:13 Tomas Novotny  Ahoj,
>
> On Fri, 18 Jan 2019 16:29:38 +0100
> gorn  wrote:
>
> [...]
>
> > 2. Členský příspěvek 100 Kč zašlete na transparentní účet spolku s
> > textem transakce ve tvaru  „  – členský příspěvek za rok
> > “.
>
> ja uz poslal $$$ pred resenim prihlasky a to ve formatu, ktery posilal Tom
> Kasparek, tedy:
> clensky prispevek 2019 - JMENO PRIJMENI (OSM NICK)
>

Ahoj,

nevim co je to za diverzni akci, ze Jakub v kazdem mailu meni text pro
poslani prispevku, ale moc vas prosim, pouzijte format co jsem psal. Ja to
pak s ucetni budu davat dohromady, tak mi pomuze, kdyz to nebude pokazde
jinak.

Dekuji tom.k

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

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread Pierre Béland

John,
Il y a local et local. Compte-tenu des différences culturelles Québec vs Canada 
en général et que les contributeurs du Québec ne fréquentent pratiquement pas 
cette liste, vous ne devriez pas prendre pour acquis que vous représentez cette 
communauté et pouvez démarrer des projets en son nom.
 
Pierre 
 

Le vendredi 18 janvier 2019 13 h 11 min 37 s HNE, john whelan 
 a écrit :  
 
 I know of no other way to contact him but he made an interesting comment that 
the project is on hold in the wiki pending review.
Would he care to comment on who is supposed to be reviewing the project?
My understanding is that the import was raised in talk-ca before it commenced 
for comment and these were generally favourable.  I took that as the local 
mappers to Canada had been consulted and they are the "local mappers" authority 
in this case.
I understand he has concerns about local mappers making decisions but in Canada 
we have been importing similar data through CANVEC for some time.  CANVEC data 
comes from a number of sources including municipal data.
Is he suggesting that each of the 3,700 municipalities in Canada should form a 
group of local mappers who can make individual decisions on whether their 
municipal data should be imported and we should end up with 3,700 import plans?
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] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread John Marshall

I found the building footprints to be very good. JOSM cleaned up most of
the errors..I'm not sure it would be worth the risk to do more processing.
Sometimes there were crossing ways, usually with  terrace or buildings in
the downtown core that need to be fixed manually. Which took a ton of time.
I always removed all the errors from import buildings before I added the
OSM data.

 I also keeped the city name on the imported data so I could tell which was
the imported data/ OSM data. I removed the city name later before
uploading. If there was already a building in OSM, I used the "Replace
Geometry" unless the building in OSM was better. Sometimes , the local
mapper had done a better job than the city, so I just left it.The building
in the Niagara Region had tons of very good buildings that I just left.

I also tired to fixed other JOSM errors, Like adding road names, missing
tags, spelling error, natural=land ect.  Using Geo Base I added about 300
names to roads mostly around  Muskoka and Goderich. This usually took more
time than adding the buildings.

I would say adding buildings in rural, residential, & Industrial areas
there is low risk for problems. The downtown areas even in small
cities Port Colborne were very time consuming and require an experienced
mapper.. Personally I wouldn't even want to try downtown Toronto.

FYI,  The top 3 CDN OSM mappers are importing the building data.
http://osmstats.neis-one.org/?item=countries=Canada

Cheers

John

On Fri, Jan 18, 2019 at 5:30 PM James  wrote:

> You guys can analyze the simplified version of ontario:
>
> https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
> If you think it's good, I can simplify the other files and process them
> into mbtiles.
> ___
> 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] 2020 building import wiki comment by Nate Wessel

You guys can analyze the simplified version of ontario:
https://drive.google.com/file/d/1OK83yrPwMW4nefyu-6JsIInu0meK2rW6/view?usp=sharing
If you think it's good, I can simplify the other files and process them
into mbtiles.
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-ja] 朗報(Re: JOSM14620 日本語設定への韓国語混入について)

2019-01-18 Thread Hokko-sha

北光社（Hokkosha）です。
JOSM14703で、こちらも問題の解消が確認できました。
ご対応くださった皆様、ありがとうございます。

2019年1月18日(金) 12:07 石野貴之 :
>
> 石野@yumean1119です。
> 本日、josmの開発版バージョン14703をダウンロードしたところ、
> 日本語メニューに韓国語が混入する問題が解決していることが分かりました。
>
> 協力していただいた皆様に深く感謝を申し上げます。
>
> 石野 貴之
> yumean1...@gmail.com
>
>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

[talk-cz] Praha zveřejňuje otevřená data o parkování v ulicích města

2019-01-18 Thread Michal Poupa

Praha zveřejňuje otevřená data o parkování v ulicích města
https://www.lupa.cz/aktuality/praha-zverejnuje-otevrena-data-o-parkovani-v-ulicich-mesta/
Odesláno z iPadu___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread Yaro Shkvorets

I'm on board with removing redundant nodes, as long as it doesn't affect
actual geometries much.
Also there are quite a few duplicated nodes in buildings. They can be
removed in JOSM in one click before upload but better to do it at the
source.

On Fri, Jan 18, 2019 at 4:25 PM James  wrote:

> I can run all the shapefiles through qgis simplify tool if this resolves
> the issue...
>
> On Fri., Jan. 18, 2019, 4:08 p.m. Nate Wessel 
>> With default settings in JOSM, sure. In the import I was working on, we
>> used a Douglas-Peucker algorithm with a 20cm threshold (before the import
>> started) and it worked beautifully. We had many points that seemed to have
>> been introduced in the shapefiles as some kind of data artifact - they
>> didn't add any detail to the shape at all. This procedure removed almost
>> all of them with no discernible reduction in quality.
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/18/19 4:03 PM, James wrote:
>>
>> dare you to run simplify tool on anything remotely round, it will make it
>> look like garbage
>>
>> On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan > wrote:
>>
>>> The import mailing list was pointed to the correct page of the wiki.
>>> The initial post was to say this is what we were thinking of and there was
>>> a comment saying we needed to change the comment line.
>>>
>>> >There is no mention of this proposed import on the import catalogue
>>>
>>>
>>> The import process was reviewed by the person who set up the Ottawa
>>> import did we miss that step on the Ottawa import as well?  Neither was it
>>> raised as a concern on the import mailing list. I think this is very minor
>>> and can be corrected.
>>>
>>> We learnt a fair bit on the Ottawa import and my expectation is since we
>>> are using experienced mappers to do the import conflation would be either
>>> handled by them or the building not imported. We aren't using new mappers
>>> in a mapathon here and with experienced mappers then I think you have to
>>> trust them.  The world isn't perfect. Think in terms of service level.
>>>
>>> >There are 2X more nodes than needed to represent the building
>>> accurately.
>>>
>>> The problem with correcting this is you are introducing approximations.
>>> This will vary according to the source and this can be simplified or
>>> corrected once its in OSM. I think this is a different issue of a
>>> mechanical edit that needs to be considered separately.
>>>
>>> If we are concerned with database size then I suggest we change the
>>> instructions to say put the source comment on the change set rather than on
>>> the building outline.
>>>
>>> Cheerio John
>>>
>>>
>>> Nate Wessel wrote on 2019-01-18 3:06 PM:
>>>
>>> John,
>>>
>>> You seem to be playing the long game with this data - it sounds like
>>> you've been working with this a lot longer than I have, and you've put in
>>> the time and effort to help make this actually-quite-incredible dataset
>>> available to us. I don't want to stop the import from happening - quite the
>>> opposite. I just want to make sure that the time is taken to do this right.
>>> OSM deserves that. Your (our) long awaited victory will be the sweeter for
>>> our patience now.
>>>
>>> There are several specific issues I see where the I's are not crossed,
>>> nor the t's dotted. I've mentioned several already, so I'll try to be brief
>>> (I really need to get back to working on my dissertation).
>>>
>>> 1) There was extremely limited discussion on the imports mailing list.
>>> The initial email did not make clear the scope of the project. I read the
>>> email and did not think twice at it, thinking it was entirely about Ottawa.
>>> The link in that email was actually to the Ottawa import, and not this one,
>>> which seems to have been only in draft at the time.
>>> https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
>>> As such, this project has NOT been reviewed by the imports list, which
>>> is a requirement for proceeding with the import.
>>>
>>> 2) There is no mention of this proposed import on the import catalogue (
>>> https://wiki.openstreetmap.org/wiki/Import/Catalogue)
>>> which is required in the imports guidelines. I suspect many other
>>> guidelines have not been followed.
>>>
>>> 3) The wiki page describing the import is not adequate to assess the
>>> quality of the data or of the proposed import. See for example:
>>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
>>> The import guidelines call for a description of how conflation will be
>>> handled. The fact that two of the major importers seem to have a
>>> substantial disagreement about how to handle existing data indicates this
>>> was not well discussed and I can see that it isn't well documented.
>>>
>>> 4) The buildings need to be simplified, quite a bit actually. Most
>>> buildings have multiple nodes

Re: [talk-au] Announcing: OpenStreetCam competition

2019-01-18 Thread Martijn van Exel

Hi all, 

I am not sure if user robbie-blogs is reading on this list -- if you are, 
please get in touch to get your gift card.

For all others, the competition is still ongoing and you have until Jan 31 to 
make your way into the top 3 contributors over the months of December 2018 and 
January 2019 and win a $25 or $100 gift card.

Some stats so far: we started at 126 752 images in Australia on Dec 1, now we 
are at 330 648 covering 8882 km of which 6293 unique.

Happy mapping / capturing :)
--
 Martijn van Exel
 m...@rtijn.org


On Tue, Jan 8, 2019, at 16:40, Martijn van Exel wrote:
> Hi all,
> 
> We have the results for the most prolific OpenStreetCam contributors for 
> Australia for the period Dec 1 - Dec 24:
> 
> 
> #1 ---> robbie-bloggs with 127971 points
> #2 ---> steve91 with 65470 points
> 
> 
> Congratulations to you both, you have just won yourselves an $25 Amazon gift 
> card! Please get in touch with me so I can arrange (virtual) delivery.
> 
> It's not over yet though. This was just the holiday mid point of the 
> competition. At the end of January there will be three more prizes ($100 / 
> $25 / $25) for the overall top contributors for the months of December and 
> January.
> 
> If you haven't started capturing yet, no worries. New, not yet covered roads 
> get you 10x points. That adds up pretty quickly. For example, this 20km trip 
> is worth more than 6000 points: 
> https://openstreetcam.org/details/1318295/0/track-info 
> 
> Best,
> --
>  Martijn van Exel
>  m...@rtijn.org
> 
> 
> 
> On Wed, Dec 12, 2018, at 12:33, Martijn van Exel wrote:
>> Folks,
>> 
>> We added an additional holiday prize for the 2 mappers who collect the most 
>> imagery before Christmas.
>> Details added on the competition page! You need 25k points minimum to be 
>> eligible for this prize, but since coverage is very low in Australia, you 
>> collect points very quickly.
>> 
>> Let me know if you have any questions. Happy mapping / capturing,
>> --
>>  Martijn van Exel
>>  m...@rtijn.org
>> 
>> 
>> 
>> On Fri, Dec 7, 2018, at 11:53, Martijn van Exel wrote:
>>> Hi folks, 
>>> 
>>> We (Telenav map team) are holding an OpenStreetCam image capture 
>>> competition. In case you're not familiar, OpenStreetCam is an open source / 
>>> open data street level imagery collection platform for OSM. It is widely 
>>> used to help improve OSM (through iD and JOSM) but there is not a lot of 
>>> coverage in Australia yet. So with this competition we’re hoping to start 
>>> to change that. 
>>> 
>>> More details here: 
>>> https://github.com/openstreetcam/competitions/wiki/Australia-Competition-Dec-2018
>>>  
>>> 
>>> The TL;DR is: collect as many OSC images as you can between now and Jan 31, 
>>> the top 3 contributors get $100 / $25 Amazon gift cards!
>>> 
>>> Happy mapping / capturing!
>>> Martijn
>>> 
>>> PS in case you’re in NZ, we have a separate competition staring there as 
>>> well, 
>>> https://github.com/openstreetcam/competitions/wiki/New-Zealand-Competition-Dec-2018
>>>  
>>> _
>>> Talk-au mailing list
>>> Talk-au@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-au
>> 
>> ___
>> Talk-au mailing list
>> Talk-au@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-au
>> 
> 
> ___
> Talk-au mailing list
> Talk-au@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-au
> 
___
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

I can run all the shapefiles through qgis simplify tool if this resolves
the issue...

On Fri., Jan. 18, 2019, 4:08 p.m. Nate Wessel  With default settings in JOSM, sure. In the import I was working on, we
> used a Douglas-Peucker algorithm with a 20cm threshold (before the import
> started) and it worked beautifully. We had many points that seemed to have
> been introduced in the shapefiles as some kind of data artifact - they
> didn't add any detail to the shape at all. This procedure removed almost
> all of them with no discernible reduction in quality.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/18/19 4:03 PM, James wrote:
>
> dare you to run simplify tool on anything remotely round, it will make it
> look like garbage
>
> On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  wrote:
>
>> The import mailing list was pointed to the correct page of the wiki.  The
>> initial post was to say this is what we were thinking of and there was a
>> comment saying we needed to change the comment line.
>>
>> >There is no mention of this proposed import on the import catalogue
>>
>>
>> The import process was reviewed by the person who set up the Ottawa
>> import did we miss that step on the Ottawa import as well?  Neither was it
>> raised as a concern on the import mailing list. I think this is very minor
>> and can be corrected.
>>
>> We learnt a fair bit on the Ottawa import and my expectation is since we
>> are using experienced mappers to do the import conflation would be either
>> handled by them or the building not imported. We aren't using new mappers
>> in a mapathon here and with experienced mappers then I think you have to
>> trust them.  The world isn't perfect. Think in terms of service level.
>>
>> >There are 2X more nodes than needed to represent the building accurately.
>>
>> The problem with correcting this is you are introducing approximations.
>> This will vary according to the source and this can be simplified or
>> corrected once its in OSM. I think this is a different issue of a
>> mechanical edit that needs to be considered separately.
>>
>> If we are concerned with database size then I suggest we change the
>> instructions to say put the source comment on the change set rather than on
>> the building outline.
>>
>> Cheerio John
>>
>>
>> Nate Wessel wrote on 2019-01-18 3:06 PM:
>>
>> John,
>>
>> You seem to be playing the long game with this data - it sounds like
>> you've been working with this a lot longer than I have, and you've put in
>> the time and effort to help make this actually-quite-incredible dataset
>> available to us. I don't want to stop the import from happening - quite the
>> opposite. I just want to make sure that the time is taken to do this right.
>> OSM deserves that. Your (our) long awaited victory will be the sweeter for
>> our patience now.
>>
>> There are several specific issues I see where the I's are not crossed,
>> nor the t's dotted. I've mentioned several already, so I'll try to be brief
>> (I really need to get back to working on my dissertation).
>>
>> 1) There was extremely limited discussion on the imports mailing list.
>> The initial email did not make clear the scope of the project. I read the
>> email and did not think twice at it, thinking it was entirely about Ottawa.
>> The link in that email was actually to the Ottawa import, and not this one,
>> which seems to have been only in draft at the time.
>> https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
>> As such, this project has NOT been reviewed by the imports list, which is
>> a requirement for proceeding with the import.
>>
>> 2) There is no mention of this proposed import on the import catalogue (
>> https://wiki.openstreetmap.org/wiki/Import/Catalogue)
>> which is required in the imports guidelines. I suspect many other
>> guidelines have not been followed.
>>
>> 3) The wiki page describing the import is not adequate to assess the
>> quality of the data or of the proposed import. See for example:
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
>> The import guidelines call for a description of how conflation will be
>> handled. The fact that two of the major importers seem to have a
>> substantial disagreement about how to handle existing data indicates this
>> was not well discussed and I can see that it isn't well documented.
>>
>> 4) The buildings need to be simplified, quite a bit actually. Most
>> buildings have multiple nodes representing straight lines. This bloats the
>> database and makes things harder to edit by hand later. There are probably
>> 2x more nodes than are needed to represent the data accurately, making it
>> harder for editors and data consumers to work with down the road.This is a
>> simple fix that will save countless hours later.
>>
>> ... I could go on, but I think this is plenty sufficient to

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

With default settings in JOSM, sure. In the import I was working on, we 
used a Douglas-Peucker algorithm with a 20cm threshold (before the 
import started) and it worked beautifully. We had many points that 
seemed to have been introduced in the shapefiles as some kind of data 
artifact - they didn't add any detail to the shape at all. This 
procedure removed almost all of them with no discernible reduction in 
quality.

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 4:03 PM, James wrote:
dare you to run simplify tool on anything remotely round, it will make 
it look like garbage

On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  wrote:

The import mailing list was pointed to the correct page of the
wiki. The initial post was to say this is what we were thinking of
and there was a comment saying we needed to change the comment line.

>There is no mention of this proposed import on the import catalogue

The import process was reviewed by the person who set up the
Ottawa import did we miss that step on the Ottawa import as well? 
Neither was it raised as a concern on the import mailing list. I
think this is very minor and can be corrected.

We learnt a fair bit on the Ottawa import and my expectation is
since we are using experienced mappers to do the import conflation
would be either handled by them or the building not imported. We
aren't using new mappers in a mapathon here and with experienced
mappers then I think you have to trust them.  The world isn't
perfect. Think in terms of service level.

>There are 2X more nodes than needed to represent the building
accurately.

The problem with correcting this is you are introducing
approximations.  This will vary according to the source and this
can be simplified or corrected once its in OSM. I think this is a
different issue of a mechanical edit that needs to be considered
separately.

If we are concerned with database size then I suggest we change
the instructions to say put the source comment on the change set
rather than on the building outline.

Cheerio John

Nate Wessel wrote on 2019-01-18 3:06 PM:

John,

You seem to be playing the long game with this data - it sounds
like you've been working with this a lot longer than I have, and
you've put in the time and effort to help make this
actually-quite-incredible dataset available to us. I don't want
to stop the import from happening - quite the opposite. I just
want to make sure that the time is taken to do this right. OSM
deserves that. Your (our) long awaited victory will be the
sweeter for our patience now.

There are several specific issues I see where the I's are not
crossed, nor the t's dotted. I've mentioned several already, so
I'll try to be brief (I really need to get back to working on my
dissertation).

1) There was extremely limited discussion on the imports mailing
list. The initial email did not make clear the scope of the
project. I read the email and did not think twice at it, thinking
it was entirely about Ottawa. The link in that email was actually
to the Ottawa import, and not this one, which seems to have been
only in draft at the time.
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list,
which is a requirement for proceeding with the import.

2) There is no mention of this proposed import on the import
catalogue (https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other
guidelines have not been followed.

3) The wiki page describing the import is not adequate to assess
the quality of the data or of the proposed import. See for
example:

https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
The import guidelines call for a description of how conflation
will be handled. The fact that two of the major importers seem to
have a substantial disagreement about how to handle existing data
indicates this was not well discussed and I can see that it isn't
well documented.

4) The buildings need to be simplified, quite a bit actually.
Most buildings have multiple nodes representing straight lines.
This bloats the database and makes things harder to edit by hand
later. There are probably 2x more nodes than are needed to
represent the data accurately, making it harder for editors and
data consumers to work with down the road.This is a simple fix
that will save countless hours later.

... I could go on, but I think this is plenty sufficient to
justify pressing pause on all this.

Again, I don't in

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread John Whelan

James you know I could never resist a dare!

Cheerio John

James wrote on 2019-01-18 4:03 PM:
dare you to run simplify tool on anything remotely round, it will make 
it look like garbage

On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  wrote:

The import mailing list was pointed to the correct page of the
wiki.  The initial post was to say this is what we were thinking
of and there was a comment saying we needed to change the comment
line.

>There is no mention of this proposed import on the import catalogue

The import process was reviewed by the person who set up the
Ottawa import did we miss that step on the Ottawa import as well? 
Neither was it raised as a concern on the import mailing list. I
think this is very minor and can be corrected.

We learnt a fair bit on the Ottawa import and my expectation is
since we are using experienced mappers to do the import conflation
would be either handled by them or the building not imported. We
aren't using new mappers in a mapathon here and with experienced
mappers then I think you have to trust them.  The world isn't
perfect. Think in terms of service level.

>There are 2X more nodes than needed to represent the building
accurately.

The problem with correcting this is you are introducing
approximations. This will vary according to the source and this
can be simplified or corrected once its in OSM. I think this is a
different issue of a mechanical edit that needs to be considered
separately.

If we are concerned with database size then I suggest we change
the instructions to say put the source comment on the change set
rather than on the building outline.

Cheerio John

Nate Wessel wrote on 2019-01-18 3:06 PM:

John,

You seem to be playing the long game with this data - it sounds
like you've been working with this a lot longer than I have, and
you've put in the time and effort to help make this
actually-quite-incredible dataset available to us. I don't want
to stop the import from happening - quite the opposite. I just
want to make sure that the time is taken to do this right. OSM
deserves that. Your (our) long awaited victory will be the
sweeter for our patience now.

There are several specific issues I see where the I's are not
crossed, nor the t's dotted. I've mentioned several already, so
I'll try to be brief (I really need to get back to working on my
dissertation).

1) There was extremely limited discussion on the imports mailing
list. The initial email did not make clear the scope of the
project. I read the email and did not think twice at it, thinking
it was entirely about Ottawa. The link in that email was actually
to the Ottawa import, and not this one, which seems to have been
only in draft at the time.
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list,
which is a requirement for proceeding with the import.

2) There is no mention of this proposed import on the import
catalogue (https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other
guidelines have not been followed.

3) The wiki page describing the import is not adequate to assess
the quality of the data or of the proposed import. See for
example:

https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
The import guidelines call for a description of how conflation
will be handled. The fact that two of the major importers seem to
have a substantial disagreement about how to handle existing data
indicates this was not well discussed and I can see that it isn't
well documented.

4) The buildings need to be simplified, quite a bit actually.
Most buildings have multiple nodes representing straight lines.
This bloats the database and makes things harder to edit by hand
later. There are probably 2x more nodes than are needed to
represent the data accurately, making it harder for editors and
data consumers to work with down the road.This is a simple fix
that will save countless hours later.

... I could go on, but I think this is plenty sufficient to
justify pressing pause on all this.

Again, I don't in any way want to disrespect the work that has
gone into this effort already. We're all volunteers here and I
know how much time this all takes. However. importing all/most of
the buildings in Canada is a monstrously large task, which will
have to dance around a lot of people's toes. We should expect
this to take a really damn long time if we're going to do it
right. We need to have the patience to learn from experience,
from critique, and from the wisdom

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

dare you to run simplify tool on anything remotely round, it will make it
look like garbage

On Fri., Jan. 18, 2019, 3:49 p.m. John Whelan  The import mailing list was pointed to the correct page of the wiki.  The
> initial post was to say this is what we were thinking of and there was a
> comment saying we needed to change the comment line.
>
> >There is no mention of this proposed import on the import catalogue
>
>
> The import process was reviewed by the person who set up the Ottawa import
> did we miss that step on the Ottawa import as well?  Neither was it raised
> as a concern on the import mailing list. I think this is very minor and can
> be corrected.
>
> We learnt a fair bit on the Ottawa import and my expectation is since we
> are using experienced mappers to do the import conflation would be either
> handled by them or the building not imported. We aren't using new mappers
> in a mapathon here and with experienced mappers then I think you have to
> trust them.  The world isn't perfect. Think in terms of service level.
>
> >There are 2X more nodes than needed to represent the building accurately.
>
> The problem with correcting this is you are introducing approximations.
> This will vary according to the source and this can be simplified or
> corrected once its in OSM. I think this is a different issue of a
> mechanical edit that needs to be considered separately.
>
> If we are concerned with database size then I suggest we change the
> instructions to say put the source comment on the change set rather than on
> the building outline.
>
> Cheerio John
>
>
> Nate Wessel wrote on 2019-01-18 3:06 PM:
>
> John,
>
> You seem to be playing the long game with this data - it sounds like
> you've been working with this a lot longer than I have, and you've put in
> the time and effort to help make this actually-quite-incredible dataset
> available to us. I don't want to stop the import from happening - quite the
> opposite. I just want to make sure that the time is taken to do this right.
> OSM deserves that. Your (our) long awaited victory will be the sweeter for
> our patience now.
>
> There are several specific issues I see where the I's are not crossed, nor
> the t's dotted. I've mentioned several already, so I'll try to be brief (I
> really need to get back to working on my dissertation).
>
> 1) There was extremely limited discussion on the imports mailing list. The
> initial email did not make clear the scope of the project. I read the email
> and did not think twice at it, thinking it was entirely about Ottawa. The
> link in that email was actually to the Ottawa import, and not this one,
> which seems to have been only in draft at the time.
> https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
> As such, this project has NOT been reviewed by the imports list, which is
> a requirement for proceeding with the import.
>
> 2) There is no mention of this proposed import on the import catalogue (
> https://wiki.openstreetmap.org/wiki/Import/Catalogue)
> which is required in the imports guidelines. I suspect many other
> guidelines have not been followed.
>
> 3) The wiki page describing the import is not adequate to assess the
> quality of the data or of the proposed import. See for example:
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
> The import guidelines call for a description of how conflation will be
> handled. The fact that two of the major importers seem to have a
> substantial disagreement about how to handle existing data indicates this
> was not well discussed and I can see that it isn't well documented.
>
> 4) The buildings need to be simplified, quite a bit actually. Most
> buildings have multiple nodes representing straight lines. This bloats the
> database and makes things harder to edit by hand later. There are probably
> 2x more nodes than are needed to represent the data accurately, making it
> harder for editors and data consumers to work with down the road.This is a
> simple fix that will save countless hours later.
>
> ... I could go on, but I think this is plenty sufficient to justify
> pressing pause on all this.
>
> Again, I don't in any way want to disrespect the work that has gone into
> this effort already. We're all volunteers here and I know how much time
> this all takes. However. importing all/most of the buildings in Canada is a
> monstrously large task, which will have to dance around a lot of people's
> toes. We should expect this to take a really damn long time if we're going
> to do it right. We need to have the patience to learn from experience, from
> critique, and from the wisdom of the people who've learned from flawed
> imports in the past and have devised guidelines and processes so that we
> can have better experiences with this in the future.
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread John Whelan

The import mailing list was pointed to the correct page of the wiki.  
The initial post was to say this is what we were thinking of and there 
was a comment saying we needed to change the comment line.

>There is no mention of this proposed import on the import catalogue

The import process was reviewed by the person who set up the Ottawa 
import did we miss that step on the Ottawa import as well?  Neither was 
it raised as a concern on the import mailing list. I think this is very 
minor and can be corrected.

We learnt a fair bit on the Ottawa import and my expectation is since we 
are using experienced mappers to do the import conflation would be 
either handled by them or the building not imported. We aren't using new 
mappers in a mapathon here and with experienced mappers then I think you 
have to trust them.  The world isn't perfect. Think in terms of service 
level.

>There are 2X more nodes than needed to represent the building accurately.

The problem with correcting this is you are introducing approximations. 
This will vary according to the source and this can be simplified or 
corrected once its in OSM. I think this is a different issue of a 
mechanical edit that needs to be considered separately.

If we are concerned with database size then I suggest we change the 
instructions to say put the source comment on the change set rather than 
on the building outline.

Cheerio John

Nate Wessel wrote on 2019-01-18 3:06 PM:

John,

You seem to be playing the long game with this data - it sounds like 
you've been working with this a lot longer than I have, and you've put 
in the time and effort to help make this actually-quite-incredible 
dataset available to us. I don't want to stop the import from 
happening - quite the opposite. I just want to make sure that the time 
is taken to do this right. OSM deserves that. Your (our) long awaited 
victory will be the sweeter for our patience now.

There are several specific issues I see where the I's are not crossed, 
nor the t's dotted. I've mentioned several already, so I'll try to be 
brief (I really need to get back to working on my dissertation).

1) There was extremely limited discussion on the imports mailing list. 
The initial email did not make clear the scope of the project. I read 
the email and did not think twice at it, thinking it was entirely 
about Ottawa. The link in that email was actually to the Ottawa 
import, and not this one, which seems to have been only in draft at 
the time. 
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list, which 
is a requirement for proceeding with the import.

2) There is no mention of this proposed import on the import catalogue 
(https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other 
guidelines have not been followed.

3) The wiki page describing the import is not adequate to assess the 
quality of the data or of the proposed import. See for example: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
The import guidelines call for a description of how conflation will be 
handled. The fact that two of the major importers seem to have a 
substantial disagreement about how to handle existing data indicates 
this was not well discussed and I can see that it isn't well documented.

4) The buildings need to be simplified, quite a bit actually. Most 
buildings have multiple nodes representing straight lines. This bloats 
the database and makes things harder to edit by hand later. There are 
probably 2x more nodes than are needed to represent the data 
accurately, making it harder for editors and data consumers to work 
with down the road.This is a simple fix that will save countless hours 
later.

... I could go on, but I think this is plenty sufficient to justify 
pressing pause on all this.

Again, I don't in any way want to disrespect the work that has gone 
into this effort already. We're all volunteers here and I know how 
much time this all takes. However. importing all/most of the buildings 
in Canada is a monstrously large task, which will have to dance around 
a lot of people's toes. We should expect this to take a really damn 
long time if we're going to do it right. We need to have the patience 
to learn from experience, from critique, and from the wisdom of the 
people who've learned from flawed imports in the past and have devised 
guidelines and processes so that we can have better experiences with 
this in the future.

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:24 PM, john whelan wrote:
My background is I'm a retired civil servant who has written and 
overseen procurement documents and fairly large procurements. Dotting 
the is and crossing the Ts are my speciality.

There are

Re: [Talk-ca] [Imports] Ongoing Canadian building import needs to be stopped, possibly reverted

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

On Fri., Jan. 18, 2019, 3:02 p.m. Kevin Kenny  On Fri, Jan 18, 2019 at 2:54 PM Yaro Shkvorets 
> wrote:
> > JOSM offers very convenient way to do it called "Replace geometry".
> Select both ways, old and new, press Ctrl-Shift-G, merge any conflicting
> tags and you preserve the history, tags and have new improved outline in a
> couple of clicks.
>
> Good point. I use that a *lot* when updating the New York public land
> boundaries. Is it in a stock JOSM now? You used to have to install a
> plugin (with some uninformative name like 'Utilities') to get it. It's
> an absolute necessity for importers.
>
> ___
> Imports mailing list
> impo...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/imports
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel


John,

You seem to be playing the long game with this data - it sounds like 
you've been working with this a lot longer than I have, and you've put 
in the time and effort to help make this actually-quite-incredible 
dataset available to us. I don't want to stop the import from happening 
- quite the opposite. I just want to make sure that the time is taken to 
do this right. OSM deserves that. Your (our) long awaited victory will 
be the sweeter for our patience now.


There are several specific issues I see where the I's are not crossed, 
nor the t's dotted. I've mentioned several already, so I'll try to be 
brief (I really need to get back to working on my dissertation).


1) There was extremely limited discussion on the imports mailing list. 
The initial email did not make clear the scope of the project. I read 
the email and did not think twice at it, thinking it was entirely about 
Ottawa. The link in that email was actually to the Ottawa import, and 
not this one, which seems to have been only in draft at the time. 
https://lists.openstreetmap.org/pipermail/imports/2018-November/005812.html
As such, this project has NOT been reviewed by the imports list, which 
is a requirement for proceeding with the import.


2) There is no mention of this proposed import on the import catalogue 
(https://wiki.openstreetmap.org/wiki/Import/Catalogue)
which is required in the imports guidelines. I suspect many other 
guidelines have not been followed.


3) The wiki page describing the import is not adequate to assess the 
quality of the data or of the proposed import. See for example: 
https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan#Risks
The import guidelines call for a description of how conflation will be 
handled. The fact that two of the major importers seem to have a 
substantial disagreement about how to handle existing data indicates 
this was not well discussed and I can see that it isn't well documented.


4) The buildings need to be simplified, quite a bit actually. Most 
buildings have multiple nodes representing straight lines. This bloats 
the database and makes things harder to edit by hand later. There are 
probably 2x more nodes than are needed to represent the data accurately, 
making it harder for editors and data consumers to work with down the 
road.This is a simple fix that will save countless hours later.


... I could go on, but I think this is plenty sufficient to justify 
pressing pause on all this.


Again, I don't in any way want to disrespect the work that has gone into 
this effort already. We're all volunteers here and I know how much time 
this all takes. However. importing all/most of the buildings in Canada 
is a monstrously large task, which will have to dance around a lot of 
people's toes. We should expect this to take a really damn long time if 
we're going to do it right. We need to have the patience to learn from 
experience, from critique, and from the wisdom of the people who've 
learned from flawed imports in the past and have devised guidelines and 
processes so that we can have better experiences with this in the future.


Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 2:24 PM, john whelan wrote:
My background is I'm a retired civil servant who has written and 
overseen procurement documents and fairly large procurements. Dotting 
the is and crossing the Ts are my speciality.


There are two parts to an import.  The first part is the part played 
by the import mailing group.  They confine themselves to is the 
license correct and do you have a reasonable plan.  In this case the 
license is one of the few that has been confirmed by the Legal Working 
Group of OpenStreetMap and as such no questions were raised about it 
on the import mailing list.  We have methodology that has been used 
before successfully with the Ottawa building outline import. There 
were major discussions both on talk-ca and the import mailing group 
before that import took place and we took note of the issues raised 
and addressed them.  The licensing issue goes back about eight years 
to when I was talking to Federal Government Treasury Board and 
explaining their Open Data license did not align with OSM.  That is 
why their license is now known as 2.0.


The second part is the local group makes the decision to import they 
are the authority no one else.


Apparently you were not part of the talk-ca when the discussions took 
place which would have been the time and place to raise concerns.


When the Ottawa import was done there were one or two places where the 
existing buildings and the import overlapped.  In the instructions on 
the import there are instructions to cover this. Specifically there is 
a validation step.  I seem to recall the error rate was of the order 
of 1% and I expect this latest batch to be roughly the same.


If you can identify

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread john whelan

Could you update the wiki to include these instructions please.

Thanks John

On Fri, 18 Jan 2019 at 14:53, Yaro Shkvorets  wrote:

> John,
> >> Traditionally or the party line is if its been mapped already then to
> preserve the history you either leave it alone or manually correct it.
> Manually correcting it is very time consuming.  Often the decision is made
> to leave the existing way in the map.
>
> JOSM offers very convenient way to do it called "Replace geometry". Select
> both ways, old and new, press Ctrl-Shift-G, merge any conflicting tags and
> you preserve the history, tags and have new improved outline in a couple of
> clicks.
>
> On Fri, Jan 18, 2019 at 2:30 PM john whelan  wrote:
>
>> And that is a problem with imports.  Traditionally or the party line is
>> if its been mapped already then to preserve the history you either leave it
>> alone or manually correct it.  Manually correcting it is very time
>> consuming.  Often the decision is made to leave the existing way in the map.
>>
>> I'm not going to say one method is correct over the other but the least
>> contentious is to add only things are are not there already.
>>
>> Cheerio John
>>
>> On Fri, 18 Jan 2019 at 14:17, Yaro Shkvorets  wrote:
>>
>>> Nate,
>>> I'll change the project name to reflect that the import is on hold. As a
>>> local mapper, if you want to take a lead on the Toronto import that'd be
>>> great.
>>> I did review some of DannyMcD's edits last night
>>> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
>>> with the quality. It appears Danny chose to import only new buildings (i.e.
>>> residential homes mostly), leaving most of the existing hand-traced
>>> non-residential building outlines in OSM untouched. That's unfortunate, the
>>> dataset offers some really good data and leaving half of it behind makes it
>>> more difficult to revisit in the future.
>>> In my edits (Markham-Scarborough-East York) I was aiming to replace as
>>> many existing geometries with outlines from the import as possible. I think
>>> that's what we should be trying to do going forward.
>>> Looking forward to your comments and discussion.
>>>
>>>
>>>
>>> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>>>
 Hi all,

 I've just joined the talk-ca list, so please accept my apologies for
 not addressing this list earlier. I'm happy to take this thread off the
 imports list for now and onto talk-ca until things are ready to begin
 again. The next person to reply can please feel free to remove that email
 if they agree.

 I've just made a note on the draft import plan wiki page noting that
 the import has been stopped:

 https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

 I would really appreciate it if the person with admin access to the
 tasking manager projects could please take those offline for the moment, or
 perhaps place them in a validation-only mode if that's possible.

 Like I said in my last email, which perhaps didn't make it to the
 talk-ca list (
 https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
 I'm now proposing that we leave the data that has already been imported and
 enter a phase of thorough validation on that data.

 My plan, over the next several days, is to do a general survey of the
 quality of the data that has been imported so far and make a list of
 systematic issues I see that should be addressed before we can consider
 moving forward again. I'll add those comments to the conversation in
 talk-ca and on the wiki page (link above), as I feel is appropriate. As I
 said before, I'm of the mind that this import did not get adequate review
 or approval and did not follow all the import guidelines. I think therefore
 we need to take stock, cross the t's, dot the i's, and move this thing back
 toward where it needs to be. Step one is a thoroughly documented wiki page
 outlining the proposal and responding to everything required in the import
 guidelines.
 https://wiki.openstreetmap.org/wiki/Import/Guidelines

 I know there are people excited about this import, and people who are
 eager to get back to work bringing buildings in, but I think everyone will
 be happier in the end if we take the time to do this right. We don't need
 to stop forever - we just need to stop until we get things right. I
 sincerely respect the good intentions of everyone involved in this and I
 hope we can all work together to make OSM a map known for it's coverage AND
 it's quality.

 Best,
 Nate Wessel
 Jack of all trades, Master of Geography, PhD candidate in Urban Planning
 NateWessel.com 

 On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:

 The thread link is:

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread Yaro Shkvorets

Jarek,
There is no question we want this data. I went through much of it in
Toronto and Kingston and I found it to be very good, consistent and
precise. Time-wise it's somewhat current with 2016 ESRI imagery (sometimes
ahead, sometimes slightly behind) and is well-aligned with it. It offers 3D
features (when several buildings appear overlapped in the dataset) but you
just need to be familiar with `building:part` tag to sort through it. I
haven't looked at other provinces but in Ontario I really have no
complaints about dataset quality whatsoever. Also I don't get Nate's
"wildly unsimplified geometries" comment. IMO geometries are just perfectly
detailed.


On Fri, Jan 18, 2019 at 2:00 PM Jarek Piórkowski 
wrote:

> Some more thoughts from me.
>
> Building outlines, particularly for single-family subdivisions as seen
> in Canadian suburbs, are extremely labour-intensive to map manually.
>
> My parents' house is now on OSM - accurately. They live in a city with
> about 10,000 buildings, and about 0.5 active mappers. This wouldn't
> been completed manually in the next 5 years.
>
> An option to do this automatically with a computer algorithm detecting
> objects from imagery could be suggested, but this has not been very
> accurate in OSM in the past, even when there is decent imagery. The
> only other feasible data source is government, where they have such
> data more or less.
>
> The alternative is of course the opinion that we should not have
> building outlines until someone goes through and adds the buildings
> manually. In practice what I've seen done in Toronto is that bigger
> buildings are mapped on best-effort basis from survey and imagery,
> while areas of single-family houses are left blank. This isn't
> _wrong_, and maybe some prefer this.
>
> I would also like to note that building outlines will _never_ be
> completely verifiably up to date. I can't go into most people's
> backyards and verify that there isn't a new addition on their house. A
> building might be legally split into two different properties without
> it being evident from the street. Imagery is out of date the day after
> it's taken, and proper offset can be difficult to establish in big
> cities where GPS signal is erratic. Pragmatically, I can tell you from
> personal experience that building data in lovingly-mapped Berlin is
> also worse than 1 meter accuracy. So again: best effort.
>
> What do we get from having buildings? A sense of land use (arguably
> replaceable with larger landuse areas). A way to roughly estimate
> population density. A way to gauge built-up density. A data source for
> locating buildings in possible flood zones, or fire risk. Statistics:
> as open data, queryable by APIs that are already used, in format
> more-or-less common worldwide.
>
> Examples were given of rowhouse- or de-facto rowhouse-buildings where
> a part is attached to the wrong building. This does not alter any of
> the above examples. It's wrong, but is it substantially more wrong
> than a blank subdivision, or one with only a few buildings mapped? Is
> it better to have a null, or be off by 5%? The legal truth is in
> property records, and we can't measure houses with a ruler, so OSM can
> only be a statistical source. And then there's the question of
> verifiability - some of these buildings are connected to their
> neighbour building inside. I've really struggled at distinguishing
> what exactly is a "building" on Old Toronto avenues even with
> street-side survey.
>
> Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
> and I'm sure many of you do as well. If we import, the question is:
> are we making it better?
>
> 1. Do we want this data?
> 2. Is it generally of acceptable quality?
> 3. Is there a mechanism to spot and reject where data is particularly bad?
>
> Cheers,
> Jarek, who should really get back to updating built-last-year stuff at
> Fort York
>
> On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall 
> wrote:
> >
> > The pilot project that took place in Ottawa for all these building
> imports is what got me hooked into OSM in the first place. I would make
> only very minor changes here and there. I even attempted to draw building
> footprints but got burnt out after only doing a single street, which was
> very discouraging for me to continue.
> >
> > When I saw the entire neighbourhood get flooded with new buildings that
> weren't there before, I was entirely intrigued and actually got on board
> with the locals to help with the process. I've been hooked since and have
> been to many meetups afterwards. Helping out with projects completely
> unrelated to the initial building import.
> >
> > I'm entirely of the belief that it is much more encouraging for a new
> user to make a minor change (eg. changing `building=yes` to
> `building=detached`) than it is to add every single minor detail to each
> object from scratch (visiting the location, drawing the building footprints
> manually, adding address data, etc.). It's

[Talk-at] Heise: Unzulänglichkeiten bei der IP-Lokalisierung mit gravierenden Folgen

2019-01-18 Thread Rainer Fügenstein



https://www.heise.de/newsticker/meldung/Unzulaenglichkeiten-bei-der-IP-Lokalisierung-mit-gravierenden-Folgen-4281666.html


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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread john whelan

And that is a problem with imports.  Traditionally or the party line is if
its been mapped already then to preserve the history you either leave it
alone or manually correct it.  Manually correcting it is very time
consuming.  Often the decision is made to leave the existing way in the map.

I'm not going to say one method is correct over the other but the least
contentious is to add only things are are not there already.

Cheerio John

On Fri, 18 Jan 2019 at 14:17, Yaro Shkvorets  wrote:

> Nate,
> I'll change the project name to reflect that the import is on hold. As a
> local mapper, if you want to take a lead on the Toronto import that'd be
> great.
> I did review some of DannyMcD's edits last night
> (Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
> with the quality. It appears Danny chose to import only new buildings (i.e.
> residential homes mostly), leaving most of the existing hand-traced
> non-residential building outlines in OSM untouched. That's unfortunate, the
> dataset offers some really good data and leaving half of it behind makes it
> more difficult to revisit in the future.
> In my edits (Markham-Scarborough-East York) I was aiming to replace as
> many existing geometries with outlines from the import as possible. I think
> that's what we should be trying to do going forward.
> Looking forward to your comments and discussion.
>
>
>
> On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:
>
>> Hi all,
>>
>> I've just joined the talk-ca list, so please accept my apologies for not
>> addressing this list earlier. I'm happy to take this thread off the imports
>> list for now and onto talk-ca until things are ready to begin again. The
>> next person to reply can please feel free to remove that email if they
>> agree.
>>
>> I've just made a note on the draft import plan wiki page noting that the
>> import has been stopped:
>>
>>
>> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>>
>> I would really appreciate it if the person with admin access to the
>> tasking manager projects could please take those offline for the moment, or
>> perhaps place them in a validation-only mode if that's possible.
>>
>> Like I said in my last email, which perhaps didn't make it to the talk-ca
>> list (
>> https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
>> I'm now proposing that we leave the data that has already been imported and
>> enter a phase of thorough validation on that data.
>>
>> My plan, over the next several days, is to do a general survey of the
>> quality of the data that has been imported so far and make a list of
>> systematic issues I see that should be addressed before we can consider
>> moving forward again. I'll add those comments to the conversation in
>> talk-ca and on the wiki page (link above), as I feel is appropriate. As I
>> said before, I'm of the mind that this import did not get adequate review
>> or approval and did not follow all the import guidelines. I think therefore
>> we need to take stock, cross the t's, dot the i's, and move this thing back
>> toward where it needs to be. Step one is a thoroughly documented wiki page
>> outlining the proposal and responding to everything required in the import
>> guidelines.
>> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>>
>> I know there are people excited about this import, and people who are
>> eager to get back to work bringing buildings in, but I think everyone will
>> be happier in the end if we take the time to do this right. We don't need
>> to stop forever - we just need to stop until we get things right. I
>> sincerely respect the good intentions of everyone involved in this and I
>> hope we can all work together to make OSM a map known for it's coverage AND
>> it's quality.
>>
>> Best,
>> Nate Wessel
>> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
>> NateWessel.com 
>>
>> On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:
>>
>> The thread link is:  
>> https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html
>>
>> SteveA
>>
>>
>
> --
> Best Regards,
>   Yaro Shkvorets
> ___
> 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] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread Yaro Shkvorets

Nate,
I'll change the project name to reflect that the import is on hold. As a
local mapper, if you want to take a lead on the Toronto import that'd be
great.
I did review some of DannyMcD's edits last night
(Mississauga-Brampton-Vaughan) and to be honest was rather disappointed
with the quality. It appears Danny chose to import only new buildings (i.e.
residential homes mostly), leaving most of the existing hand-traced
non-residential building outlines in OSM untouched. That's unfortunate, the
dataset offers some really good data and leaving half of it behind makes it
more difficult to revisit in the future.
In my edits (Markham-Scarborough-East York) I was aiming to replace as many
existing geometries with outlines from the import as possible. I think
that's what we should be trying to do going forward.
Looking forward to your comments and discussion.



On Fri, Jan 18, 2019 at 1:07 PM Nate Wessel  wrote:

> Hi all,
>
> I've just joined the talk-ca list, so please accept my apologies for not
> addressing this list earlier. I'm happy to take this thread off the imports
> list for now and onto talk-ca until things are ready to begin again. The
> next person to reply can please feel free to remove that email if they
> agree.
>
> I've just made a note on the draft import plan wiki page noting that the
> import has been stopped:
>
>
> https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan
>
> I would really appreciate it if the person with admin access to the
> tasking manager projects could please take those offline for the moment, or
> perhaps place them in a validation-only mode if that's possible.
>
> Like I said in my last email, which perhaps didn't make it to the talk-ca
> list (
> https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html)
> I'm now proposing that we leave the data that has already been imported and
> enter a phase of thorough validation on that data.
>
> My plan, over the next several days, is to do a general survey of the
> quality of the data that has been imported so far and make a list of
> systematic issues I see that should be addressed before we can consider
> moving forward again. I'll add those comments to the conversation in
> talk-ca and on the wiki page (link above), as I feel is appropriate. As I
> said before, I'm of the mind that this import did not get adequate review
> or approval and did not follow all the import guidelines. I think therefore
> we need to take stock, cross the t's, dot the i's, and move this thing back
> toward where it needs to be. Step one is a thoroughly documented wiki page
> outlining the proposal and responding to everything required in the import
> guidelines.
> https://wiki.openstreetmap.org/wiki/Import/Guidelines
>
> I know there are people excited about this import, and people who are
> eager to get back to work bringing buildings in, but I think everyone will
> be happier in the end if we take the time to do this right. We don't need
> to stop forever - we just need to stop until we get things right. I
> sincerely respect the good intentions of everyone involved in this and I
> hope we can all work together to make OSM a map known for it's coverage AND
> it's quality.
>
> Best,
> Nate Wessel
> Jack of all trades, Master of Geography, PhD candidate in Urban Planning
> NateWessel.com 
>
> On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:
>
> The thread link is:  
> https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html
>
> SteveA
>
>

-- 
Best Regards,
  Yaro Shkvorets
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread Jarek Piórkowski

Some more thoughts from me.

Building outlines, particularly for single-family subdivisions as seen
in Canadian suburbs, are extremely labour-intensive to map manually.

My parents' house is now on OSM - accurately. They live in a city with
about 10,000 buildings, and about 0.5 active mappers. This wouldn't
been completed manually in the next 5 years.

An option to do this automatically with a computer algorithm detecting
objects from imagery could be suggested, but this has not been very
accurate in OSM in the past, even when there is decent imagery. The
only other feasible data source is government, where they have such
data more or less.

The alternative is of course the opinion that we should not have
building outlines until someone goes through and adds the buildings
manually. In practice what I've seen done in Toronto is that bigger
buildings are mapped on best-effort basis from survey and imagery,
while areas of single-family houses are left blank. This isn't
_wrong_, and maybe some prefer this.

I would also like to note that building outlines will _never_ be
completely verifiably up to date. I can't go into most people's
backyards and verify that there isn't a new addition on their house. A
building might be legally split into two different properties without
it being evident from the street. Imagery is out of date the day after
it's taken, and proper offset can be difficult to establish in big
cities where GPS signal is erratic. Pragmatically, I can tell you from
personal experience that building data in lovingly-mapped Berlin is
also worse than 1 meter accuracy. So again: best effort.

What do we get from having buildings? A sense of land use (arguably
replaceable with larger landuse areas). A way to roughly estimate
population density. A way to gauge built-up density. A data source for
locating buildings in possible flood zones, or fire risk. Statistics:
as open data, queryable by APIs that are already used, in format
more-or-less common worldwide.

Examples were given of rowhouse- or de-facto rowhouse-buildings where
a part is attached to the wrong building. This does not alter any of
the above examples. It's wrong, but is it substantially more wrong
than a blank subdivision, or one with only a few buildings mapped? Is
it better to have a null, or be off by 5%? The legal truth is in
property records, and we can't measure houses with a ruler, so OSM can
only be a statistical source. And then there's the question of
verifiability - some of these buildings are connected to their
neighbour building inside. I've really struggled at distinguishing
what exactly is a "building" on Old Toronto avenues even with
street-side survey.

Bluntly, OSM is not perfect in Canada. I have pet peeves I can quote,
and I'm sure many of you do as well. If we import, the question is:
are we making it better?

1. Do we want this data?
2. Is it generally of acceptable quality?
3. Is there a mechanism to spot and reject where data is particularly bad?

Cheers,
Jarek, who should really get back to updating built-last-year stuff at Fort York

On Fri, 18 Jan 2019 at 09:31, Kyle Nuttall  wrote:
>
> The pilot project that took place in Ottawa for all these building imports is 
> what got me hooked into OSM in the first place. I would make only very minor 
> changes here and there. I even attempted to draw building footprints but got 
> burnt out after only doing a single street, which was very discouraging for 
> me to continue.
>
> When I saw the entire neighbourhood get flooded with new buildings that 
> weren't there before, I was entirely intrigued and actually got on board with 
> the locals to help with the process. I've been hooked since and have been to 
> many meetups afterwards. Helping out with projects completely unrelated to 
> the initial building import.
>
> I'm entirely of the belief that it is much more encouraging for a new user to 
> make a minor change (eg. changing `building=yes` to `building=detached`) than 
> it is to add every single minor detail to each object from scratch (visiting 
> the location, drawing the building footprints manually, adding address data, 
> etc.). It's just overwhelming for a new user.
>
> It is very much a cat-and-mouse type scenario with community driven projects 
> like OSM. Apparently the issue with this import is the lack of community 
> involvement but I can for sure tell you that this import will help flourish 
> the community in the local areas. Especially if they only need to add or 
> change minor tags than if they would have had to create all of this data by 
> hand. With an import this size there is bound to be some errors that slip 
> through. That's where the community comes through to correct these minor 
> things.
>
> This is the whole point of OSM. A user creates an object with as much 
> information as they know and the next user comes and adds onto that, and the 
> next user adds and/or updates even more. Neither of those users on their own 
> could have

Re: [Talk-ca] 2020 building import wiki comment by Nate Wessel


Hi John,

As Steve has said, you seem to be the only one suggesting that thousands 
of import committees might need to be formed. Certainly I'm not 
suggesting that.


My understanding of OSM import procedure (and wiki-style projects more 
generally) is that imports should operate in an essentially consensual 
way where possible. The goal is to build consent and bring people on 
board with a project or a change by addressing their concerns in a 
meaningful and respectful way.


I think that I have made some substantive and troubling claims about the 
quality of the data being imported. I've pointed out that this project 
has not followed the import procedures that were produced by a community 
of mappers larger than just those in Canada.


So to respond to your implication, I am in some sense the one reviewing 
the project, just as I would welcome you to find ways that my own 
contributions could be better. If you want my credentials for reviewing 
your work, here they are:


1) I am an active contributor to OSM in Toronto, where I live (and 
elsewhere)


2) I am currently helping to lead a building import in Hamilton County 
Ohio that has better addressed some of the issues I see this import 
struggling with. I can help you do the same.


3) I've been doing research in GIS for a long time now, though I don't 
need that to tell you that the issues I've described are hardly 
insurmountable technically or even all that difficult to fix. It would 
take maybe one day's hard work to get the technical side of this right.


I think Canadian OSMers will agree that we can take a pause to get 
things right on such a massive import. If they don't - if I'm shouted 
down or better, if my critiques are adequately addressed, then I will 
leave you to finish the project in peace. I might even lend a hand if 
all goes well, as I sincerely hope it does :-)


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/18/19 1:11 PM, john whelan wrote:
I know of no other way to contact him but he made an interesting 
comment that the project is on hold in the wiki pending review.


Would he care to comment on who is supposed to be reviewing the project?

My understanding is that the import was raised in talk-ca before it 
commenced for comment and these were generally favourable. I took that 
as the local mappers to Canada had been consulted and they are the 
"local mappers" authority in this case.


I understand he has concerns about local mappers making decisions but 
in Canada we have been importing similar data through CANVEC for some 
time.  CANVEC data comes from a number of sources including municipal 
data.


Is he suggesting that each of the 3,700 municipalities in Canada 
should form a group of local mappers who can make individual decisions 
on whether their municipal data should be imported and we should end 
up with 3,700 import plans?


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

[Talk-ca] 2020 building import wiki comment by Nate Wessel

2019-01-18 Thread john whelan

I know of no other way to contact him but he made an interesting comment
that the project is on hold in the wiki pending review.

Would he care to comment on who is supposed to be reviewing the project?

My understanding is that the import was raised in talk-ca before it
commenced for comment and these were generally favourable.  I took that as
the local mappers to Canada had been consulted and they are the "local
mappers" authority in this case.

I understand he has concerns about local mappers making decisions but in
Canada we have been importing similar data through CANVEC for some time.
CANVEC data comes from a number of sources including municipal data.

Is he suggesting that each of the 3,700 municipalities in Canada should
form a group of local mappers who can make individual decisions on whether
their municipal data should be imported and we should end up with 3,700
import plans?

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted


Hi all,

I've just joined the talk-ca list, so please accept my apologies for not 
addressing this list earlier. I'm happy to take this thread off the 
imports list for now and onto talk-ca until things are ready to begin 
again. The next person to reply can please feel free to remove that 
email if they agree.


I've just made a note on the draft import plan wiki page noting that the 
import has been stopped:


https://wiki.openstreetmap.org/wiki/WikiProject_Canada/Canada_Stats_Canada_Building_Outlines_Import/Plan

I would really appreciate it if the person with admin access to the 
tasking manager projects could please take those offline for the moment, 
or perhaps place them in a validation-only mode if that's possible.


Like I said in my last email, which perhaps didn't make it to the 
talk-ca list 
(https://lists.openstreetmap.org/pipermail/imports/2019-January/005886.html) 
I'm now proposing that we leave the data that has already been imported 
and enter a phase of thorough validation on that data.


My plan, over the next several days, is to do a general survey of the 
quality of the data that has been imported so far and make a list of 
systematic issues I see that should be addressed before we can consider 
moving forward again. I'll add those comments to the conversation in 
talk-ca and on the wiki page (link above), as I feel is appropriate. As 
I said before, I'm of the mind that this import did not get adequate 
review or approval and did not follow all the import guidelines. I think 
therefore we need to take stock, cross the t's, dot the i's, and move 
this thing back toward where it needs to be. Step one is a thoroughly 
documented wiki page outlining the proposal and responding to everything 
required in the import guidelines.

https://wiki.openstreetmap.org/wiki/Import/Guidelines

I know there are people excited about this import, and people who are 
eager to get back to work bringing buildings in, but I think everyone 
will be happier in the end if we take the time to do this right. We 
don't need to stop forever - we just need to stop until we get things 
right. I sincerely respect the good intentions of everyone involved in 
this and I hope we can all work together to make OSM a map known for 
it's coverage AND it's quality.


Best,

Nate Wessel
Jack of all trades, Master of Geography, PhD candidate in Urban Planning
NateWessel.com 

On 1/17/19 9:05 PM, OSM Volunteer stevea wrote:

The thread link is:  
https://lists.openstreetmap.org/pipermail/imports/2019-January/005878.html

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

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

2019-01-18 Thread Jan Macura

Ahoj,

On Fri, 18 Jan 2019 at 14:03, majka  wrote:

> Jestli takových rozcestníků je víc, možná bych začala přidávat map=yes
> nebo guidepost:map=yes, a to zatím jen pro evidenci toho, kde se ty mapy
> vyskytují.
>

+1

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Ladislav Nesnera

"šarm T602" :D :D :D
Tak nevím, je-li to projevem hlubokých znalostí nebo naprosto
nesmazatelného rukopisu, ale dodavatelem pro Poštu je "Software602"..
Pokud potřebujete zvednout adrenalin balancujíc mezi smíchem a pláčem
doporučuji články od Peterky
.

Každopádně za OpenAlt i Otevřená města prohlašuji, že rozhodnutí pořídit
si DS bylo jedním z nejlepších rozhodnutí a participace na návodu
 je
vítána ;)

;?

PS: Jinak díky všem za příspěvky do tohoto vlákna. Dokonalá ukázka co
obnáší vypuštění do světa jednoho úředního papíru/procesu  O:-)

On 18/01/2019 15.10, majka wrote:
> On Fri, 18 Jan 2019 at 14:57, Jan Cibulka  > wrote:
>
> Když pominu, že to programovala pošta, takže to má UX zdechlý
> veverky a zprávy si z toho musíš zálohovat, protože za 3 měsíce po
> doručení zmizí...
>
> Nepomlouvej poštu - dokud běhal věstník veřejných zakázek, tedy jeho
> el. varianta pod poštou, mělo to sice šarm T602 (nebo psacího stroje
> pro ty, co tenhle program už nepamatují), ale fungovalo to bez větších
> problémů. Zeptej se někoho co je s tím za (cenzurováno) teď. Ti, co to
> neměli povinné od toho během pár měsíců utekli. Takže dřív bylo vše
> vypisované na jednom místě, a teď to hledáš i po úředních deskách obcí.
>
> Majka
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz



signature.asc
Description: OpenPGP digital signature
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

2019-01-18 Thread Tomas Novotny

Ahoj,

shrnuti:

On Fri, 18 Jan 2019 14:50:59 +0100
gorn  wrote:

> > Ahoj,
> >
> > narazil jsem na lyzarsky rozcestnik KCT, ktery ma v nazvu krome klasickych
> > "bus", "zst" atd. pismenko "P" v cernem poli. Asi pro parkoviste, viz:
> > https://osm.fit.vutbr.cz/fody/files/21727.jpg
> > Jak znacit v tagu name? Napr.
> > "name=Cihelna (P)" ?  
> 
> Poslední dobou se místo standardizovaných zkratek dávají ikony, které mají
> význam té zkratky. Tj napři místo "bus" se dá malý autobusek. Ačkoli UTF
> některé ty ikony má, značil bych to těmi původními zkratkami, které jsou
> standardizované. V tomto případě "park.", tj Cihelna (park.). Seznam
> zkratek je následující:
> 
> atc, bus, háj., host., hot., cz/xx, hs, jesk., kap., koup., lan.,
> mhd, mot., muz., mysl., nábř., nám., npp, npr, odb., pam.,
> park., pom., pp, pr, prm., příst., rekr. táb., rozc., rozhl.,
> ryb., sal., stud., táb., tur. ch., ubyt., vyhl., zám., zot., zříc.,
> žst

name="Cihelna (park.)"
 
> > Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
> > vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
> > znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
> > zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
> > "guidepost:ref=KK144" atd.  
> na tu mapku bych se vykašlal, nebo bych jí dal jako samostaný bod, je to
> stejný filozofický problém jak restaurace s hotelem.

tech rozcestniku bude tak 5-10, velmi hrubym odhadem jich je polovina mnou
navstivenych. Jak psala Majka, dam:
guidepost:map=yes

> > A tento rozcestnik ma jeste jednu zvlastnost: cca 50 metru od nej je
> > rozcestnik s nazvem "Cihelna", ale referencnim cislem "KK144A", takze
> > horni tabulka ma ref "KK144Am" atd. Videl jsem to u KCT poprve. Viz:
> > https://osm.fit.vutbr.cz/fody/files/21726.jpg  
> 
> Ano při krátkém souběhu  (zjednodušně dvě rozcestní blízko sebe) to KČT
> považuje za jeden TIM a má to jedno referenční číslo. Ono se to pak používá
> například tak, že na každém tom konci je jen ta "půlka" směrovek které tam
> jsou potřeba. Není to častý ale je to správně. Do OSM to dávám tak že tam
> dám REF které je na horní tabulce, tj. dal bych tam KK144A (m už je jen
> podznak tý směrvny).

jo, ta hodnota ref KK144A je jasna. Jen na klasickych turistickych jsem to
jeste nevidel. Jen na techto lyzarskych. V tom kraji jsem to ted jeste nasel
i tady:
https://osm.fit.vutbr.cz/fody/files/8764.jpg

> > Diky a mejte se,
> >
> > T.  
> 
> Víc jsem se v tom zabýval na State of Trails 2019, někde možná visí nějaké
> video.

jj, byl jsem primo tam ;-).

Diky vsem za odpovedi,

T.
 
> gorn
> 
> > ___
> > talk-cz mailing list
> > talk-cz@openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/talk-cz
> > https://openstreetmap.cz/talkcz  
> 

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

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Dalibor Jelínek

Čau,

verze 5-9 mi na Windows funguje.

Jen "souhlasím" je ukousnuté

a pole za "V" mi přijde krátké.

 

Dalibor

From: gorn [mailto:o...@kub.cz] 
Sent: Friday, January 18, 2019 4:35 PM
To: talk-cz@openstreetmap.org
Subject: Re: [talk-cz] přihláška do spolku OSM-CZ

 

Do nového threadu jsem poslal shrnutí všeho výše řečeného a v6 přihlášky se
zahrnutím všech připomínek. Cílím tím na lidi které nezajímá technologická
diskuze a prostě se chtějí přihlásit.

Ti co mají stále trpělivost na techologickou diskuzi poprosím o vyzkoušení
verze 5.9 která je spolu s ostatními ke stažení na odkaze
https://mrak.kub.cz/s/dmkk27Xqa8oF8Dd - podle mě by měla fungovat na většině
Maců a Win.

gorn

On 18. 01. 19 15:08, gorn wrote:

Jo přesně tohle jsem zjistil studiem dokumentace. Adobe všem nacpalo svůj
formát, ale že by se o to staralo to se nestará. Pokud bych vycházel čistě
ze specifikace tak nic jiného než ISO-8859-1 to nepodporuje a ani daleko
jednodušší věci, jako např. zarovnávání textu "dolů". 

Každopádně existujou nějaký rozšířený specifikace, který jsou spíš "de
fakto" než "de jure" a tam to zdá se vlastně funguje. Bohužel často až na
Linux :) kterej se chudák drží specifikací  a tím je bit.

Každopádně na základě feedbacku pošlu formulář kterej funguje většině lidí.
Stejně většina lidí nemá elektronické klíče apod a bude to tisknout a
posílat pošlou takže řešíme marginálie. Kdybychom to chtěli elektronicky,
tak to vyplňujeme na webu a rovnou pásujeme s osm účtem, ale holt musíme
nějak začít. Stay tuned :)

gorn

On 18. 01. 19 7:01, Karel Volný wrote:

čus,
 
tak naokraj ...
 

Myslím, že Windows za to můžou. Ani 23 let od unicode v 2.0 nebyl Microsoft
schopen unicode zavést a proto v roce 2019 Windows stále používají nějaká
obskurní kódování. ;-)

jak nemám Microsoft rád, tak tady se ho musím zastat, že veškerý problém s 
kódováním padá na Adobe, resp. autory PDF, a musím říct, že pro naše 
prostředí, tedy s diakritikou, jste formát zvolili nešťastně
 
pokud se nic zásadně nezměnilo od té doby, co jsem to před ~5 lety
zkoumal[*], 
tak PDF ve formulářích prostě nepodporuje to, co bychom potřebovali (tj. 
alespoň ISO-8859-2, když už ne nějakou formu Unincode)
 
pokud někomu ve formulářích funguje diakritika (nad rámec pár očárkovaných 
písmen), tak je to bug, ne featura, a rozhodně to není přenositelné, ani
když 
se vloží fonty
 
[*] teď koukám na Wiki, že 2017 vyšla verze 2.0, tj. změnit se mohlo mnohé -

hm, pokud to tato verze fixla, tak tedy good luck s podporou rok staré 
specifikace, když dodnes jedou některé stroje na Windows XP, a v KDEčkách 
(Okular ...) se sice polovina systému překopává co půl roku, ale spousta 
nevyřešených bugů a feature requestů visí už přes deset let
 
K.





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

-- 
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582





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

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

Re: [Talk-it] Aree di attesa, ammassamento e ricovero per piani di emergenza/protezione civile

2019-01-18 Thread Cascafico Giovanni

Avevo gli stessi dubbi al tempo del terremoto del Nepal.
Spontaneous camp è qualcosa di intrinsecamente temporaneo, ma nel caso OSM
è servito come supplente ad un sistema di condivisione delle informazioni
quasi in tempo reale.


Il ven 18 gen 2019, 16:11 mbranco2  ha scritto:

> Personalissima opinione:
> penserei che sia un tipo di informazione non per OSM ma per un GIS
> dedicato. Questo a meno che  l'area individuata non venga dotata di
> segnaletica permanente e perimetrata in modo evidente.
> Spero di poter essere corretto, perché l'importanza dell'informazione è
> indubbia, ed è un tipo di informazione che essendo utile a tutta la
> popolazione è importante che venga disseminata su più canali possibili.
>
>
>
> 
>  Mail
> priva di virus. www.avast.com
> 
> <#m_-1825199892519494799_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno ven 18 gen 2019 alle ore 06:39 Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> Buongiorno a tutti.
>>
>> Essendo entrato a far parte da poco del gruppo di volontari di Protezione
>> Civile del mio comune, volevo approfondire come poter usare OpenStreetMap
>> per aumentare le informazioni a disposizione dei cittadini usando appunto
>> OSM.
>>
>> In particolare, stavo ragionando su come le aree di attesa, ammassamento
>> e ricovero (vedi
>> http://www.protezionecivile.gov.it/jcms/it/glossario.wp?letter=A) siano
>> o possano essere mappate in OSM.
>>
>> Esistono linee guida generali al riguardo?
>>
>> Da una prima e rapida indagine, mi sembra che esista solamente il tag
>> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point, che
>> possa corrispondere appunto alle aree di attesa per la popolazione.
>>
>> Ho guardato anche nei present dei tag relativi a HOT (
>> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/HDM_preset) ma
>> non mi sembra abbiano questa prospettiva. Qui (
>> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#Emergency_Response_.26_Relief_Support_Infrastructure)
>> è citato ad esempio earthquake:damage=spontaneous_camp.
>>
>> Durante il terremoto del centro Italia le aree di ricovero erano state
>> mappate come tourism=camp_site refugee=yes (es.
>> https://www.openstreetmap.org/way/438746976).
>>
>> Tutte queste soluzioni però mi sembrano dei palliativi e poco specifiche.
>>
>> Se ci sono già invece informazioni che non ho trovato, sono interessato
>> ad approfondire.
>>
>> Se invece la situazione è questa, potrei provare a formulare un'ipotesi
>> di tagging e mappatura da discutere a livello italiano e poi eventualmente
>> proporre anche a scala internazionale (se c'è corrispondenza).
>>
>> Tutti i comuni di Italia dovrebbero avere un piano di emergenza che
>> individua queste tre tipologie di area e mi piacerebbe lanciare una
>> campagna di mappatura a partire dai piani di emergenza esistenti che copra
>> questa mancanza. Se troviamo una buona proposta mi piacerebbe farmene
>> portavoce a partire dal mio comune.
>>
>> Grazie per qualunque input,
>>
>> Ale
>>
>>
>> --
>> --
>>
>> Alessandro Sarretta
>>
>> skype/twitter: alesarrett
>> Web: ilsarrett.wordpress.com
>>
>> Research information:
>>
>>- Google scholar profile
>>
>>- ORCID 
>>- Research Gate
>>
>>- Impactstory 
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> 
>  Mail
> priva di virus. www.avast.com
> 
> <#m_-1825199892519494799_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Aree di attesa, ammassamento e ricovero per piani di emergenza/protezione civile

2019-01-18 Thread Paolo F

Sono i Comuni che devono provvedere alla localizzazione delle aree da
destinare alle varie necessità (sfollati, soccorritori, materiali) con i
Piani di Protezione Civile.
Le aree utilizzate non sempre sono o possono essere espressamente dedicate
a questo tipo di necessità. Generalmente vengono utilizzati spazi aperti,
lontano da edifici, come campi sportivi o piazze come primi luoghi di
ammassamento iniziale.
I Comuni che hanno realizzato questi piani generalmente rendono disponibili
tutte queste informazioni.
Il problema in OSM è che probabilmente mancano tags specifici per
differenziare le varie tipologie di aree.

Ciao, Paolo


On Fri, Jan 18, 2019, 16:11 mbranco2  Personalissima opinione:
> penserei che sia un tipo di informazione non per OSM ma per un GIS
> dedicato. Questo a meno che  l'area individuata non venga dotata di
> segnaletica permanente e perimetrata in modo evidente.
> Spero di poter essere corretto, perché l'importanza dell'informazione è
> indubbia, ed è un tipo di informazione che essendo utile a tutta la
> popolazione è importante che venga disseminata su più canali possibili.
>
>
>
> 
>  Mail
> priva di virus. www.avast.com
> 
> <#m_4604877912441887816_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> Il giorno ven 18 gen 2019 alle ore 06:39 Alessandro Sarretta <
> alessandro.sarre...@gmail.com> ha scritto:
>
>> Buongiorno a tutti.
>>
>> Essendo entrato a far parte da poco del gruppo di volontari di Protezione
>> Civile del mio comune, volevo approfondire come poter usare OpenStreetMap
>> per aumentare le informazioni a disposizione dei cittadini usando appunto
>> OSM.
>>
>> In particolare, stavo ragionando su come le aree di attesa, ammassamento
>> e ricovero (vedi
>> http://www.protezionecivile.gov.it/jcms/it/glossario.wp?letter=A) siano
>> o possano essere mappate in OSM.
>>
>> Esistono linee guida generali al riguardo?
>>
>> Da una prima e rapida indagine, mi sembra che esista solamente il tag
>> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point, che
>> possa corrispondere appunto alle aree di attesa per la popolazione.
>>
>> Ho guardato anche nei present dei tag relativi a HOT (
>> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/HDM_preset) ma
>> non mi sembra abbiano questa prospettiva. Qui (
>> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#Emergency_Response_.26_Relief_Support_Infrastructure)
>> è citato ad esempio earthquake:damage=spontaneous_camp.
>>
>> Durante il terremoto del centro Italia le aree di ricovero erano state
>> mappate come tourism=camp_site refugee=yes (es.
>> https://www.openstreetmap.org/way/438746976).
>>
>> Tutte queste soluzioni però mi sembrano dei palliativi e poco specifiche.
>>
>> Se ci sono già invece informazioni che non ho trovato, sono interessato
>> ad approfondire.
>>
>> Se invece la situazione è questa, potrei provare a formulare un'ipotesi
>> di tagging e mappatura da discutere a livello italiano e poi eventualmente
>> proporre anche a scala internazionale (se c'è corrispondenza).
>>
>> Tutti i comuni di Italia dovrebbero avere un piano di emergenza che
>> individua queste tre tipologie di area e mi piacerebbe lanciare una
>> campagna di mappatura a partire dai piani di emergenza esistenti che copra
>> questa mancanza. Se troviamo una buona proposta mi piacerebbe farmene
>> portavoce a partire dal mio comune.
>>
>> Grazie per qualunque input,
>>
>> Ale
>>
>>
>> --
>> --
>>
>> Alessandro Sarretta
>>
>> skype/twitter: alesarrett
>> Web: ilsarrett.wordpress.com
>>
>> Research information:
>>
>>- Google scholar profile
>>
>>- ORCID 
>>- Research Gate
>>
>>- Impactstory 
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
>
>
> 
>  Mail
> priva di virus. www.avast.com
> 
> <#m_4604877912441887816_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Jan Macura

On Fri, 18 Jan 2019 at 07:07, Karel Volný  wrote:

> > A jenom poznámka bokem: je vidět, že OSM dělají samý nerdi. Zajímalo by
> mě,
> > jestli v ČR existuje i jiný spolek, který u přihlášky vyžaduje otisk GPG
> > klíče.
>
> (již bylo řečeno, se slovem "vyžaduje" opatrně)
>

* tak tedy ... "umožňuje"... #sorryjako

H.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku v6

2019-01-18 Thread Tomas Novotny

Ahoj,

On Fri, 18 Jan 2019 16:29:38 +0100
gorn  wrote:

[...]

> 2. Členský příspěvek 100 Kč zašlete na transparentní účet spolku s
> textem transakce ve tvaru  „  – členský příspěvek za rok
> “.

ja uz poslal $$$ pred resenim prihlasky a to ve formatu, ktery posilal Tom
Kasparek, tedy:
clensky prispevek 2019 - JMENO PRIJMENI (OSM NICK)
tak snad v tom nebude moc chaos...

T.

[...]

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

Re: [talk-cz] přihláška do spolku OSM-CZ

S datovkou mám relativně zkušenosti a je to jeden z bodů, který chci v 
radě řešit, jakmile se stabilizuje nějaký základní stav. Jinak budem 
řešit všechno najednou :) Souhlasím s tím co píšeš. Je šílený UX ale 
pokud se nastaví rozumný workflow je to jistota. Mimochodem existuje 
velmi dobrá aplikace Datovka od nic.cz která je multiplatformní a UX má 
rozumný (v rámci omezení která jsou obsažena ve struktuře celého systému).



On 18. 01. 19 14:57, Jan Cibulka wrote:


Hele starosti s tim nejsou (mam datovku v ekospolku), prostě o ní 
statutár na poště/radnici požádá, za dva dny přijde login. Následně 
možno vytvářet další loginy, třeba jen pro čtení, dalším osobám.


Dobrý je, že pak už všechny subjekty veřejný správy musej komunikovat 
skrze ni (ty tu povinnost, s - co vim - výjimkou přiznání k dani), 
takže ti všechno chodí elektronicky, žádný cesty na poštu. A nehrozí 
ti, že mineš nějakej zásadní dopis od úřadu, kterej tě následně kvůli 
fikci doručení kousne do zadnice.


A naopak ty pak můžeš komunikovat s úřadama (třeba se soudem, kam se 
každoročně posílá zápis z hromady) z pohodlí domova, bez pošty a zadarmo.


Prostě win-win. Když pominu, že to programovala pošta, takže to má UX 
zdechlý veverky a zprávy si z toho musíš zálohovat, protože za 3 
měsíce po doručení zmizí...


On 18.01.2019 14:31, Marián Kyral wrote:
Jednak jako spolek datovou schránku nemáme povinnou, takže jsme v 
tomto směru zatím žádné kroky nepodnikali a taky si nejsem jist, 
kolik lidí datovou schránku má. Zda by to stálo za ty starosti ;-)


Marián

-- Původní e-mail --
Od: Jan Cibulka 
Komu: OpenStreetMap Czech Republic 
Datum: 18. 1. 2019 14:24:58
Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ


A bude mít spolek datovou schránku? Pokud ano, možno posílat
přihlášky tam (sice za peníze odesílatele, ale furt levnějc, než
doporučenym dopisem).

A teda tu DS by měl mít spolek tak jako tak, svěřit cokoli poště
je riskantní ;)

On 18.01.2019 11:57, Tom Ka wrote:

pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska  
  napsal:

možná trochu hloupá otázka, ale chápu správně že je potřeba poslat 
kus
papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou 
přihlášku
a poslat elektronicky? ;-)

Ahoj,

tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
informaci na konci prihlasky).

Bye

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

-- 
S pozdravem


Jan Cibulka
tel.: +420 776 307 158
datastory.cz 
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz


--
S pozdravem

Jan Cibulka
tel.: +420 776 307 158
datastory.cz 

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

Re: [talk-cz] přihláška do spolku OSM-CZ

Do nového threadu jsem poslal shrnutí všeho výše řečeného a v6 přihlášky 
se zahrnutím všech připomínek. Cílím tím na lidi které nezajímá 
technologická diskuze a prostě se chtějí přihlásit.


Ti co mají stále trpělivost na techologickou diskuzi poprosím o 
vyzkoušení verze 5.9 která je spolu s ostatními ke stažení na odkaze 
https://mrak.kub.cz/s/dmkk27Xqa8oF8Dd - podle mě by měla fungovat na 
většině Maců a Win.


gorn

On 18. 01. 19 15:08, gorn wrote:


Jo přesně tohle jsem zjistil studiem dokumentace. Adobe všem nacpalo 
svůj formát, ale že by se o to staralo to se nestará. Pokud bych 
vycházel čistě ze specifikace tak nic jiného než ISO-8859-1 to 
nepodporuje a ani daleko jednodušší věci, jako např. zarovnávání textu 
"dolů".


Každopádně existujou nějaký rozšířený specifikace, který jsou spíš "de 
fakto" než "de jure" a tam to zdá se vlastně funguje. Bohužel často až 
na Linux :) kterej se chudák drží specifikací a tím je bit.


Každopádně na základě feedbacku pošlu formulář kterej funguje většině 
lidí. Stejně většina lidí nemá elektronické klíče apod a bude to 
tisknout a posílat pošlou takže řešíme marginálie. Kdybychom to chtěli 
elektronicky, tak to vyplňujeme na webu a rovnou pásujeme s osm účtem, 
ale holt musíme nějak začít. Stay tuned :)


gorn

On 18. 01. 19 7:01, Karel Volný wrote:

čus,

tak naokraj ...


Myslím, že Windows za to můžou. Ani 23 let od unicode v 2.0 nebyl Microsoft
schopen unicode zavést a proto v roce 2019 Windows stále používají nějaká
obskurní kódování. ;-)

jak nemám Microsoft rád, tak tady se ho musím zastat, že veškerý problém s
kódováním padá na Adobe, resp. autory PDF, a musím říct, že pro naše
prostředí, tedy s diakritikou, jste formát zvolili nešťastně

pokud se nic zásadně nezměnilo od té doby, co jsem to před ~5 lety zkoumal[*],
tak PDF ve formulářích prostě nepodporuje to, co bychom potřebovali (tj.
alespoň ISO-8859-2, když už ne nějakou formu Unincode)

pokud někomu ve formulářích funguje diakritika (nad rámec pár očárkovaných
písmen), tak je to bug, ne featura, a rozhodně to není přenositelné, ani když
se vloží fonty

[*] teď koukám na Wiki, že 2017 vyšla verze 2.0, tj. změnit se mohlo mnohé -
hm, pokud to tato verze fixla, tak tedy good luck s podporou rok staré
specifikace, když dodnes jedou některé stroje na Windows XP, a v KDEčkách
(Okular ...) se sice polovina systému překopává co půl roku, ale spousta
nevyřešených bugů a feature requestů visí už přes deset let

K.

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

--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582

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

Re: [Talk-it] Aree di attesa, ammassamento e ricovero per piani di emergenza/protezione civile

2019-01-18 Thread mbranco2

Personalissima opinione:
penserei che sia un tipo di informazione non per OSM ma per un GIS
dedicato. Questo a meno che  l'area individuata non venga dotata di
segnaletica permanente e perimetrata in modo evidente.
Spero di poter essere corretto, perché l'importanza dell'informazione è
indubbia, ed è un tipo di informazione che essendo utile a tutta la
popolazione è importante che venga disseminata su più canali possibili.



Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>

Il giorno ven 18 gen 2019 alle ore 06:39 Alessandro Sarretta <
alessandro.sarre...@gmail.com> ha scritto:

> Buongiorno a tutti.
>
> Essendo entrato a far parte da poco del gruppo di volontari di Protezione
> Civile del mio comune, volevo approfondire come poter usare OpenStreetMap
> per aumentare le informazioni a disposizione dei cittadini usando appunto
> OSM.
>
> In particolare, stavo ragionando su come le aree di attesa, ammassamento e
> ricovero (vedi
> http://www.protezionecivile.gov.it/jcms/it/glossario.wp?letter=A) siano o
> possano essere mappate in OSM.
>
> Esistono linee guida generali al riguardo?
>
> Da una prima e rapida indagine, mi sembra che esista solamente il tag
> https://wiki.openstreetmap.org/wiki/Tag:emergency%3Dassembly_point, che
> possa corrispondere appunto alle aree di attesa per la popolazione.
>
> Ho guardato anche nei present dei tag relativi a HOT (
> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/HDM_preset) ma
> non mi sembra abbiano questa prospettiva. Qui (
> https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#Emergency_Response_.26_Relief_Support_Infrastructure)
> è citato ad esempio earthquake:damage=spontaneous_camp.
>
> Durante il terremoto del centro Italia le aree di ricovero erano state
> mappate come tourism=camp_site refugee=yes (es.
> https://www.openstreetmap.org/way/438746976).
>
> Tutte queste soluzioni però mi sembrano dei palliativi e poco specifiche.
>
> Se ci sono già invece informazioni che non ho trovato, sono interessato ad
> approfondire.
>
> Se invece la situazione è questa, potrei provare a formulare un'ipotesi di
> tagging e mappatura da discutere a livello italiano e poi eventualmente
> proporre anche a scala internazionale (se c'è corrispondenza).
>
> Tutti i comuni di Italia dovrebbero avere un piano di emergenza che
> individua queste tre tipologie di area e mi piacerebbe lanciare una
> campagna di mappatura a partire dai piani di emergenza esistenti che copra
> questa mancanza. Se troviamo una buona proposta mi piacerebbe farmene
> portavoce a partire dal mio comune.
>
> Grazie per qualunque input,
>
> Ale
>
>
> --
> --
>
> Alessandro Sarretta
>
> skype/twitter: alesarrett
> Web: ilsarrett.wordpress.com
>
> Research information:
>
>- Google scholar profile
>
>- ORCID 
>- Research Gate
>
>- Impactstory 
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>


Mail
priva di virus. www.avast.com

<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [OSM-talk] OpenStreetMap Carto release v4.19.0

2019-01-18 Thread Martijn van Exel

Thanks, Daniel and all contributors to the stylesheet. I can't even imagine how 
much work goes into carefully weighing how (not) to render all the stuff we map.

-- 
  Martijn van Exel
  m...@rtijn.org

On Fri, Jan 18, 2019, at 05:03, Daniel Koć wrote:
> Dear all,
> 
> Today, v4.19.0 of the OpenStreetMap Carto stylesheet (the default
> stylesheet on the OSM website) has been released. Once changes are
> deployed on the openstreetmap.org it will take couple of days before
> all tiles show the new rendering.
> 
> Changes include
> - Adding rendering for boundary=protected_area (#3509)
> - Nature reserve boundaries revision (#3574)
> - Adding support of amenity=vending_machine (#3601)
> - Adding more barrier icons (#3602)
> - Changing allotments color and adding outline (#3625)
> - Reducing priority of tourism=attraction and rendering from z17 (#3603)
> - Changing tourism outline color (#3582)
> - Making country borders thicker at z8 and z9 (#3563)
> - Rendering parking from z14 (#3612)
> - Starting to render most patterns at z13 instead of z14 (#3610)
> - Changing zoom level and text size for place=hamlet (#3626)
> - Rendering airport gate refs black instead of purple (#3620)
> - Updating zoom levels by height for masts, towers and telescopes (#3536)
> - Hiding underground parking (#3600)
> - Rendering ref of minor roads more than once (#3627)
> - Adjusting width of highway=construction (#3580)
> - Selecting only motorway_link to tertiary_link as link (#3567)
> - Reducing tertiary-link width (#3570)
> - Changing certain amenity icons to grey (#3586)
> - Converting springs to use ST_PointOnSurface and reformatting SQL (#3233)
> - Adding "religious-icon" as color variable for #00 (#3642)
> - Adding "barrier-icon" color variable in #3f3f3f for barriers (#3643)
> - Fixing inconsistency of leisure=ice_rink (#3598)
> - Fixing label opacity for tourism features (#3616)
> - Reverting lowzoom nobuilding test change (#3622)
> - Removing trailing whitespace (#3637)
> 
> Thanks to all the contributors for this release.
> 
> For a full list of commits, see
> https://github.com/gravitystorm/openstreetmap-carto/compare/v4.18.0...v4.19.0
> 
> As always, we welcome any bug reports at
> https://github.com/gravitystorm/openstreetmap-carto/issues
> 
> -- 
> "Excuse me, I have some growing up to do" [P. Gabriel]
> 
> 
> 
> ___
> 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-ca] Waylens camera available in Montreal

2019-01-18 Thread Fabián Rodríguez

Hi,

Last year OSM US lent me a Waylens camera for this project:

  * https://www.openstreetmap.us/2018/05/camera-lending-program/
  * 
https://wiki.openstreetmap.org/wiki/Foundation/Local_Chapters/United_States/Waylens_Camera_Lending_Program

I can't continue contributing, so if someone wants to join this effort,
please let me know off-list. We'd need to arrange for the kit I received
to be picked up. I am in Montreal.

Please read both links, they include important details and context. If
you aren't already an active OSM contributor, please do not contact me.

Cheers,

- Fabian

-- 
Fabián Rodríguez
http://openstreetmap.magicfab.ca/

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

2019-01-18 Thread Kyle Nuttall

The pilot project that took place in Ottawa for all these building imports is 
what got me hooked into OSM in the first place. I would make only very minor 
changes here and there. I even attempted to draw building footprints but got 
burnt out after only doing a single street, which was very discouraging for me 
to continue.

When I saw the entire neighbourhood get flooded with new buildings that weren't 
there before, I was entirely intrigued and actually got on board with the 
locals to help with the process. I've been hooked since and have been to many 
meetups afterwards. Helping out with projects completely unrelated to the 
initial building import.

I'm entirely of the belief that it is much more encouraging for a new user to 
make a minor change (eg. changing `building=yes` to `building=detached`) than 
it is to add every single minor detail to each object from scratch (visiting 
the location, drawing the building footprints manually, adding address data, 
etc.). It's just overwhelming for a new user.

It is very much a cat-and-mouse type scenario with community driven projects 
like OSM. Apparently the issue with this import is the lack of community 
involvement but I can for sure tell you that this import will help flourish the 
community in the local areas. Especially if they only need to add or change 
minor tags than if they would have had to create all of this data by hand. With 
an import this size there is bound to be some errors that slip through. That's 
where the community comes through to correct these minor things.

This is the whole point of OSM. A user creates an object with as much 
information as they know and the next user comes and adds onto that, and the 
next user adds and/or updates even more. Neither of those users on their own 
could have added as much detail as all of their knowledge combined.

Are we supposed to just wait for a user who can add every single building with 
centimetre precision and every bit of detail simply because we can't? No, of 
course not. We do the best we can and have other users who know more than we do 
build on that.

I fully endorse this import because I would love to see what it does for the 
local communities that apparently need to figure this import out for themselves.

Cheers,
Kyle

On Jan. 18, 2019 05:40, James  wrote:
As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't 
shoot me) There has never been a GO-Nogo for imports, you bring it up on the 
mailing lists with reasonable delay, is there no objections(in this case no one 
was saying anything about it for 2-3 weeks) then email the list that the import 
would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards 
mailto:alarob...@gmail.com> wrote:
Along the lines of what Jarek said, sometimes silence just means tacit 
acceptance, or that it's not that controversial. There's quite a bit of 
government data here that is supposedly "open" but unavailable for OSM, so I'm 
very glad Stats Can was able to find a way to collect municipal data and 
publish it under one national license. I was surprised myself it hadn't got 
more attention, but I'm firmly onboard with more imports if done with care.
Manually adding buildings - especially residential neighborhoods, is about the 
most boring task I can think of, yet it does add a lot to the map.

I'll admit I hadn't looked at the data quality myself, but I just did review 
several task squares around BC and they look pretty good. Houses were all in 
the right place, accurate, and generally as much or even more detailed than I 
typically see. Issues seemed to be mostly the larger commercial buildings being 
overly large or missing detail, but in general these are the buildings most 
likely to be already mapped. To a large degree, it's up the individual importer 
to do some quality control, review against existing object, satellite, etc. If 
we have specific issues we can and should address them, but if the data is 
largely good then I see no need to abort or revert.

alarobric

On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
mailto:ja...@piorkowski.ca>> wrote:
On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
mailto:stevea...@softworkers.com>> wrote:
> Thanks, Jarek.  Considering I am a proponent of "perfection must not be the 
> enemy of good" (regarding OSM data entry), I think data which are "darn good, 
> though not perfect" DO deserve to enter into OSM.  Sometimes "darn good" 
> might be 85%, 95% "good," as then we'll get it to 99% and then 100% over 
> time.  But if the focus on "how" isn't sharp enough to get it to 85% (or so) 
> during initial entry, go back and start over to get that number up.  85% 
> sounds arbitrary, I know, but think of it as "a solid B" which might be 
> "passes the class for now" without failing.  And it's good we develop a 
> "meanwhile strategy" to take it to 99% and then 100% in the (near- or at most 
> mid-term) future.  This isn't outrageously difficult, though it does take 
>

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread majka

On Fri, 18 Jan 2019 at 14:57, Jan Cibulka  wrote:

> Když pominu, že to programovala pošta, takže to má UX zdechlý veverky a
> zprávy si z toho musíš zálohovat, protože za 3 měsíce po doručení zmizí...
>
Nepomlouvej poštu - dokud běhal věstník veřejných zakázek, tedy jeho el.
varianta pod poštou, mělo to sice šarm T602 (nebo psacího stroje pro ty, co
tenhle program už nepamatují), ale fungovalo to bez větších problémů.
Zeptej se někoho co je s tím za (cenzurováno) teď. Ti, co to neměli povinné
od toho během pár měsíců utekli. Takže dřív bylo vše vypisované na jednom
místě, a teď to hledáš i po úředních deskách obcí.

Majka
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ

Jo přesně tohle jsem zjistil studiem dokumentace. Adobe všem nacpalo 
svůj formát, ale že by se o to staralo to se nestará. Pokud bych 
vycházel čistě ze specifikace tak nic jiného než ISO-8859-1 to 
nepodporuje a ani daleko jednodušší věci, jako např. zarovnávání textu 
"dolů".


Každopádně existujou nějaký rozšířený specifikace, který jsou spíš "de 
fakto" než "de jure" a tam to zdá se vlastně funguje. Bohužel často až 
na Linux :) kterej se chudák drží specifikací  a tím je bit.


Každopádně na základě feedbacku pošlu formulář kterej funguje většině 
lidí. Stejně většina lidí nemá elektronické klíče apod a bude to 
tisknout a posílat pošlou takže řešíme marginálie. Kdybychom to chtěli 
elektronicky, tak to vyplňujeme na webu a rovnou pásujeme s osm účtem, 
ale holt musíme nějak začít. Stay tuned :)


gorn

On 18. 01. 19 7:01, Karel Volný wrote:

čus,

tak naokraj ...


Myslím, že Windows za to můžou. Ani 23 let od unicode v 2.0 nebyl Microsoft
schopen unicode zavést a proto v roce 2019 Windows stále používají nějaká
obskurní kódování. ;-)

jak nemám Microsoft rád, tak tady se ho musím zastat, že veškerý problém s
kódováním padá na Adobe, resp. autory PDF, a musím říct, že pro naše
prostředí, tedy s diakritikou, jste formát zvolili nešťastně

pokud se nic zásadně nezměnilo od té doby, co jsem to před ~5 lety zkoumal[*],
tak PDF ve formulářích prostě nepodporuje to, co bychom potřebovali (tj.
alespoň ISO-8859-2, když už ne nějakou formu Unincode)

pokud někomu ve formulářích funguje diakritika (nad rámec pár očárkovaných
písmen), tak je to bug, ne featura, a rozhodně to není přenositelné, ani když
se vloží fonty

[*] teď koukám na Wiki, že 2017 vyšla verze 2.0, tj. změnit se mohlo mnohé -
hm, pokud to tato verze fixla, tak tedy good luck s podporou rok staré
specifikace, když dodnes jedou některé stroje na Windows XP, a v KDEčkách
(Okular ...) se sice polovina systému překopává co půl roku, ale spousta
nevyřešených bugů a feature requestů visí už přes deset let

K.

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


--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582

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

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Jan Cibulka

Hele starosti s tim nejsou (mam datovku v ekospolku), prostě o ní statutár na 
poště/radnici požádá, za dva dny přijde login. Následně možno vytvářet další 
loginy, třeba jen pro čtení, dalším osobám.

Dobrý je, že pak už všechny subjekty veřejný správy musej komunikovat skrze ni 
(ty tu povinnost, s - co vim - výjimkou přiznání k dani), takže ti všechno 
chodí elektronicky, žádný cesty na poštu. A nehrozí ti, že mineš nějakej 
zásadní dopis od úřadu, kterej tě následně kvůli fikci doručení kousne do 
zadnice.

A naopak ty pak můžeš komunikovat s úřadama (třeba se soudem, kam se každoročně 
posílá zápis z hromady) z pohodlí domova, bez pošty a zadarmo.

Prostě win-win. Když pominu, že to programovala pošta, takže to má UX zdechlý 
veverky a zprávy si z toho musíš zálohovat, protože za 3 měsíce po doručení 
zmizí...

On 18.01.2019 14:31, Marián Kyral wrote:

> Jednak jako spolek datovou schránku nemáme povinnou, takže jsme v tomto směru 
> zatím žádné kroky nepodnikali a taky si nejsem jist, kolik lidí datovou 
> schránku má. Zda by to stálo za ty starosti ;-)
>
> Marián
> -- Původní e-mail --
> Od: Jan Cibulka [](mailto:ho...@datastory.cz)
> Komu: OpenStreetMap Czech Republic 
> [](mailto:talk-cz@openstreetmap.org)
> Datum: 18. 1. 2019 14:24:58
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
>
>> A bude mít spolek datovou schránku? Pokud ano, možno posílat přihlášky tam 
>> (sice za peníze odesílatele, ale furt levnějc, než doporučenym dopisem).
>>
>> A teda tu DS by měl mít spolek tak jako tak, svěřit cokoli poště je 
>> riskantní ;)
>>
>> On 18.01.2019 11:57, Tom Ka wrote:
>>
>>> pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska
>>> [](mailto:krako...@krakonos.org)
>>> napsal:
>>>
 možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
 papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
 a poslat elektronicky? ;-)
>>>
>>> Ahoj,
>>>
>>> tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
>>> jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
>>> uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
>>> pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
>>> informaci na konci prihlasky).
>>>
>>> Bye
>>>
>>> ___
>>> talk-cz mailing list
>>> talk-cz@openstreetmap.org
>>>
>>> https://lists.openstreetmap.org/listinfo/talk-cz
>>>
>>> https://openstreetmap.cz/talkcz
>>
>> --
>> S pozdravem
>>
>> Jan Cibulka
>> tel.: +420 776 307 158
>> datastory.cz
>> ___
>> talk-cz mailing list
>> talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>> https://openstreetmap.cz/talkcz

--
S pozdravem

Jan Cibulka
tel.: +420 776 307 158
datastory.cz___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

2019-01-18 Thread Marián Kyral


-- Původní e-mail --
Od: gorn 
Komu: Tomas Novotny , OpenStreetMap Czech Republic 
Datum: 18. 1. 2019 14:52:03
Předmět: Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku
"
> Ahoj,
>
> narazil jsem na lyzarsky rozcestnik KCT, ktery ma v nazvu krome klasickych
> "bus", "zst" atd. pismenko "P" v cernem poli. Asi pro parkoviste, viz:
> https://osm.fit.vutbr.cz/fody/files/21727.jpg
> Jak znacit v tagu name? Napr.
> "name=Cihelna (P)" ?

Poslední dobou se místo standardizovaných zkratek dávají ikony, které
mají význam té zkratky. Tj napři místo "bus" se dá malý autobusek.
Ačkoli UTF některé ty ikony má, značil bych to těmi původními zkratkami,
které jsou standardizované. V tomto případě "park.", tj Cihelna (park.).
Seznam zkratek je následující:

atc, bus, háj., host., hot., cz/xx, hs, jesk., kap., koup., lan.,
mhd, mot., muz., mysl., nábř., nám., npp, npr, odb., pam.,
park., pom., pp, pr, prm., příst., rekr. táb., rozc., rozhl.,
ryb., sal., stud., táb., tur. ch., ubyt., vyhl., zám., zot., zříc.,
žst


> Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
> vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
> znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
> zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
> "guidepost:ref=KK144" atd.
na tu mapku bych se vykašlal, nebo bych jí dal jako samostaný bod, je to
stejný filozofický problém jak restaurace s hotelem.
> A tento rozcestnik ma jeste jednu zvlastnost: cca 50 metru od nej je
> rozcestnik s nazvem "Cihelna", ale referencnim cislem "KK144A", takze 
horni
> tabulka ma ref "KK144Am" atd. Videl jsem to u KCT poprve. Viz:
> https://osm.fit.vutbr.cz/fody/files/21726.jpg

Ano při krátkém souběhu  (zjednodušně dvě rozcestní blízko sebe) to KČT
považuje za jeden TIM a má to jedno referenční číslo. Ono se to pak
používá například tak, že na každém tom konci je jen ta "půlka" směrovek
které tam jsou potřeba. Není to častý ale je to správně. Do OSM to dávám
tak že tam dám REF které je na horní tabulce, tj. dal bych tam KK144A (m
už je jen podznak tý směrvny).

> Diky a mejte se,
>
> T.

Víc jsem se v tom zabýval na State of Trails 2019, někde možná visí
nějaké video.
"



Tady: https://openstreetmap.cz/sotm/2018




Marián
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku




Ahoj,

narazil jsem na lyzarsky rozcestnik KCT, ktery ma v nazvu krome klasickych
"bus", "zst" atd. pismenko "P" v cernem poli. Asi pro parkoviste, viz:
https://osm.fit.vutbr.cz/fody/files/21727.jpg
Jak znacit v tagu name? Napr.
"name=Cihelna (P)" ?


Poslední dobou se místo standardizovaných zkratek dávají ikony, které 
mají význam té zkratky. Tj napři místo "bus" se dá malý autobusek. 
Ačkoli UTF některé ty ikony má, značil bych to těmi původními zkratkami, 
které jsou standardizované. V tomto případě "park.", tj Cihelna (park.). 
Seznam zkratek je následující:


atc, bus, háj., host., hot., cz/xx, hs, jesk., kap., koup., lan.,
mhd, mot., muz., mysl., nábř., nám., npp, npr, odb., pam.,
park., pom., pp, pr, prm., příst., rekr. táb., rozc., rozhl.,
ryb., sal., stud., táb., tur. ch., ubyt., vyhl., zám., zot., zříc.,
žst



Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
"guidepost:ref=KK144" atd.
na tu mapku bych se vykašlal, nebo bych jí dal jako samostaný bod, je to 
stejný filozofický problém jak restaurace s hotelem.

A tento rozcestnik ma jeste jednu zvlastnost: cca 50 metru od nej je
rozcestnik s nazvem "Cihelna", ale referencnim cislem "KK144A", takze horni
tabulka ma ref "KK144Am" atd. Videl jsem to u KCT poprve. Viz:
https://osm.fit.vutbr.cz/fody/files/21726.jpg


Ano při krátkém souběhu  (zjednodušně dvě rozcestní blízko sebe) to KČT 
považuje za jeden TIM a má to jedno referenční číslo. Ono se to pak 
používá například tak, že na každém tom konci je jen ta "půlka" směrovek 
které tam jsou potřeba. Není to častý ale je to správně. Do OSM to dávám 
tak že tam dám REF které je na horní tabulce, tj. dal bych tam KK144A (m 
už je jen podznak tý směrvny).



Diky a mejte se,

T.


Víc jsem se v tom zabýval na State of Trails 2019, někde možná visí 
nějaké video.


gorn


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


--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582


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

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Marián Kyral


Jednak jako spolek datovou schránku nemáme povinnou, takže jsme v tomto
směru zatím žádné kroky nepodnikali a taky si nejsem jist, kolik lidí
datovou schránku má. Zda by to stálo za ty starosti ;-)




Marián



-- Původní e-mail --
Od: Jan Cibulka 
Komu: OpenStreetMap Czech Republic 
Datum: 18. 1. 2019 14:24:58
Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
"
A bude mít spolek datovou schránku? Pokud ano, možno posílat přihlášky tam
(sice za peníze odesílatele, ale furt levnějc, než doporučenym dopisem).

A teda tu DS by měl mít spolek tak jako tak, svěřit cokoli poště je
riskantní ;)


On 18.01.2019 11:57, Tom Ka wrote:

"
pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska  napsal:

"
možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
a poslat elektronicky? ;-)

"
Ahoj,

tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
informaci na konci prihlasky).

Bye

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

"
--
S pozdravem

Jan Cibulka
tel.: +420 776 307 158
datastory.cz(https://datastory.cz)
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ

Pokud chceš poslat hned, použij kterýkoli z formulářů, který ti funguje. 
Jinak vyčkej :)


On 18. 01. 19 14:06, Ladislav Láska wrote:

A když tam ještě vložím svůj škrábanec? Né že bych chtěl komplikovat
život, ale měl jsem zato že podle té (relativně) nové novely se za
podpis považuje skoro všechno co si vymyslím, klidně i snůška hexa
číslic :-)

Nicméně k věci: smím použít formulář 5.2 a přihlásit se, nebo raději
počkat na nějakou další verzi?

On 1/18/2019 11:57, Tom Ka wrote:

pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska  napsal:

možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
a poslat elektronicky? ;-)

Ahoj,

tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
informaci na konci prihlasky).

Bye

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


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


--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582


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

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Jan Cibulka

A bude mít spolek datovou schránku? Pokud ano, možno posílat přihlášky tam 
(sice za peníze odesílatele, ale furt levnějc, než doporučenym dopisem).

A teda tu DS by měl mít spolek tak jako tak, svěřit cokoli poště je riskantní ;)

On 18.01.2019 11:57, Tom Ka wrote:

> pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska
> [](mailto:krako...@krakonos.org)
> napsal:
>
>> možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
>> papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
>> a poslat elektronicky? ;-)
>
> Ahoj,
>
> tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
> jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
> uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
> pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
> informaci na konci prihlasky).
>
> Bye
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
>
> https://lists.openstreetmap.org/listinfo/talk-cz
>
> https://openstreetmap.cz/talkcz

--
S pozdravem

Jan Cibulka
tel.: +420 776 307 158
datastory.cz___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-GB] 2 Open Data Manchester in Feb 2019

2019-01-18 Thread Jez Nicholson

The very excellent Open Data Manchester are running 2 events in Feb 2019.

2 Feb An Introduction to OpenStreetMap with Andy Mabbett -
https://www.eventbrite.co.uk/e/an-introduction-to-openstreetmap-tickets-54982712774

26 Feb Mapping Your World - a beginner's guide to using OpenStreetMap -
https://www.eventbrite.co.uk/e/mapping-your-world-a-beginners-guide-to-using-openstreetmap-tickets-5498307
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Ladislav Láska

A když tam ještě vložím svůj škrábanec? Né že bych chtěl komplikovat
život, ale měl jsem zato že podle té (relativně) nové novely se za
podpis považuje skoro všechno co si vymyslím, klidně i snůška hexa
číslic :-)

Nicméně k věci: smím použít formulář 5.2 a přihlásit se, nebo raději
počkat na nějakou další verzi?

On 1/18/2019 11:57, Tom Ka wrote:
> pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska  
> napsal:
>>
>> možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
>> papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
>> a poslat elektronicky? ;-)
> 
> Ahoj,
> 
> tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
> jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
> uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
> pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
> informaci na konci prihlasky).
> 
> Bye
> 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
> 

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

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

2019-01-18 Thread majka

On Fri, 18 Jan 2019 at 13:53, Tom Ka  wrote:

> > Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
> > vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
> > znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
> > zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
> > "guidepost:ref=KK144" atd.
>
> z techto duvodu bych neznacil mapu vubec, jen rozcestnik.
>

Jestli takových rozcestníků je víc, možná bych začala přidávat map=yes nebo
guidepost:map=yes, a to zatím jen pro evidenci toho, kde se ty mapy
vyskytují. Rozumnější značení můžeme vymyslet kdykoli později, ale
ignorovat tu informaci by se mi tak úplně nechtělo.

Majka
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

pá 18. 1. 2019 v 13:28 odesílatel Tomas Novotny  napsal:
> narazil jsem na lyzarsky rozcestnik KCT, ktery ma v nazvu krome klasickych
> "bus", "zst" atd. pismenko "P" v cernem poli. Asi pro parkoviste, viz:
> https://osm.fit.vutbr.cz/fody/files/21727.jpg
> Jak znacit v tagu name? Napr.
> "name=Cihelna (P)" ?

za mne asi Cihelna (parking)

> Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
> vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
> znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
> zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
> "guidepost:ref=KK144" atd.

z techto duvodu bych neznacil mapu vubec, jen rozcestnik.

> A tento rozcestnik ma jeste jednu zvlastnost: cca 50 metru od nej je
> rozcestnik s nazvem "Cihelna", ale referencnim cislem "KK144A", takze horni
> tabulka ma ref "KK144Am" atd. Videl jsem to u KCT poprve. Viz:
> https://osm.fit.vutbr.cz/fody/files/21726.jpg

neni nahodou to KK144 nazev neceho jineho a jen nahodou stejny jako
ref? Kazdopadne zajimave :-)

Bye

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

Re: [Talk-GB] Rendering Problems

2019-01-18 Thread Brian Prangle

No worries, thanks for the update!

On Fri, 18 Jan 2019, 12:13 Tom Hughes  On 18/01/2019 09:49, Brian Prangle wrote:
>
> > Has anyone else noticed problems with edits failing to render?. Stuff I
> > did 2 days ago still not showing up
>
> Replication had stalled on one of the render servers - it is catching
> up now but will take a few hours to get everything.
>
> Tom
>
> --
> Tom Hughes (t...@compton.nu)
> http://compton.nu/
>
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

[talk-cz] Drobnosti k mapovani lyzarskych rozcestniku

2019-01-18 Thread Tomas Novotny

Ahoj,

narazil jsem na lyzarsky rozcestnik KCT, ktery ma v nazvu krome klasickych
"bus", "zst" atd. pismenko "P" v cernem poli. Asi pro parkoviste, viz:
https://osm.fit.vutbr.cz/fody/files/21727.jpg
Jak znacit v tagu name? Napr.
"name=Cihelna (P)" ?

Dale je na tomto rozcestniku mala mapka s lyzarskymi trasami. Ta mapka se
vyskytuje na vice lyzarskych rozcestnicich v teto oblasti. Ma smysl ji
znacit. Pripadne jak? Dat napr. "information=guidepost;map"? Jenze ref se
zase bude vztahovat i k mape a to pak vede na zneprehledneni typu
"guidepost:ref=KK144" atd.

A tento rozcestnik ma jeste jednu zvlastnost: cca 50 metru od nej je
rozcestnik s nazvem "Cihelna", ale referencnim cislem "KK144A", takze horni
tabulka ma ref "KK144Am" atd. Videl jsem to u KCT poprve. Viz:
https://osm.fit.vutbr.cz/fody/files/21726.jpg

Diky a mejte se,

T.

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

Re: [Talk-it] Aree di attesa, ammassamento e ricovero per piani di emergenza/protezione civile

2019-01-18 Thread Alessandro P.


Il 18/01/19 06:39, Alessandro Sarretta ha scritto:

.

Ho guardato anche nei present dei tag relativi a HOT 
(https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/HDM_preset) 
ma non mi sembra abbiano questa prospettiva. Qui 
(https://wiki.openstreetmap.org/wiki/Humanitarian_OSM_Tags/Humanitarian_Data_Background#Emergency_Response_.26_Relief_Support_Infrastructure) 
è citato ad esempio earthquake:damage=spontaneous_camp.




Ciao,
spontaneous_camp è tautologicamente un'iniziativa spontanea, non è detto 
che sorga nel luogo migliore della zona, quella che verrebbe scelta da 
esperti del settore.

Occorre trovare alcuni tag per queste aree.

Alessandro

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

Re: [Talk-GB] Rendering Problems

2019-01-18 Thread Tom Hughes


On 18/01/2019 09:49, Brian Prangle wrote:

Has anyone else noticed problems with edits failing to render?. Stuff I 
did 2 days ago still not showing up


Replication had stalled on one of the render servers - it is catching
up now but will take a few hours to get everything.

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/

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

[OSM-talk] OpenStreetMap Carto release v4.19.0

2019-01-18 Thread Daniel Koć

Dear all,

Today, v4.19.0 of the OpenStreetMap Carto stylesheet (the default
stylesheet on the OSM website) has been released. Once changes are
deployed on the openstreetmap.org it will take couple of days before
all tiles show the new rendering.

Changes include
- Adding rendering for boundary=protected_area (#3509)
- Nature reserve boundaries revision (#3574)
- Adding support of amenity=vending_machine (#3601)
- Adding more barrier icons (#3602)
- Changing allotments color and adding outline (#3625)
- Reducing priority of tourism=attraction and rendering from z17 (#3603)
- Changing tourism outline color (#3582)
- Making country borders thicker at z8 and z9 (#3563)
- Rendering parking from z14 (#3612)
- Starting to render most patterns at z13 instead of z14 (#3610)
- Changing zoom level and text size for place=hamlet (#3626)
- Rendering airport gate refs black instead of purple (#3620)
- Updating zoom levels by height for masts, towers and telescopes (#3536)
- Hiding underground parking (#3600)
- Rendering ref of minor roads more than once (#3627)
- Adjusting width of highway=construction (#3580)
- Selecting only motorway_link to tertiary_link as link (#3567)
- Reducing tertiary-link width (#3570)
- Changing certain amenity icons to grey (#3586)
- Converting springs to use ST_PointOnSurface and reformatting SQL (#3233)
- Adding "religious-icon" as color variable for #00 (#3642)
- Adding "barrier-icon" color variable in #3f3f3f for barriers (#3643)
- Fixing inconsistency of leisure=ice_rink (#3598)
- Fixing label opacity for tourism features (#3616)
- Reverting lowzoom nobuilding test change (#3622)
- Removing trailing whitespace (#3637)

Thanks to all the contributors for this release.

For a full list of commits, see
https://github.com/gravitystorm/openstreetmap-carto/compare/v4.18.0...v4.19.0

As always, we welcome any bug reports at
https://github.com/gravitystorm/openstreetmap-carto/issues

-- 
"Excuse me, I have some growing up to do" [P. Gabriel]



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

Re: [Talk-GB] Rendering Problems

2019-01-18 Thread Martin Wynne


On 18/01/2019 09:49, Brian Prangle wrote:

Has anyone else noticed problems with edits failing to render?. Stuff I did
2 days ago still not showing up


Try pressing CTRL+F5 in your browser to refresh the page. Your browser 
may be caching old tiles. This is especially a problem in Google Chrome.


Try zooming in a few levels. The zoomed-in tiles always update first and 
more often. Presumably because they contain a lot less content to be 
rendered.


cheers,

Martin.

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

Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)

2019-01-18 Thread Marián Kyral


Tohle by se možná dalo řešit speciálním OSM účtem, ke kterému by měli
přístup všichni členové rady.

Jen nevím, jestli by nevadilo, že by pod tím účtem nebyly žádné changesety.
Aby nám účet při nějaké čistce nesmazali :-D





Marián



-- Původní e-mail --
Od: Tom Ka 
Komu: OpenStreetMap Czech Republic 
Datum: 18. 1. 2019 11:54:59
Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)
"Nezavrhlo se to uplne, ale je tam zasadni nevyhoda, ze je to smerovano
na jednoho konkretniho cloveka, ne na celou radu, coz pri zmene rady
neni idealni. GPG je obecnejsi, takze vim, ze se bude dat pouzit.
Navic neni zavisly na zadne 3 strane.

Bye

pá 18. 1. 2019 v 10:56 odesílatel Pavel Zbytovský  napsal:
>
> Ještě bych měl podnět ke GPG klíči: na úvodní schůzi se mluvilo o možnosti
hlasování zkrze messaging system osm.org - já bych tuhle verzi preferoval,
protože to bude fungovat všem a míra bezpečnosti je přibližně stejná. (Když
to srovnám s používáním pro lidi neznáme technologie, kterou jinak na nic
nevyužijou.)
>
> Proč se to vlastně zavrhlo?
>
> P.
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz

___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ


GPG NEvyžadujeme. Nebo je to někde napsáno?

On 18. 01. 19 7:07, Karel Volný wrote:

zdar,


A jenom poznámka bokem: je vidět, že OSM dělají samý nerdi. Zajímalo by mě,
jestli v ČR existuje i jiný spolek, který u přihlášky vyžaduje otisk GPG
klíče.

(již bylo řečeno, se slovem "vyžaduje" opatrně)

tak třeba OpenAlt - a tuším, že jeden z jeho předchůdců OpenMobility to měl
taky(?)

K.

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


--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582

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

Re: [talk-cz] přihláška do spolku OSM-CZ

Me to prijde taky divny. Dovedu si představit třeba profi GISáky co 
nechtěj nikde moc šířit že jsou členy, nebo někoho kdo prostě chce jen 
přispívat ale nechce to spojovat se zbytkem svého života - ostatně právě 
proto jsou na OSM nicky a je na každém, jestli to propojí se svou 
totožností.


Zaroven mi to neprijde nijak vyloženě proti ničemu, čili bych to umožnil.

On 18. 01. 19 2:32, Petr Vozdecký wrote:


Kazdopadne mi prijde predstava, ze nekdo chce byt clenem spolku 
prosazujicicho otevřena data byt anonymni... no... proste ujeta...



--
gorn (Jakub Těšínský)
mapper a člen rady spolku
+420777852582


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

Re: [talk-cz] přihláška do spolku OSM-CZ

pá 18. 1. 2019 v 11:52 odesílatel Ladislav Láska  napsal:
>
> možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
> papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
> a poslat elektronicky? ;-)

Ahoj,

tim gpg klicem ne, protoze nemame jak ho svazat s tvoji osobou. Papir
jsme zvolili jako zaklad, protoze to muze udelat kazdy. Honza Cibulka
uz proveril i moznost PDF podepsaneho kvalifikovanym podpisem, to je
pravne i pro nas taky v pohode (a psal jsem Jakubovi aby to pridal do
informaci na konci prihlasky).

Bye

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

Re: [Talk-GB] Rendering Problems

2019-01-18 Thread Silent Spike

I've noticed my edits yesterday are not yet rendered (usually almost
instant). Presumably just a temporary slowdown due to heavy load or
something.

On Fri, Jan 18, 2019 at 10:31 AM Gareth L  wrote:

> I’ve noticed. A bunch of edits around Rugby (by you, I think?) are only
> being rendered on humanitarian tiles.
> Gareth
>
> > On 18 Jan 2019, at 09:50, Brian Prangle  wrote:
> >
> > Has anyone else noticed problems with edits failing to render?. Stuff I
> did 2 days ago still not showing up
> > ___
> > 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: [talk-cz] přihláška do spolku OSM-CZ

2019-01-18 Thread Ladislav Láska

Ahoj,

možná trochu hloupá otázka, ale chápu správně že je potřeba poslat kus
papíru? Nemůžu třeba tím gpg klíčem zrovna podepsat vyplněnou přihlášku
a poslat elektronicky? ;-)

On 1/16/2019 20:05, gorn wrote:
> Milí mappeři a mapperky,
> 
> včera jsme s Mariánem otevřeli pro spolek účet u Fiobanky, což byl
> poslední krok k zprovoznění spolku. Hlavní běhání ohledně zápisu a sídla
> vyřešil Tomáš (díky!) a poslední co zbývá k tomu abychom se mohli hlásit
> je formulář přihlášky :) V příloze ji posílám, prošla oponenturou v
> radě, ale budu rád pokud k ní napíše kdokoli své připomínky. Přihláška
> se dá jen vytisknout, nebo vyplnit rovnou v pdf prohlížeči.
> 
> Členem spolku OpenStreetMap Česká republika z.s. se lze stát takto:
> 
> 1. vyplňte přihlášku a předejte ji někomu z rady (podrobnosti na přihlášce)
> 2. na účet spolku pošlete členský příspěvek na rok 2019, do textu
> napište jméno, příjmení ať se nám to líp páruje.
> 
> to je všechno. Pokud navíc pošlete elektronickou verzi na
> spo...@openstreetmap.cz, budeme rádi. Bližší informace o spolku jsou na
> https://openstreetmap.cz/spolek, pár komentářů k tomu co přihláška obsahuje:
> 
>   * vaše údaje nebudeme nikde zveřejňovat, pokud nám k tomu nedáte souhlas
>   * GPG klíč ani telefon nepotřbujeme, ale telefon se může hodit ke
> komunikaci a GPG klíč pro případné elektronické hlasování
>   * souhlas s uveřejněním jména a nicku je zatím předběžná idea, pokud
> bychm někde chtěli jmenovat členy spolku, abychom nemuseli žádat
> dodatečně. Není nutný.
> 
> A na závěr připomenutí, že spolek je jen další možnost jak dosáhnout
> některých cílů OSM komunity, ale rozhodně nechce bránit v aktivitě
> kohokoli kdo cokoli pro OSM chce udělat skrze něj či mimo něj. Tak jako
> dosud závisí jen na jednotlivcích a jejich energii.
> 
> gorn
> 
> -- 
> gorn (Jakub Těšínský)
> mapper a člen rady spolku
> +420777852582
> 
> 
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
> 

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

Re: [Talk-ca] Ongoing Canadian building import needs to be stopped, possibly reverted

As Frederik Ramm once said(sorry i'm paraphrasing from memory please don't
shoot me) There has never been a GO-Nogo for imports, you bring it up on
the mailing lists with reasonable delay, is there no objections(in this
case no one was saying anything about it for 2-3 weeks) then email the list
that the import would start.

On Fri., Jan. 18, 2019, 12:59 a.m. Alan Richards  Along the lines of what Jarek said, sometimes silence just means tacit
> acceptance, or that it's not that controversial. There's quite a bit of
> government data here that is supposedly "open" but unavailable for OSM, so
> I'm very glad Stats Can was able to find a way to collect municipal data
> and publish it under one national license. I was surprised myself it hadn't
> got more attention, but I'm firmly onboard with more imports if done with
> care.
> Manually adding buildings - especially residential neighborhoods, is about
> the most boring task I can think of, yet it does add a lot to the map.
>
> I'll admit I hadn't looked at the data quality myself, but I just did
> review several task squares around BC and they look pretty good. Houses
> were all in the right place, accurate, and generally as much or even more
> detailed than I typically see. Issues seemed to be mostly the larger
> commercial buildings being overly large or missing detail, but in general
> these are the buildings most likely to be already mapped. To a large
> degree, it's up the individual importer to do some quality control, review
> against existing object, satellite, etc. If we have specific issues we can
> and should address them, but if the data is largely good then I see no need
> to abort or revert.
>
> alarobric
>
> On Thu, Jan 17, 2019 at 7:41 PM Jarek Piórkowski 
> wrote:
>
>> On Thu, 17 Jan 2019 at 21:46, OSM Volunteer stevea
>>  wrote:
>> > Thanks, Jarek.  Considering I am a proponent of "perfection must not be
>> the enemy of good" (regarding OSM data entry), I think data which are "darn
>> good, though not perfect" DO deserve to enter into OSM.  Sometimes "darn
>> good" might be 85%, 95% "good," as then we'll get it to 99% and then 100%
>> over time.  But if the focus on "how" isn't sharp enough to get it to 85%
>> (or so) during initial entry, go back and start over to get that number
>> up.  85% sounds arbitrary, I know, but think of it as "a solid B" which
>> might be "passes the class for now" without failing.  And it's good we
>> develop a "meanwhile strategy" to take it to 99% and then 100% in the
>> (near- or at most mid-term) future.  This isn't outrageously difficult,
>> though it does take patience and coordination.  Open communication is a
>> prerequisite.
>>
>> Thank you for this commitment. I wish others shared it. Unfortunately
>> the reality I've been seeing in OSM is that edits which are 90+% good
>> (like this import) are challenged, while edits which are 50+% bad
>> (maps.me submissions, wheelmap/rosemary v0.4.4 going to completely
>> wrong locations for _years_) go unchallenged or are laboriously
>> manually fixed afterward.
>>
>> --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
>
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [OSM-talk-fr] greffon conflation : fichier pour modifier la valeur d'un attribut d'un ensemble d'objets

2019-01-18 Thread lenny.libre


Bonjour

J'ai installé le greffon conflation.
J'ai téléchargé d'OSM les deux nœuds à modifier (calque OSMaModifier.osm)
J'ai ouvert le fichier NouvelRefSansId2enr.csv
Puis j'ai pas mal tâtonné avant de faire :

Dans la fenêtre du greffon

Générer les correspondances
Dans la fenêtre il y a deux différences une pour chaque noeud (si 
j'avais le fichier complet 487)

Je sélectionne les différences
Je clique sur combine

Et les valeurs ont bien été modifiées dans le calque OSMaModifier.osm

Merci

Leni

Le 16/01/2019 à 10:33, Vincent Bergeot a écrit :

Bonjour,

il me semble qu'il y a des choses à faire avec le plugin conflation 
https://wiki.openstreetmap.org/wiki/JOSM/Plugins/Conflation


à plus



Le 16/01/2019 à 10:16, lenny.libre a écrit :


Bonjour.

J'ai un fichier .csv dont voici les 2 premiers enregistrements :

@id,lat,lon,ref:FR:aec31
5210012041,43.3561957,0.8141832,801
5210012040,43.3562281,0.8145247,802

J'utilise JOSM ;

Je télécharge depuis OSM tous les nœuds à modifier ;

J'ouvre le fichier csv :
JOSM crée un calque en créant les nœuds, au bon endroit, avec un 
nouvel id et les attributs @id (même résultat si j'ai indiqué id dans 
le fichier) et ref:FR:aec31
Si j'enlève l'id du fichier : crée un nœud avec un nouvel id et 
l'attribut ref:FR:aec31


Si je fusionne les deux calques ( "nœuds à modifier" et "nœuds avec 
attribut à modifier")

JOSM me dit qu'il faut fusionner nœud par nœud
pour chaque nœud JOSM crée un deuxième nœud au-dessus du nœud à modifier

Si j'ai créé un fichier, c'est qu'il y a 487 nœuds à modifier ; je ne 
me vois pas les faire nœud par nœud ...

Y a-t-il une façon simple de le faire ? J'utilise JOSM avec W10

Merci d'avance

Leni



--
Vincent Bergeot


  









  
  









  


lat,lon,ref:FR:aec31
43.3561957,0.8141832,801
43.3562281,0.8145247,802
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [Talk-GB] Rendering Problems

2019-01-18 Thread Warin


On 18/01/19 20:49, Brian Prangle wrote:
Has anyone else noticed problems with edits failing to render?. Stuff 
I did 2 days ago still not showing up


I find a new entry goes through (zoomed in) fairly quickly

Changed old stuff takes it time .. and is not consistent with the zoom 
level.


If you mark a tile dirty then that usually takes a day. I only do that 
when I'm stuffy or not certain if I need to do more. I always mark dirty 
from a zoomed in level first, then the next day zoom out to see if I 
need/want to mark dirty there too.


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

Re: [OSM-talk-fr] Base OD/DAE et SauvLife - Permis de Sauver

2019-01-18 Thread Jacques Lavignotte




Le 17/12/2018 à 14:11, Jacques Lavignotte a écrit :
Faites un petit mot à ces gens > 
https://twitter.com/sauv_life/status/1074626562912387073


Dans la même veine :

http://permisdesauver.info/

qui poursuit le même objectif, plus orientée Pompiers (concurrence avec 
la précédente ?).


Et part elle aussi dans un recensement des DAE.

J.

--
GnuPg : C8F5B1E3 Because privacy matters.


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

Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)

2019-01-18 Thread Pavel Zbytovský

Ještě bych měl podnět ke GPG klíči: na úvodní schůzi se mluvilo o možnosti
hlasování zkrze messaging system osm.org - já bych tuhle verzi preferoval,
protože to bude fungovat všem a míra bezpečnosti je přibližně stejná. (Když
to srovnám s používáním pro lidi neznáme technologie, kterou jinak na nic
nevyužijou.)

Proč se to vlastně zavrhlo?

P.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

[Talk-GB] Rendering Problems

2019-01-18 Thread Brian Prangle

Has anyone else noticed problems with edits failing to render?. Stuff I did
2 days ago still not showing up
___
Talk-GB mailing list
Talk-GB@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb

Re: [Talk-it] Banchetto WMI a FOSS4G-IT 2019 a Padova

2019-01-18 Thread mbranco2

Ci sarò anch'io, quindi sarò disponibile.


Il giorno lun 14 gen 2019 alle ore 13:03 Volker Schmidt 
ha scritto:

> Molto meglio che serà in febbraio.
> :-)
> Volker
>
>
>
>
>
>
>
> 
>  Virus-free.
> www.avast.com
> 
> <#m_-7385862051435438116_DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>
>
> On Mon, 14 Jan 2019, 12:13 Alessandro Sarretta <
> alessandro.sarre...@gmail.com wrote:
>
>> On 14/01/19 12:02, Volker Schmidt wrote:
>>
>> On Mon, 14 Jan 2019 at 10:40, Alessandro Palmas <
>> alessandro.pal...@wikimedia.it> wrote:
>>
>>> ... almeno durante
>>> i giorni della conferenza, giovedì 21 e venerdì 22.
>>>
>>
>> Se intendi lunedì 21 e martedì 22 io posso esserci per mezza giornata,
>> fonora non ho appuntamenti fissi
>>
>> La conferenza FOSS4G-IT sarà a febbraio :-)
>>
>> Ale
>> --
>> --
>>
>> Alessandro Sarretta
>>
>> skype/twitter: alesarrett
>> Web: ilsarrett.wordpress.com
>>
>> Research information:
>>
>>- Google scholar profile
>>
>>- ORCID 
>>- Research Gate
>>
>>- Impactstory 
>>
>> ___
>> Talk-it mailing list
>> Talk-it@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-it
>>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] Rimozione piloni alta tensione

2019-01-18 Thread Lorenzo Stucchi

Grazie per il suggerimento per il siro di terna, ho trovato un comunicato
stampa che parla di questa rimozione
http://www.terna.it/Default.aspx?tabid=1095=111089=TCAT-CS non si
parla però di una sostituzione ma solo della rimozione.

Cercherò di stabilire quale la tratta che è stata rimossa e provvederò a
eliminarla.

Ciao,
Lorenzo

Il giorno 17 gen 2019, alle ore 20:25, Fabrizio Tambussa
mailto:ftambu...@gmail.com>> ha scritto:

Sono sempre di più i casi di linee a 132kV che vengono interrate in
corrispondenza dei centri urbani. Puoi cercare notizie dei lavori su
www.terna.it nella sezione Sistema elettrico, ma le
informazioni se ci sono sono annidate in profondità. Oppure cerca su google
articoli sulla stampa locale, normalmente questi lavori vengono pubblicizzati
per il loro ridotto impatto ambientale.
Saluti

Il giorno Gio 17 Gen 2019, 17:47 Lorenzo Stucchi
mailto:lorenzostucch...@outlook.it>> ha scritto:
Non ho visti segni di interramento ma mi sembra eccessivo il lavoro di
interrare 2 linee, credo sia stato spostato, non avendo però immagini recenti è
difficile capire questo spostamento.

Aspetto altri suggerimenti, non è possibile trovare una qualche segnalazioni
dei lavori? dove potrei cercare?

Il giorno 17 gen 2019, alle ore 17:17, Volker Schmidt
mailto:vosc...@gmail.com>> ha scritto:

Bene, abbiamo fatto progresso.
Quello che non sappiamo quanto di queste linee è stato interrato, e quale
percorso hanno scelto per farlo.
Hai per caso notato tracce di interramento sul terreno? Non penso che linee di
115 kV si mettono sotto la strada.

[https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif]
Virus-free.
www.avast.com

On Thu, 17 Jan 2019 at 16:49, Lorenzo Stucchi
mailto:lorenzostucch...@outlook.it>> wrote:
Ho avuto modo di scattare alcune foto nel tragitto di ritorno, e ho avuto modo
di vedere che nel punto che avevo indicato io, non esistono entrambe le linee,
facendo riferimento ai piloni (https://www.openstreetmap.org/node/896580348 e
https://www.openstreetmap.org/node/896577130 ) si può notare che non siano
presenti nelle foto che ho scattato.
Come anche per questo https://www.openstreetmap.org/node/896578293 e questo
https://www.openstreetmap.org/node/861259427 di cui non ho foto.
L’ultimo punto che ho controllato in questa zona,
https://www.openstreetmap.org/node/861259574 non risulta essere presente nel
modo in cui è mappato ma è presente una linea più piccola.

Le foto stanno per essere caricate su mapillary, le tempistiche dipendono dalla
connessione.

Credo che entrambe le linee siano state rimosse/interrrate.

Il giorno 17 gen 2019, alle ore 15:15, Volker Schmidt
mailto:vosc...@gmail.com>> ha scritto:

Attenzione, come appena scritto, è l'altra linea parallela che è "sparita".

[X]
Virus-free.
www.avast.com

On Thu, 17 Jan 2019 at 15:13, Fabrizio Tambussa
mailto:ftambu...@gmail.com>> wrote:
Pronabilmente la linea è stata interrata. Occorre risalire a dove la linea
passa da linea aerea a linea interrata e cancellare solo quel tratto.
Saluti

Il giorno Gio 17 Gen 2019, 14:14 Lorenzo Stucchi
mailto:lorenzostucch...@outlook.it>> ha scritto:
Buongiorno,

mi sono accorto, dopo un’uscita che questo pilone
https://www.openstreetmap.org/node/896580348 che fa parte di questa linea
elettrica https://www.openstreetmap.org/way/194877446 non risulta più esistere,
ma nelle immagini satellitari vecchia risulta esistente, come anche per la way
che passa parallelamente.

Non avendo molto senso eliminare il solo pilone, vi chiedo cosa fareste voi.

Ciao,
Stucchi Lorenzo
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

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

___
Talk-it mailing list

Re: [talk-cz] přihláška do spolku OSM-CZ (+ GPG klíč)

2019-01-18 Thread Mikoláš Štrajt


Zdar,

co se týká testování přihlášky:




- všechny verze se zobrazují dobře v aktuálním Firefoxu na Win7

- bude to myslím i tím, že mám všechna písma co v přihlášce jsou
nainstalovaná na počítači

- formuláře ve FF vyplnit nejdou, ale to není chyba přihlášky (FF je
nepodporuje)

- ve Foxitu na Win7 se taky přihlášky zobrazují dobře, dokonce jdou do
formulářů zadat háčky a čárky




* * *




co se týká GPG klíče - já bych možnosti hlasovat na dálku rád využil (až
budu členem). Cestovat třeba do Brna je pro mě finančně (ale především spíš
organizačně) celkem náročné.




--


Severák




-- Původní e-mail --
Od: gorn 
Komu: talk-cz@openstreetmap.org
Datum: 17. 1. 2019 17:24:59
Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
"

Díky za všechny postřehy


   * zanesl jsem  větší pole pro adresu (majka, petr)
   * Pavlovo připomínky ohledně lidí co se nechtějí někde zveřejnit budeme
   řešit, zatím woraround je poslat přihlášku a zaplatit příspěvky hotově
   nějakému radnímu (na transparentní účet podle mě nejde zaslat
   "netransparetní" platbu - minimálně tam bude odesilatel
   * další Pavlovo připomínky budeme řešit v radě, jsou širšího charakteru
   * problémy s kódováním fontů (vop, Dalibor) jsem řešil a v příloze jsou
   tři pokusy. Trochu jsem se ponořil do diskuzních fór a začínám mít pocit,
   že FPDF formát (a PDF obecně) je teda velehumus a něco tak jednoduchýho
   jako defaultní UTF je velice těžké dosáhnout. Některé specifikace to
   dokonce zakazují (ano PDF má několik specifikací). No takže to zkusíme
   prakticky - v příoze jsou tři verze, budu rád pokud mi napíšete která pod
   kterými windows a verzí Adobe Readeru Funguje - je to generováno z AR
   Pro, ale někde píšou že některé AR s tím kompatibilní nejsou. Primárně to
   chci rozchodit na Win a Macu (tam to běží) a pak budu řešit Linux (jsem
   sám Linuxák, ale Adobe na Linux prostě kašle)


gorn


On 17. 01. 19 16:12, Petr Vozdecký wrote:

"
-- Původní e-mail --
Od: majka (mailto:majka.zem+t...@gmail.com)
Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ "


Jako testovací doporučuji třeba adresu tohohle obecního úřadu
(https://www.dobravodaucb.cz/), ale nevejde se tam komplet ani "V Č. 
Budějovicích"

"



nebo adresu teto radnice http://www.novavesnm.cz/(http://www.novavesnm.cz/)

:)





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

"
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz
"___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ

čt 17. 1. 2019 v 19:24 odesílatel Marián Kyral  napsal:

> Tak ani jedna verze 5.2 mi nefunguje - ztrácí se diakritika. Jsem fakt
> nečekal, že s tím bude takový problém :-(
>

No ja vim, ze to Jakub nebude rad slyset, ale porad je moznost pouzit tu
"strasne hnusnou" verzi bez formatovani v jednoduchem dokumentu, ktera sice
mozna je hnusna ale netravi se nad ni tydny casu a proste funguje.

Bye


> Marián
>
> -- Původní e-mail --
> Od: Marián Kyral 
> Komu: OpenStreetMap Czech Republic 
> Datum: 17. 1. 2019 18:34:19
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
>
> Nezkoušel jsem. Jsem teď ve vlaku a internet spíše nefunguje než funguje
> :-(
> Ale zkusím.
>
> Marián
>
> -- Původní e-mail --
> Od: gorn 
> Komu: talk-cz@openstreetmap.org
> Datum: 17. 1. 2019 18:14:32
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
>
> Mariáne a ta 5.2 ti nefunguje?
> On 17. 01. 19 17:49, Marián Kyral wrote:
>
> Nevím, co s tím ty windows dělají, původní v5 na linuxu v Okularu naprosto
> bez problémů.
>
>
> Marián
>
> -- Původní e-mail --
> Od: gorn  
> Komu: talk-cz@openstreetmap.org
> Datum: 17. 1. 2019 17:25:40
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
>
> Díky za všechny postřehy
>
>- zanesl jsem  větší pole pro adresu (majka, petr)
>- Pavlovo připomínky ohledně lidí co se nechtějí někde zveřejnit
>budeme řešit, zatím woraround je poslat přihlášku a zaplatit příspěvky
>hotově nějakému radnímu (na transparentní účet podle mě nejde zaslat
>"netransparetní" platbu - minimálně tam bude odesilatel
>- další Pavlovo připomínky budeme řešit v radě, jsou širšího charakteru
>- problémy s kódováním fontů (vop, Dalibor) jsem řešil a v příloze
>jsou tři pokusy. Trochu jsem se ponořil do diskuzních fór a začínám mít
>pocit, že FPDF formát (a PDF obecně) je teda velehumus a něco tak
>jednoduchýho jako defaultní UTF je velice těžké dosáhnout. Některé
>specifikace to dokonce zakazují (ano PDF má několik specifikací). No takže
>to zkusíme prakticky - v příoze jsou tři verze, budu rád pokud mi napíšete
>která pod kterými windows a verzí Adobe Readeru Funguje - je to generováno
>z AR Pro, ale někde píšou že některé AR s tím kompatibilní nejsou. Primárně
>to chci rozchodit na Win a Macu (tam to běží) a pak budu řešit Linux (jsem
>sám Linuxák, ale Adobe na Linux prostě kašle)
>
> gorn
> On 17. 01. 19 16:12, Petr Vozdecký wrote:
>
>
> -- Původní e-mail --
> Od: majka  
> Předmět: Re: [talk-cz] přihláška do spolku OSM-CZ
>
>
> Jako testovací doporučuji třeba adresu tohohle obecního úřadu
> , ale nevejde se tam komplet ani "V Č.
> Budějovicích"
>
>
> nebo adresu teto radnice http://www.novavesnm.cz/
> :)
>
> ___
> talk-cz mailing 
> listtalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
>
> ___
> talk-cz mailing 
> listtalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-czhttps://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
> ___
> talk-cz mailing list
> talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
> https://openstreetmap.cz/talkcz
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] přihláška do spolku OSM-CZ

čt 17. 1. 2019 v 17:48 odesílatel Jan Macura  napsal:
> ...a předpokládám že nebude problém jej kdykoliv později doplnit, hej?

Samozrejme, je to aktualizace udaju v prihlasce jako kazda jina -
zmena adresy, mailu apod.

Bye

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

Re: [talk-cz] přihláška do spolku OSM-CZ