[talk-au] Country / farm dams

[Graeme Fitzpatrick]

Question that just came to mind after discussions on tagging list.

Just entered some details for a property in Western Qld, & started to
include a turkey nest dam
https://www.agric.wa.gov.au/water-management/excavated-tanks-farm-dams, but
then thought, what's it actually called?

Is it a waterway=dam? - not on  waterway so wouldn't have thought so

natural=water + water=reservoir / landuse=reservoir? "A *reservoir* is an
artificial lake is used to store water. Usually formed by a dam over a
natural water course, water then backs up into a natural valley or
depression" so no, not really?

landuse=basin + basin=retention? "An area of land artificially graded to
hold water" "retention basin
 catches storm water and
retains it, forming an artificial pond" so I guess that's the best
solution, but it doesn't really describe what you're looking at, because
anybody looking for a turkey nest dam isn't going to be looking for a
retention basin & vice versa!

Oz guidelines don't mention them, just windmills & bores.

Thanks

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

Re: [Talk-se] Naturvårdsverkets nya Nationella MarktäckeData

[Grigory Rechistov via Talk-se]

Hej! Kolla imports-listan där jag beskriver min nuvarande approach med masker:  
https://lists.openstreetmap.org/pipermail/imports/2019-April/005990.html  
Återkommer till talk-se-listan med fler filer, detaljer för de som vill pröva 
med nya vektor efter helgen. Trevlig helg!


Med vänliga hälsningar,
Grigory Rechistov
With best regards,
Grigory Rechistov
___
Talk-se mailing list
Talk-se@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-se

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[Kevin Kenny]

On Tue, Apr 30, 2019 at 5:12 PM OSM Volunteer stevea
 wrote:
> I myself have also used landuse=conservation (long ago) and/or 
> leisure=nature_reserve (neither of which render, not really the point).

My understanding is that landuse=conservation is deprecated in favor
of boundary=protected_area.

leisure=nature_reserve does indeed render.

boundary=protected_area, I am given to understand, renders if the
protection class is between 1 and 6 (with 1a and 1b also rendering).

> > I think the entire "national_park" tag is unfortunate, as it wraps up a
> > lot of concepts that vary by country, and makes people understand things
> > when they don't.  In the US, it should mean "preserve the land while
> > allowing access and enjoyment", there is a notion that the place is
> > relatively distinguished, and it doesn't really have a connotation of
> > size.
>
> Some say "size matters" with national_park, some say it's too confusing for 
> size to matter.  It doesn't seem we're going to eliminate 
> boundary=national_park anytime soon, as even though this shouldn't have 
> mattered, it did:  this was a tag that rendered, so people used it.  (How 
> rendering — presently, eventually, politically-within-OSM... — gets coupled 
> to tagging is another chewy topic).

Some say that 'level of government matters' or that 'title matters' as
well, but I think that the right way to think about it is function.The
two parks in New York that enjoy constitutional protection effectively
function as if they were national parks in other countries, as do many
facilities in the US that are titled, 'National Monument' or even
'National Forest'. They conform with the Wiki definition of 'national
park'. I suspect that relatively few, even among the tourists who've
been there, could distinguish among the coterminous 'Sequoia National
Park', 'Giant Sequoia National Monument, and 'Sequoia National
Forest'.
There was a proposal in the 1960's to transfer control of the
Adirondack Park to Uncle Sam, which would have created the nation's
largest National Park at the time. It was tremendously unpopular and
never went anywhere, but it was recognition that the two systems serve
a similar purpose. Baxter State Park in Maine is more stringently
protected than the adjoining Katahdin Woods and Waters National
Monument, and its scenery is considerably more spectacular.

For New York's confusing array of facilities, I've been careful to
retain protected_area tagging, in case we should lose all the
arguments and have no other consistent tagging left to us.
Unfortunately, to have that make sense, I've had to choose
protect_class=21 protection_object=recreation, since they aren't
generally nature-protected areas. (I try to tag them case by case -
I've not done a massive botched import.) Since that protection class
doesn't render, we're little better off from the standpoint of showing
something on the map.

About half the array of facilities is represented in the table on
https://wiki.openstreetmap.org/wiki/NYS_DEC_Lands. Nothing there is
tagged 'park', it's all nature_reserve - with a handful of exceptions
(fish hatchery, historic site, and notably state forest). Multiple Use
Area probably *should* be the same as whatever we wind up deciding is
right for the typical 'state park' but right now they're nature
reserves.  The remaining half of the facilities are the State Parks,
State Historic Sites, and State Recreation Areas (maybe other titles,
too, I need to check my notes) that are administered by a completely
different department of the state government.

My personal worst case of 'city park' is one that would fall solidly
within the European definition of 'park' - except that, well, it's
sort of also a cemetery.  https://www.openstreetmap.org/note/1438926 I
made the somewhat arbitrary decision of using multipolygons that
follow the land use rather than the property line.

It's a mess, and it's what I've got.

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

Re: [Talk-GB] OSMappers meeting in Norfolk

[nkn]

Hi Jez

thank you for your encouragement. Indeed, this is the attempt to find my 
tribe :) I don't know about NorDev and similarly, I haven't come across 
Maptime or CodeClub yet. Are these groups or types of events? A quick 
search doesn't reveal anything relevant or UK-specific to me, so if you 
could send some more details, I would be grateful and make contact with 
them.


The only OSM-related group in my proximity seem to be the HOT group in 
Cambridge running the Missing Maps events which I recently joined. 
Having spoken to two of the co-organisers, they seem to be no OSM group 
as such in Cambridge and it is quite far away for me.


Apart from writing via this GB list, I plan to approach some individuals 
with the help of the Who is around me? tool 
(http://resultmaps.neis-one.org/oooc) over the next couple of days.


Thank you
Nora


Am 29/04/2019 um 14:43 schrieb Jez Nicholson:

Hi Nora,

As a mapper and OSMUK Director I would love to see you succeed. I am 
interested in how we enhance OSM all over the UK. I'm wondering 
whether partnering with an existing meetup such as NorDev to do a talk 
might shake some mappers out of the woodwork? or generate some new 
ones? Or whether Norwich could do with a Maptime or CodeClub? Or 
whether OSMUK could help?


Anyway, does anyone have any advice on 'finding you tribe' for 
real-life OSM meetups?...or is it a case of starting with one person 
and building slowly?


Regards,
              Jez

On Sat, Apr 27, 2019 at 8:00 PM > wrote:


Hi fellow OSM companions in Norfolk,

I’m trying to organise a meetup.

/Why?/ I aim to revitalise the social side of mapping in the rural
spheres of Norfolk. It would be great to get to know other local
mappers from the area and to find out what other people are
interested in or currently working on.

/When?/ I suggest the 11th, 12th, 18th or 19th May 2019.

/Where?/ I propose to meet at a public place like a pub or café in
Norwich as suitable location for an initial meeting.

If you are principally interested, it would be great if you could
respond to me.

Regards
Nora


___
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-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

Apologies if I've already answered these.

On Apr 24, 2019, at 4:34 PM, Greg Troxel  wrote:
> I think Kevin has it right that we should tag primarily by something
> about land use, not by owne/operator, although it's fine to tag
> operator.

I 100% agree.  Yet I peruse landuse key values (except park is noted 
leisure=park, which means I'm chasing my tail so I ignore it) and find that 
none of them come close to describing "park" (the American English sense).  I 
myself have also used landuse=conservation (long ago) and/or 
leisure=nature_reserve (neither of which render, not really the point).

> I think the entire "national_park" tag is unfortunate, as it wraps up a
> lot of concepts that vary by country, and makes people understand things
> when they don't.  In the US, it should mean "preserve the land while
> allowing access and enjoyment", there is a notion that the place is
> relatively distinguished, and it doesn't really have a connotation of
> size.

Some say "size matters" with national_park, some say it's too confusing for 
size to matter.  It doesn't seem we're going to eliminate 
boundary=national_park anytime soon, as even though this shouldn't have 
mattered, it did:  this was a tag that rendered, so people used it.  (How 
rendering — presently, eventually, politically-within-OSM... — gets coupled to 
tagging is another chewy topic).

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

The linguist in me feels compelled to be a bit pedantic:  terms like "plain 
language" and "human language" used to distinguish between data/code/machine 
kinds of "language," including what we mean by "tagging" or "codepoint" are, I 
believe, well-expressed with the (linguistic community) phrase "natural 
language."

Much of what OSM is going through with "park" is because:

1)  leisure=park wasn't clearly defined (this is essentially the most important 
lesson),
2)  "park" has wide variation in what is meant (I have noted a distinctly 
American English dialect usage that is much more inclusive than that how OSM 
defines "park" as in 1),
3)  the drift apart between less-precise (over 15 years of tagging) usage of 
leisure=park, more-precise definition of leisure=park (which we partly say 
"what we meant all along" but others disagree, as it was less-precisely 
defined) has become severe, brought into focus as we recently made more precise 
the definition of leisure=park.  (Ostensibly to mean "what we meant all along," 
but which appears to be a significant re-definition to many, especially in the 
USA, where American English is used and its word "park" shaped the lack of 
precision definition in our wiki for the first 15 years of OSM).

Well, about there, anyway.  I think most or even all of us know this, I wanted 
to state it as explicitly as I do here.  These are my opinions, though they 
rise from long-term observation.

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

Re: [OSM-talk-be] Automated edits related to the GRB import

[joost schouppe]

Hi,

I just did a first edit on this.More info:
https://www.openstreetmap.org/changeset/69750322
Let me know if you see anything suspicious.

Op di 9 apr. 2019 om 09:46 schreef joost schouppe :

> Hi,
>
> The GRB building conflation is now in beta-testing. Join us on Riot (
> https://riot.im/app/#/room/#osmbe:matrix.org - or through OFTC for IRC)
> if you want to be an early adoptor.
>
> On the imports mailing list, there were some comments on the data model we
> used. In previous iterations, the toolset would at these tags to any
> building of which the geometry comes from GRB:
>
> 
> 
> 
> 
>
> Glenn has simplified this to:
> 
> 
>
> These tags make it easy to use the tool for detecting missing or
> improvable buildings, and for continuous maintance of the link between OSM
> and GRB. Now to keep the tool simple, we'd like to change all the objects
> that still have the old style tagging. Since that is an automated edit, one
> needs to follow the rules (as documented here
> https://wiki.openstreetmap.org/wiki/Automated_Edits_code_of_conduct)
>
> I have written a little script to do this. It just does the simple cases,
> because the complicate cases are quite rare and can probably just be done
> by hand.
> Everything seems to work. You can download an example changeset
> (West-Vlaanderen) here: https://we.tl/t-eMdVhq239N
> The sript for the parser is here:
> https://github.com/joostschouppe/little-grb-parser/blob/master/parser%20xml.sps
> Starts with the Overpass query you need. Sorry, the code is written in
> SPSS. That's just the language I speak best.
> If noone objects (and I get some confirmation it doesn't have stupid
> mistakes), I will do this province-by-province or in smaller chuncks if
> necessary. It takes just a few minutes to get from download to upload, so I
> don't foresee any editing conflicts.
>
>
> I'll
> use my "joost schouppe import" account. I'll add a little section to the
> main GRB project wiki pages (https://wiki.openstreetmap.org/wiki/GRBimport)
> about this edit and refer that in the changeset comments.
>
> --
> Joost Schouppe
> OpenStreetMap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>


-- 
Joost Schouppe
OpenStreetMap  |
Twitter  | LinkedIn
 | Meetup

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

Re: [Talk-us] Parks in the USA, leisure=park, park:type

[OSM Volunteer stevea]

At today's creation of https://wiki.osm.org/wiki/Talk:Key:park:type , I 
introduce a proposal to reduce usage of the park:type tag (initially, in the 
USA) with the goal of better clarifying USA park tagging.  There are a couple 
of "low hanging fruit" tasks we might do as a pilot run, though past these easy 
ones this will require additional community interaction.  That Discussion page 
is a good place to do so.

If you think you might offer some perspective on how the many values of 
park:type (state_park, city_park, state_beach, county_park, national_forest, 
state_game_land, state_recreational_area, private_park...) might help us better 
characterize and improve USA park tagging, please take a look at the brief 
discussion initiated there.  You are invited to participate.

Thank you,
SteveA
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-gb-westmidlands] River Rea, West of Kings Norton Park

[Andy Mabbett]

Done; but is it a river, or a stream? And does it have its own name?

On Tue, 30 Apr 2019 at 19:09, Brian Prangle  wrote:
>
> delete the name on the tributary should do the trick
>
> On Sat, Apr 27, 2019 at 12:05 PM Andy Mabbett  
> wrote:
>>
>> Compare the tagging on:
>>
>>https://www.openstreetmap.org/way/34080550
>>
>> and:
>>
>> https://www.openstreetmap.org/way/591479120
>>
>> and ways upstream (west) of the latter.
>>
>> I think the former is a tributary, and the latter is the river proper.
>> What needs to be changed?
>>
>> --
>> Andy Mabbett
>> @pigsonthewing
>> http://pigsonthewing.org.uk
>>
>> ___
>> Talk-gb-westmidlands mailing list
>> Talk-gb-westmidlands@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands



-- 
Andy Mabbett
@pigsonthewing
http://pigsonthewing.org.uk

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

Re: [Talk-ca] Importing buildings in Canada

[Pierre Béland via Talk-ca]

Bonjour à tous
Je suis à tester les fonctionnalités Topologie de PostGIS qui tient compte des 
relations entre les différents polygones.  Cela est prometteur  et je pense 
aussi arriver à une solution très bientôt.

Les fonctions PostGIS et la documentation sont disponibles à 
https://github.com/pierzen/OQ_Analysis 


Pierre 
 

Le mardi 30 avril 2019 13 h 29 min 37 s UTC−4, Tim Elrick  
a écrit :  
 
 Bonjour Daniel,

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

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

Tim

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

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

Daniel

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

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

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

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

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

Thoughts ladies and gentlemen please.

Thanks John


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


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

Re: [Talk-gb-westmidlands] River Rea, West of Kings Norton Park

[Brian Prangle]

delete the name on the tributary should do the trick

On Sat, Apr 27, 2019 at 12:05 PM Andy Mabbett 
wrote:

> Compare the tagging on:
>
>https://www.openstreetmap.org/way/34080550
>
> and:
>
> https://www.openstreetmap.org/way/591479120
>
> and ways upstream (west) of the latter.
>
> I think the former is a tributary, and the latter is the river proper.
> What needs to be changed?
>
> --
> Andy Mabbett
> @pigsonthewing
> http://pigsonthewing.org.uk
>
> ___
> Talk-gb-westmidlands mailing list
> Talk-gb-westmidlands@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands
>
___
Talk-gb-westmidlands mailing list
Talk-gb-westmidlands@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-gb-westmidlands

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Stephen Sprunk]

On 2019-04-30 05:50, Dave F via Talk-transit wrote:

On 29/04/2019 19:39, Markus wrote:
On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk  
wrote:
Part of what seems to have started the PTv2 mess is that bus stops 
were
sometimes mapped on the way and sometimes beside the way, and both 
cases
were tagged the same.  PTv2 tried to separate those into "platform" 
and

"stop_position", to bring uniformity across modes.

It would have been a lot easier to just recommend placing stops beside
the road. :)


If there is a problem on the OSM database I believe sorting that
problem is beneficial rather than 'papering over the cracks' by adding
extra tags. It may seem quite laborious, but just as quick as adding
those tags.


I agree.

We need platforms beside the way so routers can get people to/from 
the

stop on foot.  This is a big deal because trains are long and can
usually be boarded along their entire length, unlike buses where a 
node

often suffices.

OTOH, we need stop positions so routers can get people from stop to 
stop

on the buses/trains.


Routers just need the platforms (the places beside the road) because
the journey begins and ends there.


Please clarify what you mean by 'platforms'? Many UK bus stops are
merely signs clamped to telegraph poles. In rural areas there may not
even be a pavement, let alone a raise platform. Please remember that
we should be mapping the physical world. PT schema should fit in with
what's actually there.


A platform is where people wait to board; if they stand at a pole 
(typical for buses), then the pole is logically the platform.  That's 
easily distinguished from large platforms because it's a node rather 
than a way/area.



Stop positions (on the road) are
irrelevant for routing. If someone, for whatever reasons, needs the
stop positions, they can be calculated (projection of the stop node or
centroid of the platform to the highway or railway way).


Wouldn't a stop position be easier to locate if it's a node on the
highway, rather than an imaginary, offset 'platform'?

Please show me a router which uses platforms as I'm struggling to see
the benefits atm.


I think the idea was that nobody _could_ build routers with the data we 
had, which was inconsistently tagged between areas and sometimes even 
between mappers in the same area.


If you're trying to construct a route that involves walking to a bus 
stop, riding the bus to another stop, and then walking some more, then 
you need a linkage connecting the bus route (using stop positions) with 
the walkways (using platforms).  I'm not saying that's the only way to 
do it, but it's the only way that was proposed.


S


--
Stephen Sprunk  "Those people who think they know everything
CCIE #3723 are a great annoyance to those of us who do."
K5SSS --Isaac Asimov

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

Re: [Talk-ca] Importing buildings in Canada

[Tim Elrick]

Bonjour Daniel,

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


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


Tim

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

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

Daniel

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

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

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

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

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

Thoughts ladies and gentlemen please.

Thanks John


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



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

Re: [OSM-talk-fr] Postes de transformations électrique de "quartier" (sous-stations)

[François Lacombe]

Bonsoir Yves

Le lun. 29 avr. 2019 à 12:02, Yves P.  a écrit :

> Bonjour,
>
> Suite au message précédent de François souhaitant découper sa proposition
> d’origine, je souhaitais montrer la « complexité » actuelle pour rechercher
> des « transformateurs » pour le contributeur lambda.
>

Pour les non initiés, il s'agit de ce brouillon (en cours d'écriture) :
https://wiki.openstreetmap.org/wiki/Proposed_features/Substation_nodes_extension


> Un « transfo » sur poteau
>  (type H61 en
> France) est un « transfo » comme un autre (en armoire, cabine haute, cabine
> basse…) ?
> Et bien non ! Du moins pour certains logiciels que j’utilise à la maison
> ou sur le terrain :
>

Parce qu'il n'y a pas eu de mise en commun, c'est le but de cette
proposition à venir.
Sur le terrain c'est marqué "POSTE" donc on va retrouver un
power=substation partout, même sur les poteaux avec un transformateur.
Ce sera plus cohérent avec ce que tout le monde observe sur le terrain.


> En espérant que la future proposition de François sur le sujet sera
> acceptée.
>

Il faut déjà finir de l'écrire :)

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

Re: [Talk-ca] Importing buildings in Canada

[Paul Norman via Talk-ca]

The sources of the data are different in different regions, as well as the existing communities. A Canada-wide process won't work when each import is going to vary.On Apr 27, 2019 1:40 PM, john whelan  wrote:We now have three sources of data with the correct licensing.I'm proposing that I amend both the import plan and the import mailing list to include the three alternative sources.I'm tempted by the idea of splitting the country up into regions of some sort.We have a couple of groups currently who I think would like to import what is available in Alberta and Manitoba.  Are we asking them to hold off until Pierre and company have come up with a cleansing routine?Thoughts ladies and gentlemen please.Thanks John
___
Talk-ca mailing list
Talk-ca@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ca

Re: [Talk-ca] Importing buildings in Canada

[Begin Daniel]

Based on previous comments I improved the application and everything seems 
right now. I’ll start publishing results/documentation in following days ☺
We may then start developing an “open source” version of the application.
Daniel

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

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

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

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

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

Thoughts ladies and gentlemen please.

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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 4. 2019 16:22:57
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"

On Tue, 30 Apr 2019 at 15:55, Jan Macura mailto:macura...@gmail.com)> wrote:


"



Nicméně i to někteří dělají: https://wiki.openstreetmap.org/wiki/Tag:
landuse%3Dresidential#Separation_from_roads
(https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential#Separation_from_roads)



"



Osobně v tomhle případě za sporné spíš než to rozdělení považuji to, že se
dává jako možnost nalepit to na tu ulici. Přilepit jakoukoli landuse na
středovou čáru silnice/ polní/lesní cesty / pěšiny je taky dobrý způsob, jak
zkomplikovat budoucí úpravy. Minimálně si to říká o to, aby se změnou
landuse posunula silnice nebo změnou na silnici změnil tvar landuse bez
toho, že by to bylo úmyslem.


"



Tohle taky nesnáším. V JOSM to řeším tak, že nakreslím novou linii kolem
krajnice, plochu landuse rozdělím (Alt-X) a tu část přiléhající k silnici
smažu.

Případně, pokud je stejná landuse na obou stranách, tak ty dvě plochy prostě
spojím (Shift-J)




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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

-- Původní e-mail --
Od: Jan Macura 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 4. 2019 15:58:50
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"




On Tue, 30 Apr 2019 at 15:52, Marián Kyral mailto:mky...@email.cz)> wrote:

"

Nicméně residential area obsahuje i ty ulice a taky to většinou nedělíme na
bloky ;-)


"



Nicméně i to někteří dělají: https://wiki.openstreetmap.org/wiki/Tag:
landuse%3Dresidential#Separation_from_roads
(https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential#Separation_from_roads)






"



Proto jsem taky napsal "většinou", víme? :-D




Osobně bych řekl, že záleží na situaci. Lesní cesta nebo silnice III. třídy
- rozhodně nedělit. Silnice I. a II. třídy spíše ne, dálnice spíše ano.

Nicméně to jsme už hodně uhnuli od původního problému.




Marián



"






H.




___
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] percorso su spiaggia

[Gabriele via Talk-it]

Vero, con il tag visible=no diventa una sorta di meta-mapping, ma penso sia la 
soluzione migliore

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday 30 April 2019 16:06, Cascafico Giovanni  wrote:

> In effetti è un caso che esula dal principio del mappare quello che che è 
> visibile/verificabile... d'altra parte bloccare un routing perché c'è una 
> transitabilissima spiaggia mi pare irrazionale.
> Assomiglia al caso delle piazze pedonali: un'area senza percorsi visibili.
>
> Il mar 30 apr 2019, 13:57 Alfredo Gattai  ha 
> scritto:
>
>> Spesso in questi casi, c'e' una porzione di spiaggia (che dalle mie parti 
>> puo' facilmente essere costituita da ciottoli, ciottoloni o scogli) che 
>> risulta essere piu' calpestata proprio per il passaggio. Se fosse 
>> individuabile sarebbe l'ideale, altrimenti pace...
>>
>> On Tue, Apr 30, 2019 at 11:35 AM Cascafico Giovanni  
>> wrote:
>>
>>> Sarei per il
>>> highway=path
>>> surface=sand
>>> trail_visibility=no
>>>
>>> Il mar 30 apr 2019, 05:32 Gabriele via Talk-it  
>>> ha scritto:
>>>
 Buongiorno,
 sto mappando un percorso escursionistico che passa per una parte sulla 
 spiaggia [0]: come lo mappo? Aggiungo un percorso pedonale sulla spiaggia 
 anche se non c'è nulla fisicamente?

 [0] https://www.viaemisericordiae.org/le-tappe/pomposa/

 Sent with [ProtonMail](https://protonmail.com) Secure Email.

 ___
 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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[majka]

On Tue, 30 Apr 2019 at 15:55, Jan Macura  wrote:

> Nicméně i to někteří dělají:
> https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential#Separation_from_roads
>

Osobně v tomhle případě za sporné spíš než to rozdělení považuji to, že se
dává jako možnost nalepit to na tu ulici. Přilepit jakoukoli landuse na
středovou čáru silnice/ polní/lesní cesty / pěšiny je taky dobrý způsob,
jak zkomplikovat budoucí úpravy. Minimálně si to říká o to, aby se změnou
landuse posunula silnice nebo změnou na silnici změnil tvar landuse bez
toho, že by to bylo úmyslem.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-it] percorso su spiaggia

[Cascafico Giovanni]

In effetti è un caso che esula dal principio del mappare quello che che è
visibile/verificabile... d'altra parte bloccare un routing perché c'è una
transitabilissima spiaggia mi pare irrazionale.
Assomiglia al caso delle piazze pedonali: un'area senza percorsi visibili.

Il mar 30 apr 2019, 13:57 Alfredo Gattai  ha
scritto:

> Spesso in questi casi, c'e' una porzione di spiaggia (che dalle mie parti
> puo' facilmente essere costituita da ciottoli, ciottoloni o scogli) che
> risulta essere piu' calpestata proprio per il passaggio. Se fosse
> individuabile sarebbe l'ideale, altrimenti pace...
>
> On Tue, Apr 30, 2019 at 11:35 AM Cascafico Giovanni 
> wrote:
>
>> Sarei per il
>> highway=path
>> surface=sand
>> trail_visibility=no
>>
>> Il mar 30 apr 2019, 05:32 Gabriele via Talk-it 
>> ha scritto:
>>
>>> Buongiorno,
>>> sto mappando un percorso escursionistico che passa per una parte sulla
>>> spiaggia [0]: come lo mappo? Aggiungo un percorso pedonale sulla spiaggia
>>> anche se non c'è nulla fisicamente?
>>>
>>> [0] https://www.viaemisericordiae.org/le-tappe/pomposa/
>>>
>>>
>>> Sent with ProtonMail  Secure Email.
>>>
>>> ___
>>> 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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Jan Macura]

On Tue, 30 Apr 2019 at 15:52, Marián Kyral  wrote:

> Nicméně residential area obsahuje i ty ulice a taky to většinou nedělíme
> na bloky ;-)
>

Nicméně i to někteří dělají:
https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dresidential#Separation_from_roads

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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

-- Původní e-mail --
Od: Jan Dudík 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 4. 2019 14:59:21
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"

út 30. 4. 2019 v 14:21 odesílatel xkomc...@centrum.cz
(mailto:xkomc...@centrum.cz) mailto:xkomc...@centrum.cz)> napsal:


"

Docela kontroverzní tvrzení :-)





Když jdu lesem, narazím na silnici třetí, ale klidně i druhé či první třídy,
přejdu ji, tak nevycházím z jednoho lesa a nepřecházím do lesa druhého.
Prostě jsem pořád v tom samém lese. Proč by se to mělo dělit právě tady?


"
Jasně, je to o měřítku. Ale ve městě máš taky ulici dělanou jako čáru podél
které jsou domy a leckdy i hodně daleko od čáry, jinde blíž. Pokud budeš
uvažovat běžnou ulici 8 m mezi domy (ploty), což je minimální šířka daná
vyhláškou, a změříš si u lesního úseku vzdálenost stromů na levé a pravé
straně,  dostaneš se obvykle na 6 a více metrů. Navíc, když bys to bral
podle katastrální mapy, tak pozemek silnice má obvykle využití jako ostatní
plocha, kdežto les je trvalý lesní porost.

Oproti tomu menší lesní cesty ani v katastru nejsou.




Máme-li díky LPIS jedno pole jako dvacet menších polí, každé s jiným ID,
proč by nemohl být jeden les jako 20 menších lesů (nota bene fyzicky
oddělených pásem 6 m asfaltu)?


"



Nicméně residential area obsahuje i ty ulice a taky to většinou nedělíme na
bloky ;-)





Marián



"







 
"



Nemluvě o dalších nevýhodách typu zobrazování lesů při větším oddálení (kde 
jsou vidět pouze větší multipolygony), datové analýzy nad takto rozsekanými
lesy, ...





Magický postup, který by naráz vyřešil všechny naše problémy, asi
neexistuje.


Jirka Komárek


On 30. 04. 19 14:06, Jan Dudík wrote:

"
Jako první bod by určitě pomohlo, pokud vede skrz les větší silnice nebo
cesta, mapovat les na každé straně jako vlastní multipolygon.
Pak by to šlo i v rámci jednoho lesa dělat třeba podle stáří, druhů apod,
ale na to už se asi hůře shání data.




JAnD


---









út 30. 4. 2019 v 13:59 odesílatel Milan Cerny mailto:milan...@centrum.cz)> napsal:

"Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to
skončí bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě
dělením (sdílením) vnějších cest. To se po čase ukázalo jako nepraktické.
Aktuálně se snažím lesy mapovat po vzoru jedna linie outer a více inner.
To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na linii. Pak se
musí plocha rozdělit na více menších a přidělit správně inner prvky novým
relacím. Je to celkem náročné.
Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat, nejlépe
s dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná přišla
nazmar.

Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem
někde u 20.
Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište, opravím
přednostně.
Chyby v MP řeším prakticky denně a věřte, není jich málo.

Milan

__
> Od: "majka" mailto:majka.zem%2bt...@gmail.com)>
> Komu: "OpenStreetMap Czech Republic" mailto:talk-cz@openstreetmap.org)>
> Datum: 30.04.2019 12:26
> Předmět: Re: [talk-cz]        Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
>
>Ne, myslím tím outer který vypadá takhle:
>[image: 2019-04-30_115906.png]
>
>Tohle je konkrétně relace 25301
>
>
>JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci ani
>nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci nepobere).
>V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
>moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
>omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
>Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>
>Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
>zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
>50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
>znovu s tím, že ten les bude rozbitý už napořád.
>
>V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
>klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
>se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše to
>nepůjde.
>
>Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.
>
>Majka
>
>
>On Tue, 30 Apr 2019 at 11:06, Marián Kyral mailto:mky...@email.cz)> wrote:
>
>> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>>
>> To je něco jiného, než když je outer cesta 

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Jan Dudík]

út 30. 4. 2019 v 14:21 odesílatel xkomc...@centrum.cz 
napsal:

> Docela kontroverzní tvrzení :-)
>
>
> Když jdu lesem, narazím na silnici třetí, ale klidně i druhé či první
> třídy, přejdu ji, tak nevycházím z jednoho lesa a nepřecházím do lesa
> druhého. Prostě jsem pořád v tom samém lese. Proč by se to mělo dělit právě
> tady?
>
Jasně, je to o měřítku. Ale ve městě máš taky ulici dělanou jako čáru podél
které jsou domy a leckdy i hodně daleko od čáry, jinde blíž. Pokud budeš
uvažovat běžnou ulici 8 m mezi domy (ploty), což je minimální šířka daná
vyhláškou, a změříš si u lesního úseku vzdálenost stromů na levé a pravé
straně,  dostaneš se obvykle na 6 a více metrů. Navíc, když bys to bral
podle katastrální mapy, tak pozemek silnice má obvykle využití jako ostatní
plocha, kdežto les je trvalý lesní porost.
Oproti tomu menší lesní cesty ani v katastru nejsou.

Máme-li díky LPIS jedno pole jako dvacet menších polí, každé s jiným ID,
proč by nemohl být jeden les jako 20 menších lesů (nota bene fyzicky
oddělených pásem 6 m asfaltu)?



> Nemluvě o dalších nevýhodách typu zobrazování lesů při větším oddálení
> (kde jsou vidět pouze větší multipolygony), datové analýzy nad takto
> rozsekanými lesy, ...
>
>
> Magický postup, který by naráz vyřešil všechny naše problémy, asi
> neexistuje.
>
> Jirka Komárek
> On 30. 04. 19 14:06, Jan Dudík wrote:
>
> Jako první bod by určitě pomohlo, pokud vede skrz les větší silnice nebo
> cesta, mapovat les na každé straně jako vlastní multipolygon.
> Pak by to šlo i v rámci jednoho lesa dělat třeba podle stáří, druhů apod,
> ale na to už se asi hůře shání data.
>
> JAnD
> ---
>
>
> út 30. 4. 2019 v 13:59 odesílatel Milan Cerny 
> napsal:
>
>> Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to
>> skončí bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
>> Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě
>> dělením (sdílením) vnějších cest. To se po čase ukázalo jako nepraktické.
>> Aktuálně se snažím lesy mapovat po vzoru jedna linie outer a více inner.
>> To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na linii. Pak
>> se musí plocha rozdělit na více menších a přidělit správně inner prvky
>> novým relacím. Je to celkem náročné.
>> Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat,
>> nejlépe s dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná
>> přišla nazmar.
>>
>> Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem
>> někde u 20.
>> Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište,
>> opravím přednostně.
>> Chyby v MP řeším prakticky denně a věřte, není jich málo.
>>
>> Milan
>>
>> __
>> > Od: "majka" 
>> > Komu: "OpenStreetMap Czech Republic" 
>> > Datum: 30.04.2019 12:26
>> > Předmět: Re: [talk-cz]Jak na rekonstrukce multipolygonů (outer
>> z neuzavřených cest)
>> >
>> >Ne, myslím tím outer který vypadá takhle:
>> >[image: 2019-04-30_115906.png]
>> >
>> >Tohle je konkrétně relace 25301
>> >
>> >
>> >JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci
>> ani
>> >nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci
>> nepobere).
>> >V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde
>> to
>> >moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
>> >omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde
>> to.
>> >Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>> >rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>> >
>> >Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
>> >zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
>> >50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>> >přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
>> >znovu s tím, že ten les bude rozbitý už napořád.
>> >
>> >V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
>> >klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím,
>> že
>> >se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše
>> to
>> >nepůjde.
>> >
>> >Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně
>> často.
>> >
>> >Majka
>> >
>> >
>> >On Tue, 30 Apr 2019 at 11:06, Marián Kyral  wrote:
>> >
>> >> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>> >>
>> >> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
>> >> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě.
>> No a
>> >> velké lesy mívají těch uzlů mnohem více.
>> >>
>> >> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
>> >> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
>> >> polygony.
>> >>
>> >> Díky,
>> >> Marián
>> >>

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

Tak lze mít jeden multipolygon co má dvě a více outer smyček. Jen se to moc
nedělá.




Marián



-- Původní e-mail --
Od: xkomc...@centrum.cz 
Komu: talk-cz@openstreetmap.org
Datum: 30. 4. 2019 14:24:52
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"

Docela kontroverzní tvrzení :-)





Když jdu lesem, narazím na silnici třetí, ale klidně i druhé či první třídy,
přejdu ji, tak nevycházím z jednoho lesa a nepřecházím do lesa druhého.
Prostě jsem pořád v tom samém lese. Proč by se to mělo dělit právě tady?


Nemluvě o dalších nevýhodách typu zobrazování lesů při větším oddálení (kde 
jsou vidět pouze větší multipolygony), datové analýzy nad takto rozsekanými
lesy, ...





Magický postup, který by naráz vyřešil všechny naše problémy, asi
neexistuje.


Jirka Komárek


On 30. 04. 19 14:06, Jan Dudík wrote:

"
Jako první bod by určitě pomohlo, pokud vede skrz les větší silnice nebo
cesta, mapovat les na každé straně jako vlastní multipolygon.
Pak by to šlo i v rámci jednoho lesa dělat třeba podle stáří, druhů apod,
ale na to už se asi hůře shání data.




JAnD


---









út 30. 4. 2019 v 13:59 odesílatel Milan Cerny mailto:milan...@centrum.cz)> napsal:

"Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to
skončí bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě
dělením (sdílením) vnějších cest. To se po čase ukázalo jako nepraktické.
Aktuálně se snažím lesy mapovat po vzoru jedna linie outer a více inner.
To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na linii. Pak se
musí plocha rozdělit na více menších a přidělit správně inner prvky novým
relacím. Je to celkem náročné.
Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat, nejlépe
s dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná přišla
nazmar.

Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem
někde u 20.
Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište, opravím
přednostně.
Chyby v MP řeším prakticky denně a věřte, není jich málo.

Milan

__
> Od: "majka" mailto:majka.zem%2bt...@gmail.com)>
> Komu: "OpenStreetMap Czech Republic" mailto:talk-cz@openstreetmap.org)>
> Datum: 30.04.2019 12:26
> Předmět: Re: [talk-cz]        Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
>
>Ne, myslím tím outer který vypadá takhle:
>[image: 2019-04-30_115906.png]
>
>Tohle je konkrétně relace 25301
>
>
>JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci ani
>nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci nepobere).
>V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
>moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
>omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
>Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>
>Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
>zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
>50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
>znovu s tím, že ten les bude rozbitý už napořád.
>
>V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
>klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
>se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše to
>nepůjde.
>
>Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.
>
>Majka
>
>
>On Tue, 30 Apr 2019 at 11:06, Marián Kyral mailto:mky...@email.cz)> wrote:
>
>> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>>
>> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
>> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě. No a
>> velké lesy mívají těch uzlů mnohem více.
>>
>> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
>> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
>> polygony.
>>
>> Díky,
>> Marián
>>
>> -- Původní e-mail --
>> Od: majka mailto:majka.zem%2bt...@gmail.com)>
>> Komu: talk-cz@openstreetmap.org(mailto:talk-cz@openstreetmap.org)
>> Datum: 30. 4. 2019 10:29:20
>> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených
>> cest)
>>
>> Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
>> multipolygony (specificky lesy), u kterých outer není oblast, ale je to
>> tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané
i
>> ty inner.
>> Tyhle multipolygony se 

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

-- Původní e-mail --
Od: Milan Cerny 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 4. 2019 14:04:48
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to
skončí bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě
dělením (sdílením) vnějších cest. To se po čase ukázalo jako nepraktické.
Aktuálně se snažím lesy mapovat po vzoru jedna linie outer a více inner.
To ovšem naráží na již zmíněný problém s limitem 2000 bodů na linii. Pak se
musí plocha rozdělit na více menších a přidělit správně inner prvky novým
relacím. Je to celkem náročné. """



Ahoj,

těch 2000 bodů na linii je v pohodě - prostě tu outer cestu na vhodných
místech rozdělíš na dvě půlky. Hotovo. Polí se ani nedotkneš. Tracer se
těmhle lesům vyhne -> napasovat hranice lesa na pole musíš ručně. To musíš
stejně, pokud je mezi lesem a polem něco jiného - cesta, tráva, křoví.

 
"
Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat, nejlépe
s dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná přišla
nazmar."



Nahoď na wiki nějaký návrh a postupným upřesňováním se snad něčeho dobereme.



"

Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem
někde u 20.
Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište, opravím
přednostně.
Chyby v MP řeším prakticky denně a věřte, není jich málo.
"



A kdyby se ti chtělo popsat ty problémy a jak to řešíš, to by bylo top ;-)




Marián



"
Milan

__
> Od: "majka" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 30.04.2019 12:26
> Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
>
>Ne, myslím tím outer který vypadá takhle:
>[image: 2019-04-30_115906.png]
>
>Tohle je konkrétně relace 25301
>
>
>JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci ani
>nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci nepobere).
>V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
>moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
>omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
>Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>
>Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
>zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
>50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
>znovu s tím, že ten les bude rozbitý už napořád.
>
>V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
>klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
>se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše to
>nepůjde.
>
>Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.
>
>Majka
>
>
>On Tue, 30 Apr 2019 at 11:06, Marián Kyral  wrote:
>
>> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>>
>> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
>> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě. No a
>> velké lesy mívají těch uzlů mnohem více.
>>
>> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
>> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
>> polygony.
>>
>> Díky,
>> Marián
>>
>> -- Původní e-mail --
>> Od: majka 
>> Komu: talk-cz@openstreetmap.org
>> Datum: 30. 4. 2019 10:29:20
>> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených
>> cest)
>>
>> Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
>> multipolygony (specificky lesy), u kterých outer není oblast, ale je to
>> tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané
i
>> ty inner.
>> Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
>> případně při upravení polohy cest či rezidenčních oblastí (protože bývají
>> nalepené i na ně) strašně jednoduše rozbijí.
>>
>> Když jsem opravovala poslední takový, strávila jsem s tím doslova půl dne
>> práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala
>> kontrola toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o
>> jediný les, jen nám ho momentálně protnula stavba dálnice a na jiném
místě
>> z něj "ukousala" pole a výstavba.
>>
>> Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem jsou
>> v podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy hranice
>> mění poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné
je
>> to většinou dost snadno 

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[xkomc...@centrum.cz]

Docela kontroverzní tvrzení :-)


Když jdu lesem, narazím na silnici třetí, ale klidně i druhé či první 
třídy, přejdu ji, tak nevycházím z jednoho lesa a nepřecházím do lesa 
druhého. Prostě jsem pořád v tom samém lese. Proč by se to mělo dělit 
právě tady?


Nemluvě o dalších nevýhodách typu zobrazování lesů při větším oddálení 
(kde jsou vidět pouze větší multipolygony), datové analýzy nad takto 
rozsekanými lesy, ...



Magický postup, který by naráz vyřešil všechny naše problémy, asi 
neexistuje.


Jirka Komárek

On 30. 04. 19 14:06, Jan Dudík wrote:
Jako první bod by určitě pomohlo, pokud vede skrz les větší silnice 
nebo cesta, mapovat les na každé straně jako vlastní multipolygon.
Pak by to šlo i v rámci jednoho lesa dělat třeba podle stáří, druhů 
apod, ale na to už se asi hůře shání data.


JAnD
---


út 30. 4. 2019 v 13:59 odesílatel Milan Cerny > napsal:


Ahoj, téma velkých multipolygonů se tady řeší celkem často.
Většinou to skončí bez jasné shody na tom, jak by bylo lepší tyto
plochy mapovat a proč.
Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval
právě dělením (sdílením) vnějších cest. To se po čase ukázalo jako
nepraktické. Aktuálně se snažím lesy mapovat po vzoru jedna linie
outer a více inner.
To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na
linii. Pak se musí plocha rozdělit na více menších a přidělit
správně inner prvky novým relacím. Je to celkem náročné.
Proto bych byl rád, kdyby padla nějaká shoda na tom jak to
mapovat, nejlépe s dokumentací na wiki. Nerad bych aby čas a práce
tomu věnovaná přišla nazmar.

Opravy provádím od těch MP, které mají nejvíce outer prvků,
aktuálně jsem někde u 20.
Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem
napište, opravím přednostně.
Chyby v MP řeším prakticky denně a věřte, není jich málo.

Milan

__
> Od: "majka" mailto:majka.zem%2bt...@gmail.com>>
> Komu: "OpenStreetMap Czech Republic" mailto:talk-cz@openstreetmap.org>>
> Datum: 30.04.2019 12:26
> Předmět: Re: [talk-cz]        Jak na rekonstrukce multipolygonů
(outer z neuzavřených cest)
>
>Ne, myslím tím outer který vypadá takhle:
>[image: 2019-04-30_115906.png]
>
>Tohle je konkrétně relace 25301
>
>
>JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu
relaci ani
>nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci
nepobere).
>V konkrétním případě je to ještě přilepené na křižovatku v obci a
nejde to
>moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z
důvodu
>omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale
vyjde to.
>Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>
>Není to problém Traceru, ale tím, co uživatel udělá dál (tracer
většinou
>zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak
je to
>50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a
natrasuje to
>znovu s tím, že ten les bude rozbitý už napořád.
>
>V tomhle místě jsem to začala editovat (vlastně kvůli tomu
nedostavěnému
>klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to
s tím, že
>se na to podívám zítra, jestli u nás bude ještě pršet. Protože
jednoduše to
>nepůjde.
>
>Těchhle multipolygonů lesa máme poměrně dost, narážím na ně
poměrně často.
>
>Majka
>
>
>On Tue, 30 Apr 2019 at 11:06, Marián Kyral mailto:mky...@email.cz>> wrote:
>
>> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>>
>> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
>> Většinou to způsobeno interním omezením max 2000 uzlů v jedné
cestě. No a
>> velké lesy mívají těch uzlů mnohem více.
>>
>> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
>> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen
uzavřené
>> polygony.
>>
>> Díky,
>> Marián
>>
>> -- Původní e-mail --
>> Od: majka mailto:majka.zem%2bt...@gmail.com>>
>> Komu: talk-cz@openstreetmap.org 
>> Datum: 30. 4. 2019 10:29:20
>> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených
>> cest)
>>
>> Má někdo nápad, jak nejlépe, resp. nejsnadněji
opravit/rekonstruovat
>> multipolygony (specificky lesy), u kterých outer není oblast,
ale je to
>> tvořené jednotlivými cestami? V horším případě jsou takhle
zoufale dělané i
>> ty inner.
>> Tyhle 

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Jan Dudík]

Jako první bod by určitě pomohlo, pokud vede skrz les větší silnice nebo
cesta, mapovat les na každé straně jako vlastní multipolygon.
Pak by to šlo i v rámci jednoho lesa dělat třeba podle stáří, druhů apod,
ale na to už se asi hůře shání data.

JAnD
---


út 30. 4. 2019 v 13:59 odesílatel Milan Cerny  napsal:

> Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to
> skončí bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
> Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě
> dělením (sdílením) vnějších cest. To se po čase ukázalo jako nepraktické.
> Aktuálně se snažím lesy mapovat po vzoru jedna linie outer a více inner.
> To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na linii. Pak
> se musí plocha rozdělit na více menších a přidělit správně inner prvky
> novým relacím. Je to celkem náročné.
> Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat,
> nejlépe s dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná
> přišla nazmar.
>
> Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem
> někde u 20.
> Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište,
> opravím přednostně.
> Chyby v MP řeším prakticky denně a věřte, není jich málo.
>
> Milan
>
> __
> > Od: "majka" 
> > Komu: "OpenStreetMap Czech Republic" 
> > Datum: 30.04.2019 12:26
> > Předmět: Re: [talk-cz]Jak na rekonstrukce multipolygonů (outer z
> neuzavřených cest)
> >
> >Ne, myslím tím outer který vypadá takhle:
> >[image: 2019-04-30_115906.png]
> >
> >Tohle je konkrétně relace 25301
> >
> >
> >JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci
> ani
> >nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci
> nepobere).
> >V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
> >moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
> >omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
> >Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
> >rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
> >
> >Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
> >zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
> >50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
> >přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
> >znovu s tím, že ten les bude rozbitý už napořád.
> >
> >V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
> >klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
> >se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše
> to
> >nepůjde.
> >
> >Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.
> >
> >Majka
> >
> >
> >On Tue, 30 Apr 2019 at 11:06, Marián Kyral  wrote:
> >
> >> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
> >>
> >> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
> >> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě. No
> a
> >> velké lesy mívají těch uzlů mnohem více.
> >>
> >> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
> >> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
> >> polygony.
> >>
> >> Díky,
> >> Marián
> >>
> >> -- Původní e-mail --
> >> Od: majka 
> >> Komu: talk-cz@openstreetmap.org
> >> Datum: 30. 4. 2019 10:29:20
> >> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
> neuzavřených
> >> cest)
> >>
> >> Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
> >> multipolygony (specificky lesy), u kterých outer není oblast, ale je to
> >> tvořené jednotlivými cestami? V horším případě jsou takhle zoufale
> dělané i
> >> ty inner.
> >> Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
> >> případně při upravení polohy cest či rezidenčních oblastí (protože
> bývají
> >> nalepené i na ně) strašně jednoduše rozbijí.
> >>
> >> Když jsem opravovala poslední takový, strávila jsem s tím doslova půl
> dne
> >> práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala
> >> kontrola toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o
> >> jediný les, jen nám ho momentálně protnula stavba dálnice a na jiném
> místě
> >> z něj "ukousala" pole a výstavba.
> >>
> >> Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem
> jsou
> >> v podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy
> hranice
> >> mění poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné
> je
> >> to většinou dost snadno zrovna podle toho lpis.
> >> ___
> >> talk-cz mailing list
> >> talk-cz@openstreetmap.org
> >> 

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Milan Cerny]

Ahoj, téma velkých multipolygonů se tady řeší celkem často. Většinou to skončí 
bez jasné shody na tom, jak by bylo lepší tyto plochy mapovat a proč.
Opravám lesních ploch věnuji dost času. Dříve jsem lesy opravoval právě dělením 
(sdílením) vnějších cest. To se po čase ukázalo jako nepraktické. Aktuálně se 
snažím lesy mapovat po vzoru jedna linie outer a více inner.
To ovšem naráží na již zmíněný  problém s limitem 2000 bodů na linii. Pak se 
musí plocha rozdělit na více menších a přidělit správně inner prvky novým 
relacím. Je to celkem náročné. 
Proto bych byl rád, kdyby padla nějaká shoda na tom jak to mapovat, nejlépe s 
dokumentací na wiki. Nerad bych aby čas a práce tomu věnovaná přišla nazmar.

Opravy provádím od těch MP, které mají nejvíce outer prvků, aktuálně jsem někde 
u 20.
Pokud je potřeba nějaké konkrétní MP opravit, klidně je sem napište, opravím 
přednostně.
Chyby v MP řeším prakticky denně a věřte, není jich málo.

Milan 

__
> Od: "majka" 
> Komu: "OpenStreetMap Czech Republic" 
> Datum: 30.04.2019 12:26
> Předmět: Re: [talk-cz]Jak na rekonstrukce multipolygonů (outer z 
> neuzavřených cest)
>
>Ne, myslím tím outer který vypadá takhle:
>[image: 2019-04-30_115906.png]
>
>Tohle je konkrétně relace 25301
>
>
>JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci ani
>nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci nepobere).
>V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
>moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
>omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
>Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
>rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.
>
>Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
>zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
>50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
>přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
>znovu s tím, že ten les bude rozbitý už napořád.
>
>V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
>klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
>se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše to
>nepůjde.
>
>Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.
>
>Majka
>
>
>On Tue, 30 Apr 2019 at 11:06, Marián Kyral  wrote:
>
>> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>>
>> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
>> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě. No a
>> velké lesy mívají těch uzlů mnohem více.
>>
>> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
>> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
>> polygony.
>>
>> Díky,
>> Marián
>>
>> -- Původní e-mail --
>> Od: majka 
>> Komu: talk-cz@openstreetmap.org
>> Datum: 30. 4. 2019 10:29:20
>> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených
>> cest)
>>
>> Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
>> multipolygony (specificky lesy), u kterých outer není oblast, ale je to
>> tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané i
>> ty inner.
>> Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
>> případně při upravení polohy cest či rezidenčních oblastí (protože bývají
>> nalepené i na ně) strašně jednoduše rozbijí.
>>
>> Když jsem opravovala poslední takový, strávila jsem s tím doslova půl dne
>> práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala
>> kontrola toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o
>> jediný les, jen nám ho momentálně protnula stavba dálnice a na jiném místě
>> z něj "ukousala" pole a výstavba.
>>
>> Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem jsou
>> v podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy hranice
>> mění poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné je
>> to většinou dost snadno zrovna podle toho lpis.
>> ___
>> 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 

Re: [Talk-it] percorso su spiaggia

[Alfredo Gattai]

Spesso in questi casi, c'e' una porzione di spiaggia (che dalle mie parti
puo' facilmente essere costituita da ciottoli, ciottoloni o scogli) che
risulta essere piu' calpestata proprio per il passaggio. Se fosse
individuabile sarebbe l'ideale, altrimenti pace...

On Tue, Apr 30, 2019 at 11:35 AM Cascafico Giovanni 
wrote:

> Sarei per il
> highway=path
> surface=sand
> trail_visibility=no
>
> Il mar 30 apr 2019, 05:32 Gabriele via Talk-it 
> ha scritto:
>
>> Buongiorno,
>> sto mappando un percorso escursionistico che passa per una parte sulla
>> spiaggia [0]: come lo mappo? Aggiungo un percorso pedonale sulla spiaggia
>> anche se non c'è nulla fisicamente?
>>
>> [0] https://www.viaemisericordiae.org/le-tappe/pomposa/
>>
>>
>> Sent with ProtonMail  Secure Email.
>>
>> ___
>> 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-transit] Ideas for a simplified public transportation scheme

[Dave F via Talk-transit]

On 28/04/2019 17:13, DC Viennablog wrote:

...But in my opinion, as it stands, for bus or tram stops, these relations do 
not make that much sense. As any software should be able to find those 
connections between stops with the same name, the stop areas are quite 
redundent.


Agreed
Using a Vien example: https://www.openstreetmap.org/relation/7463438
As each stop has a unifying name tag each stop can be found & collected 
together.


Even when in a relation, routers still have to iterate each item to find 
if the bus stop is on the correct street


Note this is also an example of public_transport=platform being misused. 
There are no physical platforms, just a shelter with a bench.



For bigger train stations, with differently named bus stops around it, that all 
belong to it in some way, a relation can be useful, but that case is quite rare.

Disagree
There is no connection, other than approximate location. They're 
different modes of transport, different operators.
A passenger may wish to continue their journey using a bus stop hundreds 
of metres way, How far should this relation encompass?
Bus passengers alighting aren't guaranteed to use the train station, 
they may cross the road to get their hair cut.



  Usually the stations would have the same name. If I find the time, I might 
also write a tagging/relation sugesstion that would slightly unclutter the 
tagging, but as we know, there have been many such suggestions so far, and 
there is never a 100% consensus. But no harm in discussing it.

Agreed
It needs discussing as it's a bit of a mess right now.

Cheers
DaveF




Kind Regards
RobinD. (emergency99)

Von: Markus 
Gesendet: Sonntag, 28. April 2019 16:55:02
An: Public transport/transit/shared taxi related topics
Betreff: Re: [Talk-transit] Ideas for a simplified public transportation scheme

On Sun, 28 Apr 2019 at 16:29, Jarek Piórkowski  wrote:

Oh cool - with routing and time estimates and all?

Navigation while travelling doesn't seem to work yet (it says "public
transport navigation is currently in beta"), but it gives you a
preview of the route: walking route, where to get on and off the
vehicle, intermediate stops, estimated walking and driving time and
distance.

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



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


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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[majka]

To je přesně to, o čem jsem začala:
3) vede k problému v tom lese

Pokud smažeš pole (multipolygon, polygon...), většinou smažeš zároveň i tu
hraniční cestu a lesu začne chybět kus outer. Proběhne sice upozorňovací
hláška, ale tak 90% uživatelů naprosto nepochopí proč (neuvědomí si, že to
smazané patřilo i do lesa).

Pro "správnou funkci" stejně skončíš ještě tímhle:
Máš rozbitý les a chybí ti, podle čeho dát hranici. Natrasuješ pole, ale
ten les se nezacelil. Takže musíš popadnout "tužtičku" a dokreslit tu část
hranice lesa a vložit jí do relace lesa. JOSM tě při nahrávání bude navádět
k tomu, že máš tu "novou" cestu spojit s tou hranicí pole (2x cesta na
stejném místě) a pak ještě že máš body na stejném místě a máš to opravit.
Při tom všem musíš o tomhle problému vědět, ty hlášky ti tohle neprozradí
(dávkují ti tam chyby jednotlivě, ale neprozradí ti proč vlastně je to
problém). Nebo se zachováš jako Milan (víš o problému v lese), najdeš tu
díru a budeš se jí snažit zacelit. Takže rozstřihneš tu cestu toho nového
pole, a přidáš ten společný kus zase zpátky do multipolygonu lesa.

Tohle a ten tvůj bod 2) má za výsledek, že další natrasování pole (za rok,
pokud k tomu někdo přijde nebo zkrátka někdy v budoucnosti) stojí před
naprosto stejnou situací.

On Tue, 30 Apr 2019 at 13:23, Marián Kyral  wrote:

> Fakt si nemyslím, že samotné rozkouskování relace lesa je problém. Hlavní
> problémem je to sdílení cest mezi multipolygony.
>
> Možnosti jsou:
> 1) nakreslit nové outer cesty toho lesa, přilepit je na existující pole,
> smazat staré cesty z relace lesa a outer cesty polí sloučit.
> 2) jako 1) jen se bude hlavně pracovat s relacemi polí.
> 3) smazat pole a znova natrasovat.
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

Fakt si nemyslím, že samotné rozkouskování relace lesa je problém. Hlavní
problémem je to sdílení cest mezi multipolygony.




Možnosti jsou:

1) nakreslit nové outer cesty toho lesa, přilepit je na existující pole,
smazat staré cesty z relace lesa a outer cesty polí sloučit.

2) jako 1) jen se bude hlavně pracovat s relacemi polí.


3) smazat pole a znova natrasovat.




Ale všechny tři možnosti mi přijdou docela pracné.




Marián



-- Původní e-mail --
Od: majka 
Komu: OpenStreetMap Czech Republic 
Datum: 30. 4. 2019 13:09:44
Předmět: Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z
neuzavřených cest)
"






On Tue, 30 Apr 2019 at 12:50, Marián Kyral mailto:mky...@email.cz)> wrote:

"

Tak ten les je více méně v pohodě, ale tohle je problém:






"



Já bych řekla, že je to jedno s druhým - protože buď ten les zůstane navěky
tak, jak byl zmapovaný (nikdo si netroufne na to sáhnout), nebo ty změny
okolo (a to navázání) si začne vyžadovat různé "nenormální" metody. A nebo
ty rozkouskované outer zkrátka časem opravíme na souvislou cestu a problém
pak zarazíme v počátku.


Protože co jsem viděla, tak kolem lesa s rozbitým outer se vyskytují i louky
a pole s rozbitým outer (s pravděpodobností hraničící s jistotou). Vychází
to z toho, že se rozbít zkrátka musí, protože ten les potřebuje z té cesty
outer pole/louky jen kus - nebo se musí ten les v téhle části kompletně
překreslit.

A málokdo si to uvědomuje.




Takže bych odhadla, že spíš Milan jen zoufale napravuje ty rozbité lesy, ale
přitom rozbíjí ty pole, protože to je ta cesta, co potřebuje k tomu, aby to
zavřel...


___
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: [OSM-ja] Windows 版 JOSMで使うJava

[ribbon]

On Mon, Apr 08, 2019 at 09:23:02PM +0900, ribbon wrote:

> じゃどうするかというと、Oracleではなくて、OpenJDKを使えと。
> 一応同じものの筈なのですけど、インストールは面倒になるらしい。
> 
> https://qiita.com/shibafu/items/8762636f66d7fef49d59
> 
> ただそれ以外にも、Javaの実装はいくつかあって、さてどれを使うのかな、
> ということになるわけです。

で、結局京都教育大学の案内
https://ipc.kyokyo-u.ac.jp/page/696
から、ZuluのJava 8を使ってみることにしました。インストールしてみましたが、
正常に動いているようです。

ribbon

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

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Dave F via Talk-transit]

On 29/04/2019 16:22, Stephen Sprunk wrote:


Stop areas are supposed to link stop positions to platforms, so a 
router knows which platform you need to take a route that only stops 
on a particular track.  In most cases, this can be inferred by 
proximity, but in some it can't, particularly at very complex stations.


If there needs to be a 'link' (& I'm still not convinced it does), can 
it not be achieved with unifying tags on nodes/ways? Why does it require 
a relation?


Relations were devised to allow items which couldn't be achieved on 
nodes/ways alone (ie routes) not to collect things together. If it can 
be done without relations it makes tagging so much simpler & less prone 
to errors.


Cheers
DaveF

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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[majka]

On Tue, 30 Apr 2019 at 12:50, Marián Kyral  wrote:

> Tak ten les je více méně v pohodě, ale tohle je problém:
>
>
Já bych řekla, že je to jedno s druhým - protože buď ten les zůstane navěky
tak, jak byl zmapovaný (nikdo si netroufne na to sáhnout), nebo ty změny
okolo (a to navázání) si začne vyžadovat různé "nenormální" metody. A nebo
ty rozkouskované outer zkrátka časem opravíme na souvislou cestu a problém
pak zarazíme v počátku.
Protože co jsem viděla, tak kolem lesa s rozbitým outer se vyskytují i
louky a pole s rozbitým outer (s pravděpodobností hraničící s jistotou).
Vychází to z toho, že se rozbít zkrátka musí, protože ten les potřebuje z
té cesty outer pole/louky jen kus - nebo se musí ten les v téhle části
kompletně překreslit.
A málokdo si to uvědomuje.

Takže bych odhadla, že spíš Milan jen zoufale napravuje ty rozbité lesy,
ale přitom rozbíjí ty pole, protože to je ta cesta, co potřebuje k tomu,
aby to zavřel...
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [Talk-lv] Lūgums atritināt atpakaļ 69707503

[Rihards]

On 30.04.19 13:50, Aivars Miška wrote:
> Lauris (https://www.openstreetmap.org/user/Lauris) lūdz palīdzību
> atritināt atpakaļ viņa izmaiņas nr. 69707503 ar kurām samaitāts mežu
> multipoligons Anstrupē un Pācē. Es palīdzēt nemāku.

Atcelts. Rezultātā nekas īpaši slikti vairs neizskatās, bet būtu jauki
pārbaudīt.

> Vai kāds var izglābt?
> 
> Aivars Miška-- 
 Rihards

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

Re: [Talk-transit] Ideas for a simplified public transportation scheme

[Dave F via Talk-transit]

On 29/04/2019 19:39, Markus wrote:

On Mon, 29 Apr 2019 at 17:18, Stephen Sprunk  wrote:

Part of what seems to have started the PTv2 mess is that bus stops were
sometimes mapped on the way and sometimes beside the way, and both cases
were tagged the same.  PTv2 tried to separate those into "platform" and
"stop_position", to bring uniformity across modes.

It would have been a lot easier to just recommend placing stops beside
the road. :)


If there is a problem on the OSM database I believe sorting that problem 
is beneficial rather than 'papering over the cracks' by adding extra 
tags. It may seem quite laborious, but just as quick as adding those tags.






We need platforms beside the way so routers can get people to/from the
stop on foot.  This is a big deal because trains are long and can
usually be boarded along their entire length, unlike buses where a node
often suffices.

OTOH, we need stop positions so routers can get people from stop to stop
on the buses/trains.

Routers just need the platforms (the places beside the road) because
the journey begins and ends there.


Please clarify what you mean by 'platforms'? Many UK bus stops are 
merely signs clamped to telegraph poles. In rural areas there may not 
even be a pavement, let alone a raise platform. Please remember that we 
should be mapping the physical world. PT schema should fit in with 
what's actually there.



  Stop positions (on the road) are
irrelevant for routing. If someone, for whatever reasons, needs the
stop positions, they can be calculated (projection of the stop node or
centroid of the platform to the highway or railway way).


Wouldn't a stop position be easier to locate if it's a node on the 
highway, rather than an imaginary, offset 'platform'?


Please show me a router which uses platforms as I'm struggling to see 
the benefits atm.


Cheers
DaveF

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

[Talk-lv] Lūgums atritināt atpakaļ 69707503

[Aivars Miška]

Lauris (https://www.openstreetmap.org/user/Lauris) lūdz palīdzību atritināt 
atpakaļ viņa izmaiņas nr. 69707503 ar kurām samaitāts mežu multipoligons 
Anstrupē un Pācē. Es palīdzēt nemāku.


Vai kāds var izglābt?

Aivars Miška 



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

Re: [OSM-talk-fr] Ajout de panneaux d'affichage libre

[gouessej]

Bonjour

 

Une partie des données vient directement de mes propres relevés donc libre à 
moi de choisir une licence adaptée à l'usage que je veux en faire, ça ne pose 
pas de problème.

 

Je n'utilise pas Google Maps.

 

Je n'ai rien contre JOSM, c'est juste que ça me va très bien de passer par 
l'API et ça me permettra de proposer des façons de faire qui marchent avec la 
dernière version. De toute façon, sur certaines des premières communes 
concernées, il n'y a pas un seul panneau d'affichage libre déjà entré dans 
OpenStreetMap.

 

J'accepte la proposition de Paul pour éviter de polluer la liste avec des 
tonnes d'échanges, il sait très bien ce qu'il fait.

 

Les zones de mes imports touchent plusieurs communes du 93 dont Romainville, 
quelques autres communes dans d'autres départements d'Île-de-France hors Paris 
(excepté peut-être un emplacement dans le 20ème), une commune du Bas-Rhin 
(Erstein), Dieppe (76), ...

 

Je vais commencer par les imports de mes propres données, ça posera moins de 
problèmes et ça me permettra de valider la méthodologie.
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[majka]

Ne, myslím tím outer který vypadá takhle:
[image: 2019-04-30_115906.png]

Tohle je konkrétně relace 25301


JOSM mi zahlásil konflikt, předpokládám že to bylo tímhle. iD tu relaci ani
nevidí (resp. vidí že ta cesta je součástí relace, ale tu relaci nepobere).
V konkrétním případě je to ještě přilepené na křižovatku v obci a nejde to
moc jednoduše odlepit bez toho, že se rozbije ten les. Není to z důvodu
omezení počtu bodů - pokud ten outer zkombinuji, sice těsně, ale vyjde to.
Pro takovéhle roztříštění to není důvod, navíc ten les by mohl být i
rozdělený na několik částí. Minimálně na dvě, kde hranice je II/143.

Není to problém Traceru, ale tím, co uživatel udělá dál (tracer většinou
zahlásí, že ta pole v okolí natrasovat neumí). Řekla bych, že pak je to
50:50 jestli od toho uživatel uteče, nebo ten polygon, co mu nejde
přetrasovat smaže a tím "ukradne" tu jednu cestu z relace a natrasuje to
znovu s tím, že ten les bude rozbitý už napořád.

V tomhle místě jsem to začala editovat (vlastně kvůli tomu nedostavěnému
klášteru). Chtěla jsem toho pak opravit víc, ale zavřela jsem to s tím, že
se na to podívám zítra, jestli u nás bude ještě pršet. Protože jednoduše to
nepůjde.

Těchhle multipolygonů lesa máme poměrně dost, narážím na ně poměrně často.

Majka


On Tue, 30 Apr 2019 at 11:06, Marián Kyral  wrote:

> Myslíš takové ty multipologony, které sdílejí společné outer cesty?
>
> To je něco jiného, než když je outer cesta multipolygonu rozdělena.
> Většinou to způsobeno interním omezením max 2000 uzlů v jedné cestě. No a
> velké lesy mívají těch uzlů mnohem více.
>
> Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
> multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
> polygony.
>
> Díky,
> Marián
>
> -- Původní e-mail --
> Od: majka 
> Komu: talk-cz@openstreetmap.org
> Datum: 30. 4. 2019 10:29:20
> Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených
> cest)
>
> Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
> multipolygony (specificky lesy), u kterých outer není oblast, ale je to
> tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané i
> ty inner.
> Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
> případně při upravení polohy cest či rezidenčních oblastí (protože bývají
> nalepené i na ně) strašně jednoduše rozbijí.
>
> Když jsem opravovala poslední takový, strávila jsem s tím doslova půl dne
> práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala
> kontrola toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o
> jediný les, jen nám ho momentálně protnula stavba dálnice a na jiném místě
> z něj "ukousala" pole a výstavba.
>
> Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem jsou
> v podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy hranice
> mění poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné je
> to většinou dost snadno zrovna podle toho lpis.
> ___
> 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-it] via crucis

[Martin Koppenhoefer]

Am Di., 30. Apr. 2019 um 12:08 Uhr schrieb Gabriele via Talk-it <
talk-it@openstreetmap.org>:

> Ok, sostituisco con image allora
> I numeri non li metto perche' i pilastri sono 8, non sono numerati e non
> seguono prprio la struttura ufficiale delle stazioni
>


è una via crucis?
Secondo wikipedia le vie crucis sono composte di 12, 14 oppure 15 stazioni:
https://it.wikipedia.org/wiki/Via_Crucis#Stazioni_della_Via_Crucis

il tag "image" serve per dare l'indirizzo di una foto. "yes" non è un
valore secondo il wiki. Cosa vorresti esprimere con questo tag, che ci sia
un'immagine?

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

Re: [Talk-it] Uso della Strava Heatmap

[solitone]

On 30 Apr 2019, at 11:34, suburbanstu...@runbox.com wrote:
> Personalmente resto dell'opinione che l'heatmap sia un ottima risorsa per 
> valutare o meno passaggi reali - sottobosco ecc - ma non possa essere 
> utilizzato via "desktop" per mappare perchè oggettivamente non si ha la 
> percezione dei luoghi…

E’ utile quando si conoscono i posti. Di solito la uso per migliorare il 
posizionamento dei punti delle way da cui sono passato e di cui ho registrato 
una mia traccia GPS. Inoltre permette di scoprire sentieri non ancora mappati, 
da cui passare al prossimo giro per poi aggiungerli in OSM.
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] via crucis

[Gabriele via Talk-it]

Ok, sostituisco con image allora
I numeri non li metto perche' i pilastri sono 8, non sono numerati e non 
seguono prprio la struttura ufficiale delle stazioni

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday 30 April 2019 12:04, Martin Koppenhoefer  
wrote:

> Si, solitamente hanno numeri da 1 a 14, in certi casi anche 15 
> (ressurezione). Se non ci sono questi numeri li potresti omettere, ma io li 
> vedo quasi sempre (talvolta sono numeri latini).
> Vedi per esempio qui: https://www.openstreetmap.org/relation/9529492
>
> Poi ho notato che hai inserito il tag "picture=yes" sulle singole stazioni, 
> ma non è definito, anzi sembrerebbe da taginfo che tutti gli usi si sono 
> sbagliati e volevano usare "image". La pagina wiki di picture infatti inoltra 
> a image:
> https://wiki.openstreetmap.org/w/index.php?title=Key:picture=no
>
> Ciao,
> Martin___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] via crucis

[Martin Koppenhoefer]

Si, solitamente hanno numeri da 1 a 14, in certi casi anche 15
(ressurezione). Se non ci sono questi numeri li potresti omettere, ma io li
vedo quasi sempre (talvolta sono numeri latini).
Vedi per esempio qui: https://www.openstreetmap.org/relation/9529492

Poi ho notato che hai inserito il tag "picture=yes" sulle singole stazioni,
ma non è definito, anzi sembrerebbe da taginfo che tutti gli usi si sono
sbagliati e volevano usare "image". La pagina wiki di picture infatti
inoltra a image:
https://wiki.openstreetmap.org/w/index.php?title=Key:picture=no

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

Re: [Talk-it] percorso su spiaggia

[Cascafico Giovanni]

Sarei per il
highway=path
surface=sand
trail_visibility=no

Il mar 30 apr 2019, 05:32 Gabriele via Talk-it 
ha scritto:

> Buongiorno,
> sto mappando un percorso escursionistico che passa per una parte sulla
> spiaggia [0]: come lo mappo? Aggiungo un percorso pedonale sulla spiaggia
> anche se non c'è nulla fisicamente?
>
> [0] https://www.viaemisericordiae.org/le-tappe/pomposa/
>
>
> Sent with ProtonMail  Secure Email.
>
> ___
> 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] Uso della Strava Heatmap

[suburbanstudio]

On 27/04/2019 23:02, Alessandro P. via Talk-it wrote:

Il 27/04/19 19:36, solitone ha scritto:

On 26 Apr 2019, at 21:54, Any File  wrote:

a leggere la discussione su twitter non mi pare affatto che
quello che viene detto possa essere presa come un'autorizzazione
formale.
Infatti, ho cercato anch’io un po’ in giro e tutto viene fuori da un 
paio di tweet di dipendenti di Strava. Non c’è mai stata 
un’autorizzazione ufficiale. Ho chiesto direttamente a Strava, ma per 
ora non mi hanno risposto.




Mah, è piuttosto strano che qualche dipendente abbia creato strumenti 
per utilizzare le tracce di Strava senza che loro non se ne siano resi 
conto

https://strava.github.io/iD/#background=Bing=15.82/-122.0450/37.2711


...in effetti.
La versione di ID-strava slide ed il relativo algoritmo di 
autocorrezione era stato creato da Paul Mach, ma attualmente non è più 
aggiornato.
Qui ci sono alcuni riferimenti dove si capisce che Strava  ha chiesto di 
firmare un "developer agreement"  ma la cosa sembra non si sia mai 
conclusa...

https://github.com/paulmach/slide/issues/12
Personalmente resto dell'opinione che l'heatmap sia un ottima risorsa 
per valutare o meno passaggi reali - sottobosco ecc - ma non possa 
essere utilizzato via "desktop" per mappare perchè oggettivamente non si 
ha la percezione dei luoghi...


Sul tema non riesco ad esempio ad utilizzare la STRAVA heatmap 
aggiornata come TMS  layer su QGIS ma soltanto attraverso JOSM con la 
procedura ormai nota.


A qualcuno funziona ?

M.






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

Re: [Talk-it] via crucis

[Gabriele via Talk-it]

Ref cioe' una sorta di numero identificativo per ordinarli da 1 alla fine?

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday 30 April 2019 11:26, Martin Koppenhoefer  
wrote:

> Am Di., 30. Apr. 2019 um 10:45 Uhr schrieb Gabriele via Talk-it 
> :
>
>> Cercando di sommare tutti i consigli per ora l'ho mappata cosi' [0]. 
>> Considerate che non sono proprio solo pilastrini: ognuno in realta' ha un 
>> quadretto all'interno coperto da uno sportellino di legno apribilie. Grazie 
>> a tutti per i consigli! Fatemi sapere anche come vi sembra.
>>
>> [0] https://www.openstreetmap.org/relation/9527983
>
> mi sembra buono. Metterei anche "ref" ai nodi / stazioni.
>
> Ciao,
> Martin___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] via crucis

[Martin Koppenhoefer]

Am Di., 30. Apr. 2019 um 10:45 Uhr schrieb Gabriele via Talk-it <
talk-it@openstreetmap.org>:

> Cercando di sommare tutti i consigli per ora l'ho mappata cosi' [0].
> Considerate che non sono proprio solo pilastrini: ognuno in realta' ha un
> quadretto all'interno coperto da uno sportellino di legno apribilie. Grazie
> a tutti per i consigli! Fatemi sapere anche come vi sembra.
>
> [0] https://www.openstreetmap.org/relation/9527983
>
>

mi sembra buono. Metterei anche "ref" ai nodi / stazioni.

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

Re: [OSM-talk-fr] Ajout de panneaux d'affichage libre

[Vincent de Château-Thierry]

Bonjour et bienvenue,

> De: goues...@orange.fr
> 
> Il m'a été fortement recommandé de vous prévenir de mon ajout de
> plusieurs dizaines (centaines?) d'emplacements de panneaux
> d'affichage libre dans OpenStreetMap sous peu. J'ai lu les consignes
> et les commentaires de membres de plusieurs forums sur la façon de
> les qualifier. Je peux vous montrer un échantillon si vous le
> souhaitez. J'ai plusieurs fichiers au format geojson que je vais
> convertir au format XML OsmChange. Je sais utiliser l'API en ligne
> de commande avec Curl, j'ai même trouvé comment faire marcher ça
> avec la version 0.6 de l'API alors que le wiki mentionne des
> exemples qui marchent uniquement avec la version 0.5. Je connais
> JOSM, je l'ai installé au cas où mais je ne pense pas qu'il me sera
> utile pour le téléversement. Je ferai des essais sur une version de
> test. Je (re)vérifierai que je ne risque pas d'écraser les
> contributions d'autres personnes. Une fois prêt, j'enverrai un
> message électronique à impo...@openstreetmap.org à moins que vous me
> disiez que ce ne sera pas nécessaire. Je pense téléverser les
> emplacements par groupe de 30 à peu près ou bien commune par
> commune. Si vous pensez que j'oublie quelque chose d'important,
> n'hésitez pas à me le faire savoir, je ne suis pas encore un habitué
> et j'ai beaucoup à apprendre.

Comme le fait remarquer marc marc la première question à se poser est celle de 
la licence associée à tes données, et donc de la possibilité de les ajouter à 
OSM sans enfreindre cette licence. Une fois cette question traitée, et s'il se 
vérifie qu'elle ne pose pas d'obstacle, arrivent les points techniques, sur la 
qualité des données et sur la méthode.
Pour la qualité, quid du positionnement géométrique de tes panneaux ? 
Connais-tu la méthode de positionnement utilisée par ton fournisseur ? Collecte 
terrain, géocodage, positionnement sur Google Maps (et dans ce cas le point 
"licence" serait bloquant) ? On peut essayer de répondre globalement à la 
question du positionnement géométrique, mais le plus fiable reste de passer en 
revue tes points *un par un*.
Dans ce sens j'ai du mal pour la méthode à trouver des intérêts à curl au 
détriment de JOSM. JOSM avec son plugin 'TODO list' [1] est fait pour ça : 
passer en revue des objets avec le moyen simple de ne pas en oublier. C'est 
bien plus fastidieux qu'un bulk-import, mais ça permet de parler d'intégration 
plutôt que d'import et c'est souhaitable. Le processus inclut alors, de fait, 
du repositionnement manuel, du dédoublonnage, de la consolidation.

À te lire,
vincent

[1] : https://wiki.openstreetmap.org/wiki/JOSM/Plugins/TODO_list

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

Re: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[Marián Kyral]

Myslíš takové ty multipologony, které sdílejí společné outer cesty?




To je něco jiného, než když je outer cesta multipolygonu rozdělena. Většinou
to způsobeno interním omezením max 2000 uzlů v jedné cestě. No a velké lesy
mívají těch uzlů mnohem více.




Máš nějaký příklad? Mrknul bych na to. Měl jsem za to, že tyhle
multipolygony (speciálně lesy) tracer ignoruje. Podporuje jen uzavřené
polygony.





Díky,

Marián



-- Původní e-mail --
Od: majka 
Komu: talk-cz@openstreetmap.org
Datum: 30. 4. 2019 10:29:20
Předmět: [talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených
cest)
"
Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
multipolygony (specificky lesy), u kterých outer není oblast, ale je to
tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané i
ty inner.
Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
případně při upravení polohy cest či rezidenčních oblastí (protože bývají
nalepené i na ně) strašně jednoduše rozbijí.




Když jsem opravovala poslední takový, strávila jsem s tím doslova půl dne
práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala kontrola
toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o jediný les, jen
nám ho momentálně protnula stavba dálnice a na jiném místě z něj "ukousala"
pole a výstavba. 




Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem jsou v
podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy hranice mění
poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné je to
většinou dost snadno zrovna podle toho lpis.

___
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: [OSM-talk-fr] hauteur minimale de pont/tunnel

[Yves P.]

> Marc, merci ça me semble la meilleure solution. unsigned=maxheight et 
> maxheight=default peut bien dire >=4,30 m.
> 
Le wiki  parle uniquement du 
fait qu’un objet n’a pas de nom. L’usage va dans ce sens (cf. valeurs dans 
TagInfo ).
Je ne mettrais donc pas unsigned=*
> Avec maxheight=default, Osmose devrait déjà être content.
> 
Est-ce le seul (?) moyen d’indiquer que la hauteur maxi n’est justement pas 
indiquée (et qu’on est aller le vérifier sur place ?).
Est-il possible de trouver cette info en OD ?

Le plus simple n’est-il pas d’ignorer le message d’Osmose ?
> Je viens à cette occasion d'apprendre un autre tag : unsigned_ref pour les 
> numéros de routes non signalé sur le terrain. C'est le cas typiquement des 
> chemins d’exploitation.
> 
La carte de TagInfo  
montre un usage aux USA et en Pologne.
Est-ce important (du moins en France) de savoir (ou pas) que la référence soit 
physiquement indiquée par un panneau (ou qu’elle provienne d’OD…) ?

—
Yves

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

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

Re: [Talk-it] via crucis

[Gabriele via Talk-it]

Cercando di sommare tutti i consigli per ora l'ho mappata cosi' [0]. 
Considerate che non sono proprio solo pilastrini: ognuno in realta' ha un 
quadretto all'interno coperto da uno sportellino di legno apribilie. Grazie a 
tutti per i consigli! Fatemi sapere anche come vi sembra.

[0] https://www.openstreetmap.org/relation/9527983

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Tuesday 30 April 2019 10:41, Martin Koppenhoefer  
wrote:

> Am Di., 30. Apr. 2019 um 06:34 Uhr schrieb canfe :
>
>> Essendo di 'pari grado' come luogo devozionale, cambia solo la fattispecie
>> architettonica, sarebbe impensabile un
>>
>> wayside_niche ?
>
> sarebbe un'alternativa, dal punto di vista semantico eventualmente anche 
> meglio, ma con il rischio di non farcela mai (di entrare nelle applicazioni 
> diffusi con questo tag) ;-)
> Ci potremmo tentare.
>
> Ciao,
> Martin___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] via crucis

[Martin Koppenhoefer]

Am Di., 30. Apr. 2019 um 06:34 Uhr schrieb canfe :

> Essendo di 'pari grado' come luogo devozionale, cambia solo la fattispecie
> architettonica, sarebbe impensabile un
>
> wayside_niche ?
>


sarebbe un'alternativa, dal punto di vista semantico eventualmente anche
meglio, ma con il rischio di non farcela mai (di entrare nelle applicazioni
diffusi con questo tag) ;-)
Ci potremmo tentare.

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

Re: [Talk-it] motor_vehicle da imagery?

[Daniele Santini]

Il mar 30 apr 2019, 10:01  ha scritto:

 Non ho capito però se qualcuno ha
già scritto a osm-edit-escalati...@amazon.com


L'ho fatto io. Questa è la risposta:

> My team is working in Italy and our edits are made based on driver
> feedback or from driver GPS traces. Due to legal constraints of
> representing drivers information we were not adding this as a source in
> changeset comments. We are working with our legal team to clear this
> constraint and be as transparent as possible. Before making any changes to
> OSM we also verify the drivers information with sources available in OSM
> such as Satellite imagery and Street Level imagery for confirmation. Hope
> this answers your question on adding motor vehicle access for Unmaintained
> Track roads.


--
Daniele Santini
http://www.dsantini.it
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [talk-cz] WeeklyOSM CZ 456

[Miroslav Suchy]

Dne 30. 04. 19 v 10:19 majka napsal(a):
> Až na to, že ten dotaz je kanónem na vrabce. Protože 99% těchhle objektů 
> jméno mít nebude...
> Osobně bych to pro zjednodušení omezila na silnice I. třídy a vyšší, ale ten 
> předchozí problém zůstane, jen nevyskočí
> každý můstek na polňačce.

V obci to dává většinou špatné výsledky
Ale mimo obec to mimo obec, to je téměř vždy zásah - teda aspoň v mém okolí. 
Polňačky obvykle nemají jméno, takže pokud
je na polňačce na mostě jméno, tak je to skoro vždy jméno mostu.
Pokud bych to měl zpřesňovat tak bych tam spíše dal regexp na name~="(m|M)ost".

Mirek

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

[talk-cz] Jak na rekonstrukce multipolygonů (outer z neuzavřených cest)

[majka]

Má někdo nápad, jak nejlépe, resp. nejsnadněji opravit/rekonstruovat
multipolygony (specificky lesy), u kterých outer není oblast, ale je to
tvořené jednotlivými cestami? V horším případě jsou takhle zoufale dělané i
ty inner.
Tyhle multipolygony se v případě přetrasování okolních polí přes lpis,
případně při upravení polohy cest či rezidenčních oblastí (protože bývají
nalepené i na ně) strašně jednoduše rozbijí.

Když jsem opravovala poslední takový, strávila jsem s tím doslova půl dne
práce, a nahrávala jsem to na několikrát. Další dva dny pak zabrala
kontrola toho, jestli se něco i přesto nerozbilo. Přitom se jednalo o
jediný les, jen nám ho momentálně protnula stavba dálnice a na jiném místě
z něj "ukousala" pole a výstavba.

Opravu by to chtělo, protože multipolygony zmapované tímhle způsobem jsou v
podstatě pro běžného uživatele needitovatelné, a zrovna ty lesy hranice
mění poměrně dost, tedy při pohledu na podrobnější mapu. A zmapovatelné je
to většinou dost snadno zrovna podle toho lpis.
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] WeeklyOSM CZ 456

[majka]

Až na to, že ten dotaz je kanónem na vrabce. Protože 99% těchhle objektů
jméno mít nebude...
Osobně bych to pro zjednodušení omezila na silnice I. třídy a vyšší, ale
ten předchozí problém zůstane, jen nevyskočí každý můstek na polňačce.

"Správně" by bylo prohledat i napojené cesty, a porovnat name (u
tunelu/mostu) s name na vedlejší silnici stejné kategorie. Jen kde se to
liší, se dá předpokládat, že to na tunelu/mostu je jméno specifické pro
tenhle objekt.

On Tue, 30 Apr 2019 at 10:12, Miroslav Suchy  wrote:

> Dne 30. 04. 19 v 9:27 Tom Ka napsal(a):
> > * Tagování jmen mostů a tunelů.
>
> Tohle je zajímavé. Pokud by někdo chtěl ve svém okolí upravovat name=* na
> bridge:name=* - což bohužel nejde
> automatizovaně - tak jsem připravil tento dotaz:
>
>
>   https://overpass-turbo.eu/s/Ioc
>
> way["bridge"="yes"]["name"][! "bridge:name"]({{bbox}});
>
> Mirek
>
___
talk-cz mailing list
talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz
https://openstreetmap.cz/talkcz

Re: [talk-cz] WeeklyOSM CZ 456

[Miroslav Suchy]

Dne 30. 04. 19 v 9:27 Tom Ka napsal(a):
> * Tagování jmen mostů a tunelů.

Tohle je zajímavé. Pokud by někdo chtěl ve svém okolí upravovat name=* na 
bridge:name=* - což bohužel nejde
automatizovaně - tak jsem připravil tento dotaz:


  https://overpass-turbo.eu/s/Ioc

way["bridge"="yes"]["name"][! "bridge:name"]({{bbox}});

Mirek

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

Re: [Talk-it] motor_vehicle da imagery?

[Martin Koppenhoefer]

sent from a phone

> On 30. Apr 2019, at 09:39, Andrea Musuruane  wrote:
> 
> Ciao a tutti,
> ho trovato anche io una track a cui è stato aggiunto motor_vehicle=yes. 
> Questa modifica però è stata fatta da un altro dipendente Amazon Logistics: 
> mhdrahm. Questo potrebbe implicare che ci siano alcune guidelines interne per 
> l'aggiunta di questo tag. Comunque concordo con Volker che queste modifiche 
> non ha senso perché track implica già motor_vehicle=yes. Avrebbe più senso 
> aggiungere il tag tracktype. Non ho capito però se qualcuno ha già scritto a 
> osm-edit-escalati...@amazon.com


per me la priorità sarebbe surface, poi tracktype. Francamente non capisco il 
problema di aggiungere motor_vehicle=yes ad un track.
Da un punto di vista internazionale non è scontato che i track siano 
accessibili, per esempio in alcuni Länder della Germania (esempio 
Baden-Württemberg) l’utilizzo dei track è vietato ai motor_vehicle anche in 
assenza di segnaletica (assurdo, concordo).
Anche qui ho riscontrato spesso track dietro delle sbarre o cancelli e con 
divieti espliciti, ma senza i tags in OpenStreetMap.

Se guardi nella wiki, si consiglia esplicitamente di aggiungere gli access tags 
ai track. (How to map)


Ciao, Martin 


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

Re: [Talk-it] motor_vehicle da imagery?

[Andrea Musuruane]

Ciao a tutti,
ho trovato anche io una track a cui è stato aggiunto motor_vehicle=yes.
Questa modifica però è stata fatta da un altro dipendente Amazon Logistics:
mhdrahm. Questo potrebbe implicare che ci siano alcune guidelines interne
per l'aggiunta di questo tag. Comunque concordo con Volker che queste
modifiche non ha senso perché track implica già motor_vehicle=yes. Avrebbe
più senso aggiungere il tag tracktype. Non ho capito però se qualcuno ha
già scritto a osm-edit-escalati...@amazon.com

Ciao,

Andrea


On Mon, Apr 29, 2019 at 9:44 AM Volker Schmidt  wrote:

> Nella nostra zona, tante "strade bianche", tipicamente a corsia singola,
> servono sia come strade di collegamento (quindi sarebbero "unclassified"),
> spesso ci sono anche case abitate (quindi sarebbero "residential") e ci
> passano anche veicoli agricoli per andare ai campi locali (sarebbero
> "track").
> Il primo esmpio in questa conversazione ( 2] 
> https://www.openstreetmap.org/changeset/69641423)
> 
> mi sembra un classico.
>
> Il punto importante è che aggiungendo motor_vehicle=yes a un
> highway=track, o anche un altra strada, è informazione ambigua perché il
> default access per track include motor_vehicle. Se vogliamo  documentare
> che qualcuno ha verificato che un track o una stradina è veramente aperto a
> specifiche categorie di veicoli, besogna utilizzare tag aggiuntivi
> (potrebbe essere "source:motor_vehicle=survey|sign|local_knowledge").
> Il problema rimane anche con questo tipo di soluzione che la mappa
> contiene tanti highway "inferiori" cui diritti di accesso non sono stati
> controllati dai mappatori che titpicamente hanno utilizzato foto
> satellitari o simili.
>
> Il metodo di verificazione di Amazon è valido, il mio dubbio è il tagging
> del risultato della verifica.
>
> Volker
>
>
>
> On Mon, 29 Apr 2019 at 08:41, emmexx  wrote:
>
>> On 04/28/2019 06:23 PM, lomastr...@gmail.com wrote:
>> > Ce ne sono diversi di Amazon che fanno questa operazione, credo che
>> > serva a garantire il routing sulle track. Probabilmente un corriere che
>> > ha consegnato lungo quella via ha segnalato che è transitabile.
>>
>> Avevo segnalato la vecchia discussione perché conteneva il riferimento
>> alla pagina wiki di Amazon:
>>
>> https://wiki.openstreetmap.org/wiki/Amazon_Logistics
>>
>> "We contribute edits in North America, Great Britain, France, Italy,
>> Spain and Germany. The mappers are Indian nationals."
>>
>> "We use driver feedback as our primary source in making edits (e.g.
>> driver feedback about road names, turn restrictions, directionality
>> while delivering to our customers). We also use GPS traces from our
>> drivers to identify missing roads. Once a potential missing road has
>> been identified we use OSM resources to confirm if that particular road
>> segment exists before making any edits. In absence of strong evidence,
>> we do not make any edits."
>>
>> "We make an edit only if there is ground data available and all edits
>> are reviewed by a second level reviewer/auditor. We also have a team of
>> GIS experts who audit a random sample of reviewed cases to ensure high
>> standards of our edits to OSM."
>>
>> > Non ci vedo niente di male nell'esplicitare un valore di accesso
>> > altrimenti ambiguo anche se secondo me nella maggior parte dei casi sono
>> > strade etichettate erroneamente come track solo perché non asfaltate e
>> > sarebbe meglio rietichettarle come unclassified o altro.
>>
>> track e unclassified non sono la stessa cosa. E nulla vieta che track
>> sia asfaltata. La differenza sta nella destinazione d'uso (prevalente)
>> della strada. Se l'uso prevalente è agricolo allora si tratta di track.
>> Se si tratta di una strada che serve per connettere zone diverse a
>> livello locale allora si tratta di unclassified anche se non è asfaltata.
>>
>> Il fatto che qualcuno di amazon sia passato da quella strada non la
>> rende automaticamente unclassified.
>>
>> ciao
>> maxx
>>
>>
>> ___
>> 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-cz] WeeklyOSM CZ 456

[Tom Ka]

Ahoj, je dostupné vydání 456 týdeníku WeeklyOSM:

https://weeklyosm.eu/cz/archives/11906

* Novinky webu osmap.cz.
* Úklid leisure=common v CZ.
* Odbočky z turistické trasy.
* Tradiční regiony Slovenska.
* Víceúčelové place=locality.
* Mazání wiki stránek a souborů.
* Měření zmapovanosti.
* Termíny pro SotM v Heidelbergu.
* Mikrogranty HOT 2019.
* Kategorizace poznámek OSM.
* Tagování jmen mostů a tunelů.
* Kolik stojí mapy Google?

Pěkné počtení ...

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

Re: [OSM-talk-fr] Ajout de panneaux d'affichage libre

[Erwan]

Intéressé par le sujet aussi
D’ailleurs je devrais corriger mes tags ...
Quels sont les zones de tes imports ?

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

Re: [Talk-it] percorso su spiaggia

[Martin Koppenhoefer]

sent from a phone

> On 30. Apr 2019, at 05:32, Gabriele via Talk-it  
> wrote:
> 
> Buongiorno,
> sto mappando un percorso escursionistico che passa per una parte sulla 
> spiaggia [0]: come lo mappo? Aggiungo un percorso pedonale sulla spiaggia 
> anche se non c'è nulla fisicamente?


io farei probabilmente così.

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

Re: [OSM-talk-fr] Ajout de panneaux d'affichage libre

[Paul Desgranges]

Bonjour
J'avais travaillé sur ce sujet. J'avais traduit, documenté, enrichi, 
rédigé aussi pas mal du wiki sur le tag "*advertising*", voir par exemple :


 * https://wiki.openstreetmap.org/wiki/FR:Key:advertising
 * https://wiki.openstreetmap.org/wiki/FR:Key:legal_type
 * 
https://wiki.openstreetmap.org/wiki/FR:Key:legal_type#Affichage_d.27opinions_et_publicit.C3.A9_relative_aux_activit.C3.A9s_des_associations_sans_but_lucratif

mais sans être arrivé à porter le débat complètement sur tout ceci, et 
construire un consensus réel sur certains points, très peu de gens 
connaissent le sujet. Comme je suis membre aussi d'une association de 
défense du paysage, j'ai une petite connaissance de la publicité 
extérieure de manière générale en France et par extension aussi des 
panneaux d'affichage libre. La dénomination "panneau d'affichage libre" 
n'existe pas vraiment, c'est un raccourci, puisque on parle dans la 
réglementation de "Affichage d'opinions et publicité relative aux 
activités des associations sans but lucratif". Cette dénomination a un 
sens précis. Puisque ces panneaux sont dans l'espace public, exposé au 
regard de tous, c'est une forme de publicité aussi, même si non 
commerciale et donc ces panneaux doivent rentrer aussi dans le champ du 
tag "advertising" avec des attributs supplémentaires pour le qualifier 
complètement. J'avais renseigné dans OSM tous (ou presque) les panneaux 
d'affichage libre de Grenoble dans OSM, en me basant sur les données 
OpenData de la métropole de Grenoble et en vérifiant sur le terrain. 
Bref ça m'intéresse beaucoup ce que tu fais, et je veux bien regarder 
ton échantillon avant que tu fasses l'import. On peut peut-être en 
discuter d'abord en direct, si tu le souhaites, et puis après porter nos 
conclusions sur osm-talk-fr dans un second temps, bon enfin comme tu 
veux...

Cordialement

Paul


Le 29/04/2019 à 22:02, goues...@orange.fr a écrit :

Bonsoir

Il m'a été fortement recommandé de vous prévenir de mon ajout de plusieurs 
dizaines (centaines?) d'emplacements de panneaux d'affichage libre dans 
OpenStreetMap sous peu. J'ai lu les consignes et les commentaires de membres de 
plusieurs forums sur la façon de les qualifier. Je peux vous montrer un 
échantillon si vous le souhaitez. J'ai plusieurs fichiers au format geojson que 
je vais convertir au format XML OsmChange. Je sais utiliser l'API en ligne de 
commande avec Curl, j'ai même trouvé comment faire marcher ça avec la version 
0.6 de l'API alors que le wiki mentionne des exemples qui marchent uniquement 
avec la version 0.5. Je connais JOSM, je l'ai installé au cas où mais je ne 
pense pas qu'il me sera utile pour le téléversement. Je ferai des essais sur 
une version de test. Je (re)vérifierai que je ne risque pas d'écraser les 
contributions d'autres personnes. Une fois prêt, j'enverrai un message 
électronique à impo...@openstreetmap.org à moins que vous me disiez que ce ne 
sera pas nécessaire. Je pense téléverser les emplacements par groupe de 30 à 
peu près ou bien commune par commune. Si vous pensez que j'oublie quelque chose 
d'important, n'hésitez pas à me le faire savoir, je ne suis pas encore un 
habitué et j'ai beaucoup à apprendre.

Cordialement.

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