Re: [Talk-transit] GTFS, tools and pt tags generally

[Paul Johnson]

On Mon, Jun 20, 2016 at 10:51 PM, Stephen Sprunk  wrote:

> On 2016-06-20 16:18, Paul Johnson wrote:
>
>> On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk 
>> wrote:
>>
>>>
>>> The situation with GTFS data itself is so bad that Google stopped
>> offering Navigation for the transit mode in it's own Maps service.
>>
>
> It's still available where I live and several other major cities I
> checked, so perhaps they just disabled it in your area because they
> recognized the GTFS data there was so bad?
>

I mean the realtime, stop-by-stop navigation that was formerly offered.
Even in areas with really good GTFS feeds, this functionality is Just
Gone.  Closest you can get now amounts to basically a static listout of
your trip similar to the paddle used by transit drivers in to familiarize
themselves with the route and schedule; it doesn't follow you in realtime
or take into account when your trip's fallen off schedule and won't make a
transfer now.  Nor will it warn you your stop is coming up.  I remember
this abruptly going away with the last version that had it was Google
Navigation 6.9...


> One example is the dissent on whether the bus stop should be a
 node on the vehicle's way or a node where the passengers wait. You
 will find all solutions implemented, because each local community
 decided different. The "approved scheme" will allow any variant.

>>>
>>> ...
>>>
>>
>> I'm a proponent of it being the location where passengers wait for bus
>> service, and the center of the position the train stops for rail
>> halts, for what it's worth.
>>
>
> Unfortunately, that could create problems if navigation tools think that a
> person has to walk to the center of the platform to actually board the
> train, whereas trains often run the full length of the platform but are
> often shorter (or even longer!) than the platform.
>
> Worse, some trains only allow boarding for mobility impaired persons at
> certain points along the platform, and they may not be able to make it from
> the center to that location within the dwell time.
>
> Worse still, a short train may not even be _present_ at the center of the
> platform if it's short and stops at one end or the other.  While
> improbable, in theory that could lead a vision-impaired person to walk off
> the platform and fall onto the tracks.
>

Most stations I've seen have a canonical tactile map and seeing impaired
users are not putting total faith in either the official tactile map nor
any electronic aid they're using.  Mostly because people and furniture
move, maintenance closes areas, pavement buckles, etc.


> I'm not sure what the solution is, though, so I've been putting the stop
> positions at the center of the platform until someone tells me better.
> FWIW, that seems to be what folks in other cities have done--if they mapped
> any stop positions at all.
>

Portland tends to put the stop position where the lead cab of the lead car
will line up.  However, Portland hits me as a little odd (in terms of west
coast light rail systems) in that there


> Another example are route relations. While there are wild
 constructions called route_master and network which are basically
 collection relations, the problem that bothers most people in
 practice has never been tackled: We would like to see per way segment
 only one or very few relations and need a construction to assemble
 itineraries from that. That would greatly reduce maintenance.

>>>
>>> I'll admit I was a bit annoyed at having to duplicate way data for
>>> several routes where some trips run A-B-C-D, some A-B-C and some
>>> B-C-D; it would have been handy to create segments A-B, B-C and C-D,
>>> and then just include the right ones in each route.  But then I
>>> realized my real complaint was that I had to do this _at all_ when
>>> there's a GTFS feed that has _all_ of that information and could
>>> easily be used to create/update all the relations.  If it's
>>> automated, only developers should have to care how complicated or
>>> repetitive it is; the important thing is that individual mappers
>>> don't, at least in the general case.
>>>
>>
>> Hadn't learned of Route Master before, but this frustration with some
>> routes not going full length or having optional loops or changed route
>> based on time of day or whether or not it's snowing without changing
>> the route name or number actually hit me as one of those, "are you
>> actually kidding me?" kind of moments with Tulsa Transit.  There's one
>> route that has something like six or eight different relations because
>> of this.
>>
>
> It's always baffled me that so many agencies are willing to give the same
> designation to different routes just because they share several stops.
> IMHO, it'd be better to give each variant a suffix so they can be easily
> identified (e.g. route 1A vs route 1B, rather than route 1 to Wherever and
> route 1 to Elsewhere; references without a suffix 

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Andreas Vilén]

I'm using Go Map for quick editing on the go. It's only available for IOS
though: https://wiki.openstreetmap.org/wiki/Go_Map!!

It's pretty much as powerful as iD (at least to my knowledge, I never use
iD for anything more complicated than adding poi's or changing tag values)
and pretty easy to use for smaller edits, or for example adding a shop or
street name on the go.

/Andreas

On Mon, Jun 20, 2016 at 11:49 PM, Andrew Harvey 
wrote:

> On 20 June 2016 at 22:48, Oleksiy Muzalyev 
> wrote:
> > Maps.me editor has got the principal difference from other editors, - it
> can be used without an active Internet connection.
>
> I've been editing in JOSM for years and just started editing with
> Maps.me, and the fact that it's very fast and easy to make the edit is
> the main reason I have. If I walk past a shop, it's very easy to add
> it straight through the app, vs making a note and then spending time
> back home converting that note into mapping in JOSM.
>
> The down side of course is that the Maps.me data isn't updated very
> frequently so I might be duplicating data which has been added after
> Maps.me last generated the data extracts, or potentially already in
> OSM but Maps.me wasn't rendering it (so I thought it didn't exist). I
> think this is something Maps.me should address that if it finds a
> similar tag nearby which was created at a time after your local
> offline data and if so let you know about it before uploading.
>
> It's also frustrating that I can't add key=value tags, as an expert
> user this would be a handy option.
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-transit] GTFS, tools and pt tags generally

[Stephen Sprunk]

On 2016-06-20 16:18, Paul Johnson wrote:

On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk 
wrote:

On 2016-06-20 02:07, Roland Olbricht wrote:

There had been a group that was very vocal for making a textbook
example of design by committee, and the result is now known as
"approved public transport scheme". They did not ask for input
from experienced mappers or developers. I decided to consider it
a waste of time and stopped developing.


I wasn't around at the time, so I can't speak to how it happened,
but the result seems to be a partial implementation of Transmodel,
which distinguishes a _lot_ of different things (and the complex
relationships between them) in excruciating detail because the real
world is, in fact, that complicated.

If one is putting data in by hand, it certainly seems unwieldy.  It
took me over a week to do just a few rail routes in my area, and I'm
still not completely sure I got them right.  I can't imagine trying
to do the hundreds of bus routes too.


I really wonder how TriMet ultimately accomplished this, since that
would seem like a decent-ish starting point since that system is in
charge of a fairly multimodal system with above and below ground
stations, split-level stations, and transit centers of almost every
description.


Same here and many other cities I've looked, so I didn't think it was 
that big of a deal.



One thing that breaks things badly for me in the Tulsa area is the
vast overwhelming majority of stops in the Tulsa Transit (and
presumably other transit systems in the region) GTFS have...literally
zero indication on the ground, there's no way to tell if there is an
actual bus stop (which is typically just a signpost with a bus stop
sign on it), and if it is, whether or not that's verifiable because
the sign's gone missing.


*facepalm*

I have plenty of complaints about the transit agencies where I live, but 
at least they manage to post signs properly and provide proper 
maps/schedules.  Their GTFS data isn't as accurate as I'd hoped, but 
it's obvious they're _trying_ to get it right.



Also, like it or not, Google Maps (and hence GTFS) has set a bar for
what users expect from online maps.  I'd certainly like OSM to be
better, of course, but the current situation is that OSM is
generally far, far worse.


It doesn't help that the only implementations of GTFS that actually
are anywhere near complete are basically the reference implementations
Google did in cooperation with TriMet and Tillamook County Transit,
and adjacent systems that asked TriMet how they did that (like Clark
County Transit, aka C-Tran).


Really?  I've looked at a couple dozen feeds for major US and European 
cities, and they seem to be reasonably complete and accurate.  Then 
again, all of the ones I've looked at so far are ones that offer rail 
services, and the nature of rail implies a high enough level of funding 
that one can probably take things like a decent GTFS feed for granted.  
A small, bus-only agency can run on a shoestring budget where such 
things may be seen as "unnecessary" or "too much effort".



The situation with GTFS data itself is so bad that Google stopped
offering Navigation for the transit mode in it's own Maps service.


It's still available where I live and several other major cities I 
checked, so perhaps they just disabled it in your area because they 
recognized the GTFS data there was so bad?



One example is the dissent on whether the bus stop should be a
node on the vehicle's way or a node where the passengers wait. You
will find all solutions implemented, because each local community
decided different. The "approved scheme" will allow any variant.


...


I'm a proponent of it being the location where passengers wait for bus
service, and the center of the position the train stops for rail
halts, for what it's worth.


Unfortunately, that could create problems if navigation tools think that 
a person has to walk to the center of the platform to actually board the 
train, whereas trains often run the full length of the platform but are 
often shorter (or even longer!) than the platform.


Worse, some trains only allow boarding for mobility impaired persons at 
certain points along the platform, and they may not be able to make it 
from the center to that location within the dwell time.


Worse still, a short train may not even be _present_ at the center of 
the platform if it's short and stops at one end or the other.  While 
improbable, in theory that could lead a vision-impaired person to walk 
off the platform and fall onto the tracks.


I'm not sure what the solution is, though, so I've been putting the stop 
positions at the center of the platform until someone tells me better.  
FWIW, that seems to be what folks in other cities have done--if they 
mapped any stop positions at all.



Another example are route relations. While there are wild
constructions called route_master and network which are basically
collection relations, 

Re: [OSM-talk-be] Radio 2 Programma De Inspecteur & navigatiesystemen

[Marc Gemis]

Ik merkte gisteren dat als je op Geopunt kijkt, een verschillend resultaat
krijgt kwa huisnummers tussen de view die enkel huisnummers toont en
dewelke ook de gebouwen toont. De eerste is juist denk ik als je de foto
bij het krantenartikel bekijkt.

m
Op 20 jun. 2016 22:11 schreef "joost schouppe" :

> Ik kon mij niet inhouden en heb dit berichtje gestuurd naar De Inspecteur:
>
> "Beste inspecteur,
> Naar aanleiding van jullie reportage morgenochtend over problemen met
> gewijzigde straatnamen. Wat GPS-producten doen is hun zaak. De gemeente
> moet het gewoon goed doen in de centrale databank, en wie de weg wil vinden
> in Vlaanderen moet die gebruiken. Maar als de mensen die we ervoor betalen
> het niet goed doen, kan je altijd de data gebruiken die vrijwilligers
> bijhouden. Bij OpenStreetMap houden we dit soort wijzigingen in de gaten,
> en passen vrijwillige kaartenmakers dit aan. Het wordt dan onmiddellijk in
> een wereldwijde database aangepast, die gebruikt wordt in allerlei
> websites, standaard op Garmin wandel-en fiets GPS'en geladen wordt en op
> allerlei manieren op je smartphone (ook zonder internetverbinding) gebruikt
> kan worden!
> Naar aanleiding van jullie spot, heeft iemand van ons dit gemeld aan de
> groep, waarop ikzelf wat onderzoek gedaan heb. Ondertussen zou het juist
> moeten staan op onze kaart, maar in de komende dagen tot weken gaat er
> wellicht iemand eens langs. In het beste geval is die iemand een luisteraar
> die we tijdens jullie programma erop wijzen dat de beste kaart van je buurt
> door jezelf gemaakt wordt.
>
> Met vriendelijke groet,
> Joost Schouppe
> OpenStreetMap vrijwilliger"
>
> Op 20 juni 2016 22:01 schreef joost schouppe :
>
>> Als ik mag veronderstellen dat ze CRAB hebben aangepast, dan zaten wij
>> alvast niet goed. Volgens mij zou onze Sijsjesstraat dan Leeuwerikstraat
>> moeten worden en onze Leeuwerikstraat dan Lijsterstraat.
>>
>> Grappig genoeg is dit de situatie in CRAB zoals weergegeven door de
>> toepassing Lara (vereist account, maar iedereen kan er een maken). In die
>> andere toepassing van hen Geopunt, is de situatie gemapped zoals wij ze
>> hadden. Dus ga ik ervan uit dat wij de oude situatie juist gemapped hadden
>> en dat de basiskaart van Geopunt NIET de kaart van AGIV zelf is. Als je de
>> basiskaart GRB erover legt, ziet het er zo ongeveer uit als in Lara.
>>
>> Dus ik heb de situatie nu hermapped zoals in Lara:
>> http://www.openstreetmap.org/changeset/40165558
>> http://www.openstreetmap.org/changeset/40165816
>>
>> Overigens in die wijk deze note gemaakt toen ik er passeerde met de GR12
>> west:
>> http://www.openstreetmap.org/note/587922
>>
>> Dus lokaal survey zeker nuttig!
>>
>> Op 20 juni 2016 20:35 schreef Marc Gemis :
>>
>> Ik hoorde daarstraks een aankondiging van het Radio 2 programma De
>>> Inspecteur [1]. Het zou morgenochten gaan over navigatiesystemen.
>>> Blijkbaar heeft de Stad Mechelen al een aantal jaar geleden
>>> commerciele spelers op de hoogte gebracht van de straatnaamwijzigingen
>>> in een bepaalde wijk, maar geen enkel systeem zou zijn aangepast.
>>>
>>> Iemand die weet over welke wijk het gaat (dat is me ontgaan) ? Of de
>>> data in OSM in orde is ?
>>>
>>> Zelfs indien niet het geval is zouden we geen tweets of FB berichten
>>> [2] kunnen achterlaten dat ze het ofwel zelf in OSM kunnen aanpassen
>>> of ons ook op de hoogte willen houden ?
>>>
>>> Mogelijks gaat het om de wijk [3], als deze weg [4] er dan deel van
>>> uitmaakt, zou het in OSM in orde kunnen zijn.
>>>
>>> mvg
>>>
>>> m
>>>
>>> [1] http://www.radio2.be/de-inspecteur
>>> [2] https://www.facebook.com/DeInspecteurRadio2/
>>> [3]
>>> http://www.gva.be/cnt/dmf20141213_01427489/nieuwe-huisnummers-en-straatnamen-ergeren-bewoners
>>> [4] http://www.openstreetmap.org/way/34546170#map=18/51.04291/4.47471
>>>
>>> Twitter van Mechelen @StadMechelen
>>> Twitter van De inspecteur @De_Inspecteur
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>
>>
>>
>> --
>> Joost @
>> Openstreetmap  |
>> Twitter  | LinkedIn
>>  | Meetup
>> 
>>
>
>
>
> --
> Joost @
> Openstreetmap  |
> Twitter  | LinkedIn
>  | Meetup
> 
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org

Re: [OSM-talk-be] Radio 2 Programma De Inspecteur & navigatiesystemen

[Marc Gemis]

Ik heb ze (stad Mechelen) via tweet gevraagd om ons (osm_be) op de hoogte
te houden vanzulke wijzigingen of het eventueel zelf te doen. Ben benieuwd
of ze gaan reageren.

m
Op 20 jun. 2016 23:24 schreef "Philippe Casteleyn" <
philippecastel...@hotmail.com>:

>
>
> betere link :
> http://www.mapillary.com/map/im/9xwkLAM7oIUTUu_UbWvaEg/photo
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Philippe Verdy]

Et pourquoi veux-tu absolument que les *données* d'OSM soient utilisées
uniquement comme phrases nominales ? OSM ne code pas que pour reproduire
les panneaux (qu'ils soient normalisés ou non). Ce sont des données qui
sont intégrables et pas seulement pour dessiner une carte avec un noeud
représentant un panneau !


Le 20 juin 2016 à 20:55, Christian Rogel 
a écrit :

>
> La question se résume à ceci, vu de ma fenêtre :
>
> 1) Il ne doit être fait mention des pratiques  l’IGN ou l’INSEE que pour
> information, car, ils ne sont pas compétents pour ce dont il est parlé,
> c’est-à-dire, les noms de lieu délibérés par les communes.
>
> 2) On ne peut qu’être prudent avec ce que présente le cadastre :
> retranscription = possibilité de déviation
>
> 3) Sauf erreur de ma part, les panneaux d’hydronymes (noms de cours d’eau)
> avec une minuscule à l’initiale ont été posés par l’État, au bord de ce qui
> a été ou est encore une route nationale. Cela me paraît une relique sans
> intérêt.
>
> 4) Les communes usent et abusent de leur liberté de dénomination et aucune
> normalisation ne peut sortir de constats diversifiés. Si les petits
> panneaux ruraux comportent aussi bien des capitales que des bas-de-casse,
> ce n’est, me semble-t’il, pas le cas des panneaux urbains (fond blanc
> entouré de bleu ou gris) qui comportent toujours des capitales
>
> Ma conclusion est que l’approche choisie pour Osmose est raisonnable, qui
> applique, non pas une règle de l’univers toponymique, mais une règle
> cardinale de la typographie française, qui prescrit une capitale en tête de
> toute locution (et exclut la présence au milieu d’un mot, comme dans
> OpenStreetMap).
> C’est pragmatique et, surtout, efficace. Proposer le bas-de-casse
> généralisé serait introduire de l’exotisme.
>
>
> Addendum : pour les langues régionales, c’est plus simple :-) , car, les
> articles, n’étant pas perçus comme tels, sont souvent affublés d’une
> capitale dans les décisions communales.
> Ainsi, la base KerOfis de l’office public de la langue bretonne (organisme
> normatif du domaine) donnera deux déclinaisons d’un même nom de lieu en
> breton du 21ème siècle :
>
> *name = Koad An Noz*  et *name:br = Koad an Noz*
>
> *Koad an Noz* signifie *Bois (de) la Nuit*
>
> Je n’ai jamais vu l’article breton initial ne pas recevoir de capitale :*
> Ar Pouilhod* (échangeur de Châteaulin, sur la RN 165).
>
>
>
>
> Christian R
>
> ___
> 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

Re: [Talk-us] Proposed import cleanup: NYSDEClands

[Kevin Kenny]

Since I've not yet heard anything from the too-long message below,
let me summarize my plea for help. My lack of understanding is blocking
my attempts to do any repair on the NYS DEC Lands import, and making
me concerned that the NYC DEP Watershed Recreation Areas import
will need a revert. (The latter surprises me, since the geometry and tagging
were both generated by ogr2osm from well-formed multipolygons in a
PostGIS database.)

Russ has expressed concern that the proposed repair of the
NYS DEC Lands import will damage
https://www.openstreetmap.org/way/32036186
which is closely related to
https://www.openstreetmap.org/way/387275831
and
https://www.openstreetmap.org/relation/91728

What I see in the external data is illustrated in:
https://www.flickr.com/photos/ke9tv/27805345215

The red polygon is the outline of the 91728 relation. Crosshatched polygons
are other polygons from OSM. The magenta area is the state forest. (There's
a slight misalignment between red and magenta. That is part of what a
reimport would be trying to fix.)

There are no tags on the 91728 relation apart from type=multipolygon. All
of the tagging is on the outer way. There's a natural=wood tag on the inner way.

Russ says that he did it as he did in order not to have to repeat natural=wood,
but I surely don't understand the tagging as it stands. He is sufficiently self
assured that I'm convinced that my understanding of how multipolygons work
is wrong. I would have thought that to represent data that belong to the
polygon-with-a-whole, tags would have to be applied to the relation, and not
to the outer way. Tags applied to the outer way would apply to the hole as well.
But that's surely not what Russ intended, since the state forest does
not include
the private inholding represented by the hole.

The only way that I can see the current tagging working is if there
is some hidden coupling where it is understood that tags that apply
to an outer way of a multipolygon relation actually belong to the relation
itself, and the inner ways are excluded implicitly. If so, that puzzles me,
because that's also not what I see the renderer assuming.

Can someone please explain to me how I should be tagging things
so that the polygon-with-a-hole becomes a protected area? The ones I did
in the Catskills, like https://www.openstreetmap.org/relation/6304902
appear to render as I intended, but I know that there is lots of nonsense
tagging that still renders prettily.

Kevin


On Sat, Jun 18, 2016 at 4:02 PM, Kevin Kenny  wrote:
> I'm looking at that relation, and I really don't understand what
> you're trying to accomplish - although when I run it through my
> script, the script at least detects the tagging as something that
> requires manual inspection. When I got to that parcel, I'd surely be
> writing to you, asking what you meant by it! I suspect there's
> something badly wrong with my understanding of multipolygons.
>
> When I look at the multipolygon relation, I see no tags, which makes
> its purpose difficult to understand. What is the meaning of a
> multipolygon without tags? It's a piece of land, about which no
> information is given.
>
> The tagging for the state forest is all on the outer ring, which,
> according to what I had previously understood, means that it applies
> to the entire interior of the area, including the inner ring. I don't
> think that's right, but you're local and I'm not. I haven't been there
> in the field to see the posters and survey blazes, but the current
> version of the NYS DEC Lands file shows a parcel with an inholding. I
> assume that you intended by your tagging to assert that the DEC Lands
> file is obsolete and incorrect and the inner parcel is actually part
> of the state forest? If so, I defer to your local knowledge.
>
> The inholding is tagged with 'natural=wood', which would make its
> interior 'natural=wood' AND part of the state forest. That's
> reasonable, I suppose. landuse=forest doesn't necessarily imply tree
> cover (a piece could, for instance, be incompletely regrown from a
> clearcut). I'm trying to avoid reigniting the whole 'forest
> controversy' - we have land use ("this area is managed for the
> production of timber"); land cover ("this area is covered by trees");
> and cadastre ("this land is designated as 'state forest', and as such
> is protected from sale or development and open to the public for
> recreation when logging is not in progress"). The current tagging
> structure doesn't distinguish the concepts well, but I see that as
> something I just have to live with and tag as best I can. natural=wood
> or landcover=trees appear to be the best tags for land cover,
> landuse=forest an appropriate tag for a producing forest, and
> boundary=protected_area to describe the status of protection and
> public access,
>
> So the semantics appear to be that the entire outer ring is the state
> forest, there's an inner area that's a wood (as well as 

[Talk-us] What Bloggers do you follow

[Clifford Snow]

The US Chapter has a press release mailing list. I'd like to update it with
bloggers that you follow. Let me know which blogger do you think should be
on our PR mailing list.

Thanks,
Clifford

-- 
@osm_seattle
osm_seattle.snowandsnow.us
OpenStreetMap: Maps with a human touch
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-transit] GTFS, tools and pt tags generally

[Mike N]

On 6/20/2016 5:18 PM, Paul Johnson wrote:

I really wonder how TriMet ultimately accomplished this, since that
would seem like a decent-ish starting point since that system is in
charge of a fairly multimodal system with above and below ground
stations, split-level stations, and transit centers of almost every
description.


  I don't know for sure, but I think TriMet's system uses GTFS as a 
primary transit planning reference in OpenTripPlanner, and OSM data is 
maintained to facilitate public transit connection to  Pedestrian / Bike 
/ Car.A quick glance at OSM's public transit layer in Portland shows 
that lots of bus routes have been entered into OSM, but I don't know if 
they have any function other than "there is a bus route or stop here".



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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Nicolás Alvarez]

2016-06-20 19:14 GMT-03:00 Frederik Ramm :
> Hi,
>
> On 06/20/2016 11:49 PM, Andrew Harvey wrote:
>> The down side of course is that the Maps.me data isn't updated very
>> frequently so I might be duplicating data which has been added after
>> Maps.me last generated the data extracts,
>
> Isn't Maps.me Open Source - could not someone else simply make current
> extracts available?
>

Yes, and I have done it (downloaded a .pbf, applied diffs to it,
generated my own .mwm).

But you don't need to; Maps.me already provides semi-official current map files!
http://direct.mapswithme.com/regular/daily/

-- 
Nicolás

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Frederik Ramm]

Hi,

On 06/20/2016 11:49 PM, Andrew Harvey wrote:
> The down side of course is that the Maps.me data isn't updated very
> frequently so I might be duplicating data which has been added after
> Maps.me last generated the data extracts, 

Isn't Maps.me Open Source - could not someone else simply make current
extracts available?

Bye
Frederik

-- 
Frederik Ramm  ##  eMail frede...@remote.org  ##  N49°00'09" E008°23'33"

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Jóhannes Birgir Jensson]

I've been using Maps.me myself and find it easy to add shops - although 
I'm missing many presets (I change them when I come home to the right 
one but other users will not do that generally).


Maps.me was perfect for one activity that is usually painful - updating 
shops inside Iceland's largest mall. Several had shut down and others 
opened and updating it as I walked past each one in Maps.me was very 
easy to do - for those that had shut down I modified the name to make it 
clear and then deleted node at home. 
http://www.openstreetmap.org/changeset/39646645


It would be nice if there was a power-user setting on it - perhaps 
unlockable elsewhere (or based on edit # in OSM or something using 
non-Maps.me editors) so novice users can't wreak more havoc.



Þann 20.6.2016 21:49, skrifaði Andrew Harvey:

On 20 June 2016 at 22:48, Oleksiy Muzalyev  wrote:

Maps.me editor has got the principal difference from other editors, - it can be 
used without an active Internet connection.

I've been editing in JOSM for years and just started editing with
Maps.me, and the fact that it's very fast and easy to make the edit is
the main reason I have. If I walk past a shop, it's very easy to add
it straight through the app, vs making a note and then spending time
back home converting that note into mapping in JOSM.

The down side of course is that the Maps.me data isn't updated very
frequently so I might be duplicating data which has been added after
Maps.me last generated the data extracts, or potentially already in
OSM but Maps.me wasn't rendering it (so I thought it didn't exist). I
think this is something Maps.me should address that if it finds a
similar tag nearby which was created at a time after your local
offline data and if so let you know about it before uploading.

It's also frustrating that I can't add key=value tags, as an expert
user this would be a handy option.

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



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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Andrew Harvey]

On 20 June 2016 at 22:48, Oleksiy Muzalyev  wrote:
> Maps.me editor has got the principal difference from other editors, - it can 
> be used without an active Internet connection.

I've been editing in JOSM for years and just started editing with
Maps.me, and the fact that it's very fast and easy to make the edit is
the main reason I have. If I walk past a shop, it's very easy to add
it straight through the app, vs making a note and then spending time
back home converting that note into mapping in JOSM.

The down side of course is that the Maps.me data isn't updated very
frequently so I might be duplicating data which has been added after
Maps.me last generated the data extracts, or potentially already in
OSM but Maps.me wasn't rendering it (so I thought it didn't exist). I
think this is something Maps.me should address that if it finds a
similar tag nearby which was created at a time after your local
offline data and if so let you know about it before uploading.

It's also frustrating that I can't add key=value tags, as an expert
user this would be a handy option.

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

Re: [OSM-talk-be] Radio 2 Programma De Inspecteur & navigatiesystemen

[Philippe Casteleyn]

betere link :http://www.mapillary.com/map/im/9xwkLAM7oIUTUu_UbWvaEg/photo   
  ___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-transit] GTFS, tools and pt tags generally

[Paul Johnson]

On Mon, Jun 20, 2016 at 2:02 PM, Stephen Sprunk  wrote:

> On 2016-06-20 02:07, Roland Olbricht wrote:
>
>> There had been a group that was very vocal for making a textbook
>> example of design by committee, and the result is now known as
>> "approved public transport scheme". They did not ask for input from
>> experienced mappers or developers. I decided to consider it a waste of
>> time and stopped developing.
>>
>
> I wasn't around at the time, so I can't speak to how it happened, but the
> result seems to be a partial implementation of Transmodel, which
> distinguishes a _lot_ of different things (and the complex relationships
> between them) in excruciating detail because the real world is, in fact,
> that complicated.
>
> If one is putting data in by hand, it certainly seems unwieldy.  It took
> me over a week to do just a few rail routes in my area, and I'm still not
> completely sure I got them right.  I can't imagine trying to do the
> hundreds of bus routes too.
>

I really wonder how TriMet ultimately accomplished this, since that would
seem like a decent-ish starting point since that system is in charge of a
fairly multimodal system with above and below ground stations, split-level
stations, and transit centers of almost every description.

One thing that breaks things badly for me in the Tulsa area is the vast
overwhelming majority of stops in the Tulsa Transit (and presumably other
transit systems in the region) GTFS have...literally zero indication on the
ground, there's no way to tell if there is an actual bus stop (which is
typically just a signpost with a bus stop sign on it), and if it is,
whether or not that's verifiable because the sign's gone missing.  Or the
more likely case with mass transit in the southern midwest, no amenities
whatsoever are provided, you just need to know the bus runs on that street
and stand about a bus length after the downstream side of an intersection
that doesn't have a signposted stop and flag down the driver to catch the
bus (likewise, you have to be unusually precise at pulling the stop cord as
the driver will automatically assume immediately after the next
intersection, regardless of how minor).  Worse, there's a large number of
duplicates with more than one stopID for the same stop position (this is a
GTFS data issue, Tulsa Transit's feed is a hot mess to start with), and
there's a significant portion (perhaps to the point of "almost all") major
transfer points that fall into the category of totally unsigned stops, and
another rash of locations that have no GTFS entry but are considered to be
valid, totally unposted bus stops.

My completely shitty answer to this problem right now is to map only
signposted stops I've verified.  I have no idea how many there actually
are, nor do I have any reason to believe that Tulsa Transit has any clue
how many there are in actuality either.  I'm also a big fan of the V1
tagging scheme as it's substantially easier to deal with.

On the ground mapping should become easier with time as Tulsa Transit's
starting to get more funding (Finally!), though focus right now is on
getting more safe vehicles on the road more frequently, longer hours and to
more places (currently any trip requiring more than one transfer, or even a
particularly long trip involving no transfers and only one possible route,
is a major test of patience, as it's annoyingly common for a scheduled bus
to be cancelled completely without warning due to lack of usable equipment
that has things like an intact floor that hasn't rusted out to the street
below).  I would hope that the GTFS feed improves as ridership increases
and stops get signposted, but I'm really not counting on the GTFS improving
or bus stops to get maintained, much less posted more formally than someone
scratching something like MTTA 3421 on a handy streetlamp or telephone pole
at unposted stops frequented by people who figured out the stop ID for that
location independently to look up when the next bus arrives via text
message...


> Also, like it or not, Google Maps (and hence GTFS) has set a bar for what
> users expect from online maps.  I'd certainly like OSM to be better, of
> course, but the current situation is that OSM is generally far, far worse.


It doesn't help that the only implementations of GTFS that actually are
anywhere near complete are basically the reference implementations Google
did in cooperation with TriMet and Tillamook County Transit, and adjacent
systems that asked TriMet how they did that (like Clark County Transit, aka
C-Tran).  The situation with GTFS data itself is so bad that Google stopped
offering Navigation for the transit mode in it's own Maps service.  Which
was actually a pretty slick thing, and I actually used it a lot for the
last few months that feature was even available, since if your route
suddenly became impossible to make a transfer because of a delay or the
GTFS Live feed indicated there was a problem, it would 

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Francois Gouget]

On Mon, 20 Jun 2016, Christian Rogel wrote:
> 
> La question se résume à ceci, vu de ma fenêtre :
> 
> 1) Il ne doit être fait mention des pratiques l’IGN ou l’INSEE que 
> pour information, car, ils ne sont pas compétents pour ce dont il est 
> parlé, c’est-à-dire, les noms de lieu délibérés par les communes.

D'accord pour l'IGN puisqu'ils décrivent leur rendu de carte et non des 
règles typographiques.

Je ne me souviens pas que l'INSEE ait été mentionnée dans cette discussion.

Les standard typographiques définis par la Commission Nationale de 
Toponymie me paraissent par contre tout à fait applicables à 
OpenStreetMap. Quelle est votre raison pour les rejeter ?


> 2) On ne peut qu’être prudent avec ce que présente le cadastre : 
> retranscription = possibilité de déviation

Oui mais ceci est une autre discussion.


> 3) Sauf erreur de ma part, les panneaux d’hydronymes (noms de cours 
> d’eau) avec une minuscule à l’initiale ont été posés par l’État, au 
> bord de ce qui a été ou est encore une route nationale. Cela me paraît 
> une relique sans intérêt.
>
> 4) Les communes usent et abusent de leur liberté de dénomination et 
> aucune normalisation ne peut sortir de constats diversifiés. Si les 
> petits panneaux ruraux comportent aussi bien des capitales que des 
> bas-de-casse, ce n’est, me semble-t’il, pas le cas des panneaux 
> urbains (fond blanc entouré de bleu ou gris) qui comportent toujours 
> des capitales

Oui. D'où la nécessité de se tourner vers des sources plus fiables 
comme le rapport de la CNT.


> Ma conclusion est que l’approche choisie pour Osmose est raisonnable, 
> qui applique, non pas une règle de l’univers toponymique, mais une 
> règle cardinale de la typographie française, qui prescrit une capitale 
> en tête de toute locution (et exclut la présence au milieu d’un mot, 
> comme dans OpenStreetMap).

L'approche choisie par Osmose contredit la règle édictée par 
OpenStreetMap. Tant que ceci n'est pas résolu dans un sens où dans 
l'autre il y a un problème.
https://wiki.openstreetmap.org/wiki/FR:Toponymes,_odonymes#Toponymes_officiels_et_non-officiels


> C’est pragmatique et, surtout, efficace. Proposer le bas-de-casse 
> généralisé serait introduire de l’exotisme.

Vous êtes donc en faveur de changer le standard OpenStreetMap. Pourquoi 
pas.

Cependant si l'option de commencer tous les champs name par une 
majuscule est pragmatique, les gens ont naturellement tendance à le 
faire, cela ne me paraît pas efficace du point de vue des utilisations 
qui pourraient être faites de cette donnée dans un contexte nécessitant 
une casse différente (que ce soit par un moteur de rendu ou par une 
application qui voudrait insérer ce nom en milieu de phrase).

Pourquoi trouvez-vous qu'il est plus efficace de commencer le champ 
name par une majuscule ?


[...]
> Je n’ai jamais vu l’article breton initial ne pas recevoir de capitale 
> : Ar Pouilhod (échangeur de Châteaulin, sur la RN 165).

Je vous rappelle "qu'aucune normalisation ne peut sortir de constats 
diversifiés". Pourquoi ce panneau échappe-t-il au status de "relique 
sans intérêt" ?
;-)

-- 
Francois Gouget   http://fgouget.free.fr/
  Hiroshima '45 - Czernobyl '86 - Windows '95___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

[OSM-talk] Invitation to Rio de Janeiro Olympics Mapathon

[Arlindo Pereira]

Hi folks,

I'd like to invite you to virtual mapping party - a mapathon - happening
this weekend (June 25th and 26th), about Rio de Janeiro area. We need your
help to create a better map for the city hosting the Olympic and Paralympic
Games.

Please head to the wiki page for more details:
https://wiki.openstreetmap.org/wiki/Rio_Olympics_Mapping

Thank you!

[]s
Arlindo Pereira
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

[OSM-talk-be] Radio 2 Programma De Inspecteur & navigatiesystemen

[Philippe Casteleyn]

Jaren geleden stond er een note op die wijk dat de straten zouden veranderen.  
Op de website van Mechelen was niets te vinden.Ik ben een paar keer gaan 
fotograferen maar de meeste straten waren nog in aanleg.  Bovendien is het een 
fotoönvriendelijke buurt.Indien iemand mij had kunnen verwittigen wanneer de 
straten klaar waren ...http://www.mapillary.com/map/search/51.041733/4.475054/14


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

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Yannick]

Le 20/06/2016 01:50, Francois Gouget a écrit :
> 
> Je pense que tout cela sort largement du cadre d'OpenStreetMap et relève 
> plutôt du cadre de la commission de réformation des noms de lieux-dits 
> français ;-)
> 
> Bref, c'est aux historiens de rétablir la vérité historique et 
> potentiellement de réformer les usages courants, pas aux cartographes.

Bonsoir,

Encore faudrait-il accepter d'être contredit par les historiens et
prendre réellement en compte leur point de vue.
Rien n'empêche un cartographe de faire un travail de recherche
historique, tout comme l'inverse est aussi vrai.

Pour moi celui qui crée le document DOIT s'assurer de sa conformité au
terrain et donc à l'histoire, les deux étant quasiment toujours liés.

Amitiés

-- 
Yannick VOYEAUD
Nul n'a droit au superflu tant que chacun n'a pas son nécessaire
(Camille JOUFFRAY 1841-1924, maire de Vienne)
http://www.voyeaud.org
Créateur CimGenWeb: http://www.francegenweb.org/cimgenweb/
Journées du Logiciel Libre: http://jdll.org
Généalogie en liberté avec Ancestris http://www.ancestris.org

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

Re: [Talk-it] DAE e furti

[Martin Koppenhoefer]

2016-06-20 21:42 GMT+02:00 Alecs :

> Ho usato un
> paio di volte defibrillator=yes che è quasi un unicum mondiale, c'è qualche
> altro tag?
>


userei automated_defibrillator




> oppure è meglio lasciare perdere un approccio di questo tipo e
> mappare solo i singoli defibrillatori?
>


è decisamente meglio mappare la posizione esatta del defibrillatore, ma
potresti pensare alla mappatura come "property" di una cosa più grande come
una sorta di promemoria (dove vuoi fare un sopraluogo dopo quando non sai
la posizione)

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

Re: [Talk-de] JOSM: keine Daten gefunden. nachtrag

[Toni Erdmann]

On 20.06.2016 20:55, Walter Nordmann wrote:

Starte Josm im Terminalfenster und schau dir den Output an.



oh ja, hätt' ich auch selber drauf kommen können:
Liegt nicht am JOSM, irgenwas scheint in der DB falsch zu laufen?

Toni

INFO: GET 
https://api.openstreetmap.org/api/0.6/map?bbox=11.6141367,48.1116721,11.6155529,48.1129615 
-> 200
INFO: Während des Einlesens wurde ein undefiniertes Element "error" 
gefunden. Dieses wird ignoriert.


wget 
https://api.openstreetmap.org/api/0.6/map?bbox=11.6141367,48.1116721,11.6155529,48.1129615



attribution="http://
www.openstreetmap.org/copyright" 
license="http://opendatacommons.org/licenses/odbl/1-0/;>
 maxlon="11.6155529"/>

 Connection to database failed



BTW:


Das JOSM latest liefert nun noch was anderes: einen leeren Startbildschirm

Fehler: java.lang.reflect.InvocationTargetException. Ursache: 
java.lang.NullPointerException

java.lang.reflect.InvocationTargetException
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1321)
at java.awt.EventQueue.invokeAndWait(EventQueue.java:1296)
at 
javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1348)
at 
org.openstreetmap.josm.gui.util.GuiHelper.runInEDTAndWait(GuiHelper.java:127)
at 
org.openstreetmap.josm.gui.MainApplication.main(MainApplication.java:321)

Caused by: java.lang.NullPointerException
at 
org.openstreetmap.josm.data.Preferences.getUserDataDirectory(Preferences.java:295)
at 
org.openstreetmap.josm.tools.ImageProvider.getImageUrl(ImageProvider.java:1188)
at 
org.openstreetmap.josm.tools.ImageProvider.getIfAvailableImpl(ImageProvider.java:915)
at 
org.openstreetmap.josm.tools.ImageProvider.getResource(ImageProvider.java:640)
at 
org.openstreetmap.josm.tools.ImageProvider.get(ImageProvider.java:622)
at 
org.openstreetmap.josm.tools.ImageProvider.get(ImageProvider.java:789)
at 
org.openstreetmap.josm.gui.widgets.TextContextualPopupMenu.addMenuEntry(TextContextualPopupMenu.java:182)
at 
org.openstreetmap.josm.gui.widgets.TextContextualPopupMenu.addMenuEntries(TextContextualPopupMenu.java:115)
at 
org.openstreetmap.josm.gui.widgets.TextContextualPopupMenu.attach(TextContextualPopupMenu.java:100)
at 
org.openstreetmap.josm.gui.widgets.TextContextualPopupMenu.enableMenuFor(TextContextualPopupMenu.java:150)
at 
org.openstreetmap.josm.gui.widgets.JosmEditorPane.(JosmEditorPane.java:33)
at 
org.openstreetmap.josm.gui.GettingStarted$LinkGeneral.(GettingStarted.java:54)
at 
org.openstreetmap.josm.gui.GettingStarted.(GettingStarted.java:123)
at 
org.openstreetmap.josm.gui.MainPanel.getGettingStarted(MainPanel.java:149)
at 
org.openstreetmap.josm.gui.MainPanel.updateContent(MainPanel.java:71)
at 
org.openstreetmap.josm.gui.MainApplication$1.run(MainApplication.java:324)
at 
java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301)

at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:756)
at java.awt.EventQueue.access$500(EventQueue.java:97)
at java.awt.EventQueue$3.run(EventQueue.java:709)
at java.awt.EventQueue$3.run(EventQueue.java:703)
at java.security.AccessController.doPrivileged(Native Method)
at 
java.security.ProtectionDomain$JavaSecurityAccessImpl.doIntersectionPrivilege(ProtectionDomain.java:76)

at java.awt.EventQueue.dispatchEvent(EventQueue.java:726)
at 
java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201)
at 
java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116)
at 
java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105)
at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101)
at 
java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93)

at java.awt.EventDispatchThread.run(EventDispatchThread.java:82)
INFO: Nutzbares IPv6-Netzwerk erkannt, bevorzuge IPv6 vor IPv4.
INFO: GET https://josm.openstreetmap.de/wiki/De:StartupPage -> 200


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

Re: [Talk-it] DAE e furti

[Andrea Lattmann]

>Piccolo OT: se passando davanti a una >scuola/palestra o altro si nota un
>cartello che indica che all'interno è >presente un defibrillatore, c'è un
>modo per mapparlo? Intendo dire, per >segnalare che la struttura è dotata di
>defibrillatore, anche se non si conosce la >posizione esatta. 

Interessa anche a me, perché alcuni DAE sono all' interno delle strutture, 
quindi è da capire come maparli.


Andrea Lattmann

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

Re: [Talk-de] JOSM: keine Daten gefunden

[Toni Erdmann]

Danke Walter,

JOSM latest ...

openjdk version "1.8.0_91"
OpenJDK Runtime Environment (IcedTea 3.0.1) (suse-12.1-x86_64)
OpenJDK 64-Bit Server VM (build 25.91-b14, mixed mode)

Und IPv6 macht auch hier immer mal wieder Probleme ...

Gruß,
Toni

On 20.06.2016 20:54, Walter Nordmann wrote:

Nö,

JOSM geht bei mir (hab mal geraten, dass du Josm verwendest).

Ich hab aber in Erinnerung, dass IPv6 bei manchen Usern Probleme gemacht
hat. Wurde dann wohl durch Java 8 erledigt. Und falls du Latest
verwendet, könnte es sein, dass Java 7 nicht mehr unterstützt wird.  Der
nächste
Tested läuft auf jeden Fall nicht mehr mit J7.

Alles nur geraten, aber evt. hilft dir das doch. Mach auf jeden Fall den
Update auf J8, sonst knallt es eh bald.

Gruss
walter

Am 20.06.2016 um 20:00 schrieb Toni Erdmann:

Hallo,

es scheint mir, was mit dem TLS (https://api.openstreetmap.org/api)
nicht zu stimmen. In wireshark sehe ich als letztes (vorm RST)

Version TLS 1.2
Alert Message: Encrypted Alert

hat noch jemand ähnliche Probleme?

Gruß,
Toni

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



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



--
Antonius "Toni" Erdmann mailto:toni.erdm...@web.de
Friedenstraße 21Phone:  +49 89 6094219
D-85521 Ottobrunn   Mobile: +49 176 45504896
Germany

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

Re: [Talk-it] DAE e furti

[Alecs]

Succede ogni tanto che vengano rubati, sono oggetti che devono essere
facilmente alla portata di tutti, sono anche alla portata dei vandali
purtroppo, anche due defibrillatori che ho mappato io, appena inaugurati,
sono spariti qualche tempo dopo (già sostituiti per fortuna).

Piccolo OT: se passando davanti a una scuola/palestra o altro si nota un
cartello che indica che all'interno è presente un defibrillatore, c'è un
modo per mapparlo? Intendo dire, per segnalare che la struttura è dotata di
defibrillatore, anche se non si conosce la posizione esatta. Ho usato un
paio di volte defibrillator=yes che è quasi un unicum mondiale, c'è qualche
altro tag? oppure è meglio lasciare perdere un approccio di questo tipo e
mappare solo i singoli defibrillatori?

Alessandro


Marco Predicatori wrote
> Approfitto del thread per segnalare una cosa che spero sia solo una
> mia paranoia. L'anno scorso, in occasione di un mapping party, è
> stato mappato questo: https://www.openstreetmap.org/node/3822927184
> 
> Era lì da anni, e pochi giorni dopo la sua comparsa su OSM è stato
> rubato:
> http://gazzettadimantova.gelocal.it/mantova/cronaca/2015/11/13/news/ladri-senza-cuore-sparito-il-defibrillatore-dalla-piazza-di-volta-1.12442624
> 
> Mi è sembrata una coincidenza stratosferica. Quando mappate un DAE,
> provate a vedere poi se per caso viene rubato. SGRAT! Hai visto mai
> che diamo alle FFOO qualche spunto di indagine, tipo da che IP è
> stato scaricato l'elenco dei DAE...
> 
> Qualche tempo fa il DAE di Volta è stato sostituito, ora l'ho rimappato.
> 
> Ciao, Marco
> 
> -- 
> https://www.openstreetmap.org/user/marco69
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it





--
View this message in context: 
http://gis.19327.n5.nabble.com/DAE-su-osm-con-la-scusa-di-un-bot-Telegram-tp5875903p5876012.html
Sent from the Italy General mailing list archive at Nabble.com.

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

[Talk-de] Einladung 2. OSM Sommercamp

[Marc Gehling]

Der FOSSGIS e.V. lädt zum 2. OSM Sommercamp im Linuxhotel ein.

Das Treffen findet vom 12.-14. August 2016 statt und kann vielfältig genutzt 
werden.

OSM Aktive können das Wochenende als Arbeitswochenende für Projekte nutzen, es 
soll Workshops rund um OSM geben ...
Communities und Interessierte aus freien GIS und Geodaten-Projekten können das 
Wochenende nutzen, um die jeweiligen Projekte voranzubringen.
Es stehen etwa 30 Hotelbetten für uns bereit sowie eine Wiese zum Campen.

Bitte tragt Euch und falls vorhanden Euer Projekt oder Eure Idee, die Ihr 
umsetzen wollte, möglichst bald im Wiki ein. Die Anzahl der Übernachtungsplätze 
ist begrenzt. Also schnell eintragen! [1]

Weitere Ideen und Anregungen zur Ausgestaltung sind gerne gesehen und werden 
bestimmt aufgegriffen.
Die Fossgis Community ist ebenfalls eingeladen, siehe 6. Fossgis Hackweekend [2]

Wir freuen uns (mittlerweile zum 2. mal) auf ein gemeinsames SommerCamp im 
Linuxhotel.

[1] http://wiki.openstreetmap.org/wiki/SommerCamp_2016
[2] https://www.fossgis.de/wiki/FOSSGIS_Hacking_Event_2015_Nummer_6


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

Re: [Talk-cz] velké multipolygony

[Libor Skala]

Zdravím,

po problémech s nedostatkem paměti jsem si připravil spouštěcí soubor 
(.bat) a do něho dal:


javaw.exe -jar -Xmx1024M "C:\Program Files (x86)\JOSM\josm-tested.jar"
exit

Dlouho se mi nestalo, že by došla paměť u JOSM.

S pozdravem

Libor Skala

Dne 20.6.2016 v 19:47 Milan Cerny napsal(a):

Zdravím, poradil by někdo jak je to s velikostí multipolygonu? Na Wiki se píše 
o libovolném počtu inner, outer cest ale o velikosti ne.
Je lepší jeden velký multipolygon, nebo plochu rozdělit na několik menších, 
případně proč?
A poslední dotaz, čím je možné velké multipolygony editovat, všechny základní 
editory velké plochy nezvládají a padají na nedostatku paměti, což může být jen 
problém mého PC.

Moc díky za rady.

Milan

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




smime.p7s
Description: Elektronicky podpis S/MIME
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-us] SOTM US schedule

[Mike Thompson]

Martijn,

Thanks!

Mike

On Mon, Jun 20, 2016 at 12:37 PM, Martijn van Exel  wrote:

> The last event should wrap up around 4pm. A final schedule should be up
> today or tomorrow. Apologies for the delay!
> Martijn
>
> On Mon, Jun 20, 2016 at 12:27 PM Mike Thompson 
> wrote:
>
>> Clifford,
>>
>> I am also looking at my flights, any idea when the last even on Monday
>> will be scheduled?
>>
>> Thanks for all you and other folks in Seattle are doing to put the
>> conference together.
>>
>> Mike
>>
>> On Wed, Jun 15, 2016 at 2:51 PM, Clifford Snow 
>> wrote:
>>
>>> Katie,
>>> We should have the workshop schedule up shortly. We have 11 different
>>> workshop planned for Monday as well as code sprints. Additionally Maptime
>>> is planning workshops for Monday as well.
>>>
>>> Clifford
>>>
>>> On Wed, Jun 15, 2016 at 1:11 PM, Katie Filbert 
>>> wrote:
>>>
 I'm thinking about attending SOTM US and looking at possible flights.

 SOTM website says the conference is July 23-July 25, but the program
 only has July 23 and 24.

 http://stateofthemap.us/program/

 Is there some program for July 25, such as hackathon or something?

 Cheers,
 Katie

 --
 Katie Filbert
 filbe...@gmail.com
 @filbertkm / @wikidata

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


>>>
>>>
>>> --
>>> @osm_seattle
>>> osm_seattle.snowandsnow.us
>>> OpenStreetMap: Maps with a human touch
>>>
>>> ___
>>> Talk-us mailing list
>>> Talk-us@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-us
>>>
>>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

Il 20 giugno 2016 16:28:34 CEST, Stefano  ha scritto:
>Il giorno 20 giugno 2016 16:20, Martin Koppenhoefer
>
>ha scritto:
>
>>
>>
>> sent from a phone
>>
>> > Il giorno 20 giu 2016, alle ore 16:13, Andrea Lattmann <
>> andrea.guglie...@ga-2.it> ha scritto:
>> >
>> > Questo mi preoccupa perché è molto importante ossigenare!
>>
>>
>> quando l'hai imparato? Pare che l'american heart association abbia
>> cambiato le raccomandazioni per motivi di nuovi risultati di ricerca.
>Anche
>> per me era una novità...
>>
>>
>Ma talk-it è diventato talk-118 ?
>
>
>
>> ciao,
>> Martin
>> ___
>> 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

>Ma talk-it è diventato talk-118 ?

Mi sa di si! :-D 

Questo perché è un argomento importante, quindi una mano in tasca e l' altra 
sul GPS e mappiamo questi benedetti DAE! 

Dai, ogni tanto un OT fa comunità. :-D

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

Re: [Talk-it] contribuire a qualità di openstreetmap su aree verdi

[Alecs]

Hai ragione, ora sono passati alla fase di modica dei dati, me ne sono
accorto dopo anche io :)
Concordo sul difetto di prendere un pezzo alla volta


Lorenzo Mastrogiacomi wrote
> Invece è il secondo. Per partecipare è anche obbligatorio accedere con
> l'account osm...
> L'altro giorno ne ho fatto uno distrattamente e adesso ho scoperto che
> risulta un changeset.
> Mi rendo anche conto adesso che è una cavolata visto che ho
> riclassificato solo un pezzo quando li attorno ce ne sono altri dello
> stesso tipo.
> 
> https://www.openstreetmap.org/way/60386527#map=17/50.91633/7.02908
> 
> Lorenzo
> 
> 
> ___
> Talk-it mailing list

> Talk-it@

> https://lists.openstreetmap.org/listinfo/talk-it





--
View this message in context: 
http://gis.19327.n5.nabble.com/contribuire-a-qualita-di-openstreetmap-su-aree-verdi-tp5875727p5876008.html
Sent from the Italy General mailing list archive at Nabble.com.

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

>quando l'hai imparato?

E un bel po di anni fa, circa 14/15 anni fa quando ero in C.R.I. ed ero 
primo soccorritore. Comunque non facevamo mai i classici 15 massaggi 2 
ventilazioni ma i primi minuti massaggiavamo molto, i 100 massaggi al minuto 
vanno benissimo, poi ventilavamo 1/2 volte ma avevamo a disposizione il 
saturimetro per vedere la saturazione di ossigeno nel sangue. Ed ora a 
ripensarci sono fermamente convinto che fanno bene a mettere a disposizione i 
DAE gli enti e a formare il personale, perché i nostri (come soccorritori) 
miglior risultati era quando un famigliare si accorgeva dell' arresto ed 
iniziava con il BLS. Noi come OpenStreetMapper possiamo fare molto mappandoli! 
Il DAE evita una fatica immane, nei casi peggiori e rende più efficace il 
massaggio cardiaco.

Andrea Lattmann

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

Re: [Talk-transit] GTFS, tools and pt tags generally

[Stephen Sprunk]

On 2016-06-20 02:07, Roland Olbricht wrote:

There had been a group that was very vocal for making a textbook
example of design by committee, and the result is now known as
"approved public transport scheme". They did not ask for input from
experienced mappers or developers. I decided to consider it a waste of
time and stopped developing.


I wasn't around at the time, so I can't speak to how it happened, but 
the result seems to be a partial implementation of Transmodel, which 
distinguishes a _lot_ of different things (and the complex relationships 
between them) in excruciating detail because the real world is, in fact, 
that complicated.


If one is putting data in by hand, it certainly seems unwieldy.  It took 
me over a week to do just a few rail routes in my area, and I'm still 
not completely sure I got them right.  I can't imagine trying to do the 
hundreds of bus routes too.


OTOH, this doesn't seem like a huge problem if we're importing the data 
from elsewhere using automated tools and only tweaking by hand where 
it's wrong--and ideally, there should be some sort of feedback mechanism 
to get the source corrected so even that's a short-term problem.


I'm interested in GTFS because it gives us a wealth of data from 
hundreds of transit agencies around the world.  It's not perfect, of 
course, but I think better tools would solve a lot of the disagreements 
over the tagging scheme and its complexity.


Also, like it or not, Google Maps (and hence GTFS) has set a bar for 
what users expect from online maps.  I'd certainly like OSM to be 
better, of course, but the current situation is that OSM is generally 
far, far worse.



I'm not the only one. Tagging never really got traction, and only a
tiny fraction of stops conforms to that approach. This is why we have
now the mess we have.

One example is the dissent on whether the bus stop should be a node on
the vehicle's way or a node where the passengers wait. You will find
all solutions implemented, because each local community decided
different. The "approved scheme" will allow any variant. It's even
worse for where to put the name: I got even within local communities
incompatible answers, all referring to the "approved scheme".


I think it's fairer to say that the approved scheme allows either or 
both--using different tags, so you know which you are dealing with.  
IMHO, that's an improvement over folks using the same tags for two 
different things.


Unfortunately, GTFS _doesn't_ help solve this particular problem.  
Worse, each agency seems to have their own idea of what a "stop" or 
"station" is, so local mappers might have to tweak things--and the tools 
would need to respect those tweaks during future imports.



Another example are route relations. While there are wild
constructions called route_master and network which are basically
collection relations, the problem that bothers most people in practice
has never been tackled: We would like to see per way segment only one
or very few relations and need a construction to assemble itineraries
from that. That would greatly reduce maintenance.


I'll admit I was a bit annoyed at having to duplicate way data for 
several routes where some trips run A-B-C-D, some A-B-C and some B-C-D; 
it would have been handy to create segments A-B, B-C and C-D, and then 
just include the right ones in each route.  But then I realized my real 
complaint was that I had to do this _at all_ when there's a GTFS feed 
that has _all_ of that information and could easily be used to 
create/update all the relations.  If it's automated, only developers 
should have to care how complicated or repetitive it is; the important 
thing is that individual mappers don't, at least in the general case.


In my day job, our goal for most process is to automate 90% of "easy" 
things because automating the last 10% would cost more than handling 
them manually does.  I think we can aim higher than that here, at least 
after the first pass, but I suspect that mappers who are doing 100% of 
one thing today aren't likely to complain about doing 10% of two things 
instead tomorrow.



And: how to tell apart services that run a few times per day from those
that have a headway of a few minutes?


That's starting down a slippery slope to including full schedule data.


Given that, it would help have an algorithm to answer the simple
questions for real world examples and their current tagging:
- Where to start/end routing of passengers?


Isn't that what the current scheme is all about?


- Where to start/end routing of vehicles?


Do our consumers really care about that?  Do we need to include 
"deadhead" trips to/from service facilities or cases where one vehicle 
switches from one route to another at a given stop?  The latter is in 
GTFS, but I'm not sure I'd want that in a map.



- How to obtain a name of a station?


How is this complicated?


It's not enough if the solution works fine in your local area and
hopefully works 

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Christian Rogel]

La question se résume à ceci, vu de ma fenêtre :

1) Il ne doit être fait mention des pratiques  l’IGN ou l’INSEE que pour 
information, car, ils ne sont pas compétents pour ce dont il est parlé, 
c’est-à-dire, les noms de lieu délibérés par les communes.

2) On ne peut qu’être prudent avec ce que présente le cadastre : 
retranscription = possibilité de déviation

3) Sauf erreur de ma part, les panneaux d’hydronymes (noms de cours d’eau) avec 
une minuscule à l’initiale ont été posés par l’État, au bord de ce qui a été ou 
est encore une route nationale. Cela me paraît une relique sans intérêt.

4) Les communes usent et abusent de leur liberté de dénomination et aucune 
normalisation ne peut sortir de constats diversifiés. Si les petits panneaux 
ruraux comportent aussi bien des capitales que des bas-de-casse, ce n’est, me 
semble-t’il, pas le cas des panneaux urbains (fond blanc entouré de bleu ou 
gris) qui comportent toujours des capitales

Ma conclusion est que l’approche choisie pour Osmose est raisonnable, qui 
applique, non pas une règle de l’univers toponymique, mais une règle cardinale 
de la typographie française, qui prescrit une capitale en tête de toute 
locution (et exclut la présence au milieu d’un mot, comme dans OpenStreetMap).
C’est pragmatique et, surtout, efficace. Proposer le bas-de-casse généralisé 
serait introduire de l’exotisme.


Addendum : pour les langues régionales, c’est plus simple :-) , car, les 
articles, n’étant pas perçus comme tels, sont souvent affublés d’une capitale 
dans les décisions communales.
Ainsi, la base KerOfis de l’office public de la langue bretonne (organisme 
normatif du domaine) donnera deux déclinaisons d’un même nom de lieu en breton 
du 21ème siècle :

name = Koad An Noz  et name:br = Koad an Noz

Koad an Noz signifie Bois (de) la Nuit

Je n’ai jamais vu l’article breton initial ne pas recevoir de capitale : Ar 
Pouilhod (échangeur de Châteaulin, sur la RN 165).




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

Re: [Talk-de] JOSM: keine Daten gefunden. nachtrag

[Walter Nordmann]

Starte Josm im Terminalfenster und schau dir den Output an.

Gruss
walter



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

Re: [Talk-de] JOSM: keine Daten gefunden

[Walter Nordmann]

Nö,

JOSM geht bei mir (hab mal geraten, dass du Josm verwendest).

Ich hab aber in Erinnerung, dass IPv6 bei manchen Usern Probleme gemacht 
hat. Wurde dann wohl durch Java 8 erledigt. Und falls du Latest 
verwendet, könnte es sein, dass Java 7 nicht mehr unterstützt wird.  Der 
nächste

Tested läuft auf jeden Fall nicht mehr mit J7.

Alles nur geraten, aber evt. hilft dir das doch. Mach auf jeden Fall den 
Update auf J8, sonst knallt es eh bald.


Gruss
walter

Am 20.06.2016 um 20:00 schrieb Toni Erdmann:

Hallo,

es scheint mir, was mit dem TLS (https://api.openstreetmap.org/api) 
nicht zu stimmen. In wireshark sehe ich als letztes (vorm RST)


Version TLS 1.2
Alert Message: Encrypted Alert

hat noch jemand ähnliche Probleme?

Gruß,
Toni

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



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

Re: [OSRM-talk] GPS Accuracy for match service

[Daniel Patterson]

Artur,

  The meaning is the same in both versions, "gps_precision" and "radiuses" are 
"the size of 1 standard deviation of accuracy".

  However, between 4.x and 5.x, the range that we check is a lot narrower.  It 
turns out that in 4.x, the default was about 10x too large, which makes 
map-matching very slow because of the increased number of candidates that it 
needed to check.  The smaller the radius you can use, the faster map-matching 
will be.

  There's no way to change the setting globally on the URL.  You can change the 
code and re-compile OSRM if you want to modify the default.  Not the best way 
to do it, but all we've got at the moment.

daniel


> On Jun 20, 2016, at 11:24 AM, Artur Bialecki  wrote:
> 
> Hello,
>  
> Thank you for the answer.
>  
> Did the match algorithm change between V4.8.1 and V5.2.2? Given the default 
> settings for GPS accuracy (5), V4 seems to match roads in larger radius then 
> version V5. 
>  
> Also, is there a way to globally change the default GPS accuracy instead of 
> having to specify it for every point?
>  
> Thanks you,
>  
> Artur…
>  
>  
> From: Daniel Patterson [mailto:dan...@mapbox.com] 
> Sent: Friday, June 17, 2016 12:13 PM
> To: Mailing list to discuss Project OSRM 
> Subject: Re: [OSRM-talk] GPS Accuracy for match service
>  
> Hi Artur,
>  
>   TL;DR - there's no direct conversion from HDOP to radius, that's not what 
> HDOP is.
>  
>   Just knowing HDOP isn't enough.  HDOP is based on satellite position and 
> basically tells you "if you had perfect reception right now, the best 
> accuracy you could achieve would be X".  Less-than-perfect reception will 
> also affect accuracy, and isn't part of the HDOP calculation.  Number of 
> satellites in view, multi-path-error, etc, all contribute to inaccuracy and 
> aren't part of HDOP.
>  
>   Things like iPhones can give a reasonable estimate because they have a 
> known GPS device with known characteristics, and they're possibly monitoring 
> satellite count, signal-to-noise ratio, etc and doing a fancier calculation 
> than you get from simple NMEA sentences.
>  
>   Cheap GPS devices sometimes do something naive like 3-5m * HDOP ~= 95% 
> radius (2 standard deviations).  It's not really correct, but if that's all 
> you've got, run with it.
>   
> daniel
>  
> On Jun 17, 2016, at 8:36 AM, Artur Bialecki  > wrote:
>  
>  
> Hello,
>  
> In the documentation of the V5 match service it states that radiuses are 
> “Standard deviation of GPS precision used for map matching. If applicable use 
> GPS accuracy”. If I have HDOP, how would I convert it to the radius value.
>  
> Thank you.
>  
> Artur…
> This e-mail message is confidential, may be privileged and is intended for 
> the exclusive use of the addressee. Any other person is strictly prohibited 
> from disclosing, distributing or reproducing it. If the addressee cannot be 
> reached or is unknown to you, please inform us immediately and delete this 
> e-mail message and destroy all copies. Thank you. 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> 
>  
> This e-mail message is confidential, may be privileged and is intended for 
> the exclusive use of the addressee. Any other person is strictly prohibited 
> from disclosing, distributing or reproducing it. If the addressee cannot be 
> reached or is unknown to you, please inform us immediately and delete this 
> e-mail message and destroy all copies. Thank you. 
> ___
> OSRM-talk mailing list
> OSRM-talk@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/osrm-talk 
> 
___
OSRM-talk mailing list
OSRM-talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/osrm-talk

Re: [Talk-us] SOTM US schedule

[Mike Thompson]

Clifford,

I am also looking at my flights, any idea when the last even on Monday will
be scheduled?

Thanks for all you and other folks in Seattle are doing to put the
conference together.

Mike

On Wed, Jun 15, 2016 at 2:51 PM, Clifford Snow 
wrote:

> Katie,
> We should have the workshop schedule up shortly. We have 11 different
> workshop planned for Monday as well as code sprints. Additionally Maptime
> is planning workshops for Monday as well.
>
> Clifford
>
> On Wed, Jun 15, 2016 at 1:11 PM, Katie Filbert  wrote:
>
>> I'm thinking about attending SOTM US and looking at possible flights.
>>
>> SOTM website says the conference is July 23-July 25, but the program only
>> has July 23 and 24.
>>
>> http://stateofthemap.us/program/
>>
>> Is there some program for July 25, such as hackathon or something?
>>
>> Cheers,
>> Katie
>>
>> --
>> Katie Filbert
>> filbe...@gmail.com
>> @filbertkm / @wikidata
>>
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
>>
>>
>
>
> --
> @osm_seattle
> osm_seattle.snowandsnow.us
> OpenStreetMap: Maps with a human touch
>
> ___
> Talk-us mailing list
> Talk-us@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
>
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-de] JOSM: keine Daten gefunden

[Toni Erdmann]

Hallo,

es scheint mir, was mit dem TLS (https://api.openstreetmap.org/api) 
nicht zu stimmen. In wireshark sehe ich als letztes (vorm RST)


Version TLS 1.2
Alert Message: Encrypted Alert

hat noch jemand ähnliche Probleme?

Gruß,
Toni

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

Re: [Talk-it] contribuire a qualità di openstreetmap su aree verdi

[Lorenzo Mastrogiacomi]

Il giorno ven, 17/06/2016 alle 10.46 -0700, Alecs ha scritto: 
> Inizialmente qualche tempo fa mi pare che chiedesse se si era d'accordo con
> la classificazione dell"area verde" attuale in OSM oppure no, non ho capito
> se a scopi di ricerca o di modifica eventualmente dei dati (mi sembra di più
> il primo).
> 


Invece è il secondo. Per partecipare è anche obbligatorio accedere con
l'account osm...
L'altro giorno ne ho fatto uno distrattamente e adesso ho scoperto che
risulta un changeset.
Mi rendo anche conto adesso che è una cavolata visto che ho
riclassificato solo un pezzo quando li attorno ce ne sono altri dello
stesso tipo.

https://www.openstreetmap.org/way/60386527#map=17/50.91633/7.02908

Lorenzo


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

Re: [Talk-cz] doplnění souřadnic rozcestníku na openstreetmap.cz

[Marián Kyral]

Potvrzuji. Zkoušel jsem a háže mi to chybu "400 - Bad request"
Není mi jasné proč :-(

Nahlásil jsem wallymu na osmcz/api: https://github.com/osmcz/api/issues/26
Marián

Dne 20.6.2016 v 18:29 Zdeněk Pražák napsal(a):
> ono to nefunguje i v jiných případech
> U rozcestníku ref JE275 se po odkliknutí dostanu na
> http://openstreetmap.cz/#map=16/50.2104/16.9903 a rovněž nemohu
> rozcestník přesunout na správné souřadnice 50.2133853  16.9928883
>
> Dne 20. června 2016 17:10 Marián Kyral  > napsal(a):
>
>
> latitude: 50.2074461.16.8473917
> longtitude: 0
>
> Pěkný. Jak se ti to povedlo? :-D
>
> V tomhle případě si s tím aplikace neví rady, protože se
> vygeneruje odkaz:
> 
> http://www.openstreetmap.cz/?mlat=50.2074461.16.8473917=0=16#map=16/50.2074461.16.8473917/0
>
> *@walley*: neměly by se ty souřadnice kontrolovat na to, že se
> jedná o čísla? Přece jen, tři desetinné tečky jsou trochu moc ;-)
>
> *@Petr1868*: Jaké jsou ty správné souřadnice? Zkusil bych to
> posunout přímým voláním API.
>
> Marián
>
> Dne 20.6.2016 v 14:00 Zdeněk Pražák napsal(a):
>> Toto nějak nefunguje - omylemnahrál jsem rozcestník s REF: UO016
>> se špatnými souřadnicemi a chtěl jsem jej tedy opravit:
>> Dosadím UO016, odkliknu, objeví se tabulka, kliknu na osm.cz
>> , objeví se bod na mapě - ale dále jsem nepřišel
>> na to, jak jej přesunout na správné místo. Nefunguje ani
>> poklikání ani přesunutí
>>
>> Dne 17. června 2016 10:39 Michal Grézl
>> > > napsal(a):
>>
>> http://api.openstreetmap.cz/table/ref/xxx za to xxx dosad to
>> co hledas
>> pak klines na odkaz osm.cz  a muzes presouvat
>>
>> --
>> Michal Grézl
>> http://openstreetmap.cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>>
>>
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org 
>> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 19:43, Francesco Piero Paolicelli 
>  ha scritto:
> 
> mi sembra 7min per la precisione


in realtà dipende dalle circostanze, hanno rianimato un bimbo dopo quasi un ora 
in acqua ghiacciata e ce l'ha fatto, ma per un adulto ho anche letto che dopo 3 
minuti i danni sono seri. Poi il resto credo dovremmo discutere in lista 
118-talk ;-)
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

[Talk-cz] velké multipolygony

[Milan Cerny]

Zdravím, poradil by někdo jak je to s velikostí multipolygonu? Na Wiki se píše 
o libovolném počtu inner, outer cest ale o velikosti ne.
Je lepší jeden velký multipolygon, nebo plochu rozdělit na několik menších, 
případně proč?
A poslední dotaz, čím je možné velké multipolygony editovat, všechny základní 
editory velké plochy nezvládají a padají na nedostatku paměti, což může být jen 
problém mého PC. 

Moc díky za rady. 

Milan

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Francesco Piero Paolicelli]

mi sembra 7min per la precisione.

Inviato da iPhone

Il giorno 20 giu 2016, alle ore 14:17, Andrea Lattmann 
 ha scritto:

>> Se una persona ha un infarto e si >interviene nei primi 10 minuti ci sono 
>> >speranze. dopo no..
> 
> ...e poi ci vuole tanta fortuna Dipende da cosa è dovuto l' arresto 
> cardiaco. 
> Comunque ho già in progetto di mappare nella mia zona quelli posti all' 
> esterno dei fabbricati, che piano piano stanno aumentando.
> 
> P.S.: 10 minuti mi sembrano un po tantini (a memoria ricordo 5), comunque 
> prima è meglio è! ;-)
> 
> Andrea Lattmann
> 
> ___
> 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: [OSM-ja] 愛知県の佐久島

[Tomomichi Hayakawa]

そか、Mapillary って手がありますな。
自転車に付けて走り回れるかな。
バッテリーいっぱい持って行こうかな。


2016年6月21日 1:45 Shu Higashi :
> Tomさん、楽しそうなマッピング、いいですね。
> 離島はいろんなタグが使えるので結構好きです。
> 折を見て遠隔参加させて頂きます。
> 現地調査よろしくお願いします。
> MapillaryでひたすらPOIの写真を撮りまくるのがいいかも。
> 東
>
>
> 2016/06/21 Tomomichi Hayakawa :
>> Tomです。
>>
>> 今週末に、愛知県の佐久島に合宿に行きます。
>> たぶん、レンタサイクルでログを取ることができると思います。
>> 夜には、コツコツとマッピングできるかと思われます。（飲みながら？）
>>
>>
>> もし、お時間ある方、後方支援、写経等・・・、いただけると嬉しいです。
>>
>> http://www.openstreetmap.org/#map=16/34.7236/137.0423
>>
>>
>> --
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> はやかわ ともみち (Tomomichi Hayakawa)
>> tom.hayak...@gmail.com
>> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
>> ___
>> Talk-ja mailing list
>> Talk-ja@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-ja
>>
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja



-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
はやかわ ともみち (Tomomichi Hayakawa)
tom.hayak...@gmail.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-ja] 愛知県の佐久島

[Shu Higashi]

Tomさん、楽しそうなマッピング、いいですね。
離島はいろんなタグが使えるので結構好きです。
折を見て遠隔参加させて頂きます。
現地調査よろしくお願いします。
MapillaryでひたすらPOIの写真を撮りまくるのがいいかも。
東


2016/06/21 Tomomichi Hayakawa :
> Tomです。
>
> 今週末に、愛知県の佐久島に合宿に行きます。
> たぶん、レンタサイクルでログを取ることができると思います。
> 夜には、コツコツとマッピングできるかと思われます。（飲みながら？）
>
>
> もし、お時間ある方、後方支援、写経等・・・、いただけると嬉しいです。
>
> http://www.openstreetmap.org/#map=16/34.7236/137.0423
>
>
> --
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> はやかわ ともみち (Tomomichi Hayakawa)
> tom.hayak...@gmail.com
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
> ___
> Talk-ja mailing list
> Talk-ja@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-ja
>
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk] Failed water proposal reversal

[Tomas Straupis]

>>  My main point is to get back to reservoir/basin being tagged as "landuse"
> why would that be desirable?

  There will always be more than one opinion on which naming of tags
is "better" because there is no "universal best way" (unless it's
"42").
  What I'm striving for is STABILITY for tagging.

  Landuse reservoir/basin/etc was there before the water proposal with
hundreds of thousands objects tagged at the time of proposal and it
still is used on more objects than water proposal. That is the reason
why I suggest to roll back to landuse version and make rules/guards so
that such "water" proposals would not go through without a VERY good
reason in the future.

-- 
Tomas

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

Re: [Talk-cz] doplnění souřadnic rozcestníku na openstreetmap.cz

[Zdeněk Pražák]

ono to nefunguje i v jiných případech
U rozcestníku ref JE275 se po odkliknutí dostanu na
http://openstreetmap.cz/#map=16/50.2104/16.9903 a rovněž nemohu rozcestník
přesunout na správné souřadnice 50.2133853  16.9928883

Dne 20. června 2016 17:10 Marián Kyral  napsal(a):

>
> latitude: 50.2074461.16.8473917
> longtitude: 0
>
> Pěkný. Jak se ti to povedlo? :-D
>
> V tomhle případě si s tím aplikace neví rady, protože se vygeneruje odkaz:
> http://www.openstreetmap.cz/?mlat=50.2074461.16.8473917=0=16#map=16/50.2074461.16.8473917/0
>
> *@walley*: neměly by se ty souřadnice kontrolovat na to, že se jedná o
> čísla? Přece jen, tři desetinné tečky jsou trochu moc ;-)
>
> *@Petr1868*: Jaké jsou ty správné souřadnice? Zkusil bych to posunout
> přímým voláním API.
>
> Marián
>
> Dne 20.6.2016 v 14:00 Zdeněk Pražák napsal(a):
>
> Toto nějak nefunguje - omylemnahrál jsem rozcestník s REF: UO016 se
> špatnými souřadnicemi a chtěl jsem jej tedy opravit:
> Dosadím UO016, odkliknu, objeví se tabulka, kliknu na osm.cz, objeví se
> bod na mapě - ale dále jsem nepřišel na to, jak jej přesunout na správné
> místo. Nefunguje ani poklikání ani přesunutí
>
> Dne 17. června 2016 10:39 Michal Grézl 
> napsal(a):
>
>> 
>> http://api.openstreetmap.cz/table/ref/xxx za to xxx dosad to co hledas
>> pak klines na odkaz osm.cz a muzes presouvat
>>
>> --
>> Michal Grézl
>> http://openstreetmap.cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [Talk-cz] doplnění souřadnic rozcestníku na openstreetmap.cz

[Zdeněk Pražák]

správné by měly být souřadnice
50.2074461
16.8473917

Povedlo se mi to tím, že jsem omylem stiskl enter před úpravou souřadnic po
vložení ctrl+V

Dne 20. června 2016 17:10 Marián Kyral  napsal(a):

>
> latitude: 50.2074461.16.8473917
> longtitude: 0
>
> Pěkný. Jak se ti to povedlo? :-D
>
> V tomhle případě si s tím aplikace neví rady, protože se vygeneruje odkaz:
> http://www.openstreetmap.cz/?mlat=50.2074461.16.8473917=0=16#map=16/50.2074461.16.8473917/0
>
> *@walley*: neměly by se ty souřadnice kontrolovat na to, že se jedná o
> čísla? Přece jen, tři desetinné tečky jsou trochu moc ;-)
>
> *@Petr1868*: Jaké jsou ty správné souřadnice? Zkusil bych to posunout
> přímým voláním API.
>
> Marián
>
> Dne 20.6.2016 v 14:00 Zdeněk Pražák napsal(a):
>
> Toto nějak nefunguje - omylemnahrál jsem rozcestník s REF: UO016 se
> špatnými souřadnicemi a chtěl jsem jej tedy opravit:
> Dosadím UO016, odkliknu, objeví se tabulka, kliknu na osm.cz, objeví se
> bod na mapě - ale dále jsem nepřišel na to, jak jej přesunout na správné
> místo. Nefunguje ani poklikání ani přesunutí
>
> Dne 17. června 2016 10:39 Michal Grézl 
> napsal(a):
>
>> 
>> http://api.openstreetmap.cz/table/ref/xxx za to xxx dosad to co hledas
>> pak klines na odkaz osm.cz a muzes presouvat
>>
>> --
>> Michal Grézl
>> http://openstreetmap.cz
>>
>> ___
>> Talk-cz mailing list
>> Talk-cz@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cz
>>
>
>
>
> ___
> Talk-cz mailing 
> listTalk-cz@openstreetmap.orghttps://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Andreas Vilén]

Look at this edit:http://www.openstreetmap.org/node/4253750089/history

Is it not possible to use "special" characters lika åäö in the Maps.me app?
Also, why is it suggesting adding opening hours to a school? Post codes are
also a little dubious, since those aren't open data in Sweden and can
normally only be figured out through local knowledge (as what's on your
letters or if you work as a mail man). We have had some communication with
governing agency Post- och Telestyrelsen but so far they have not agreed
making post code data open. (see also http://www.postnummeruppror.nu/ )

/Andreas

On Mon, Jun 20, 2016 at 5:52 PM, Martin Koppenhoefer  wrote:

>
> 2016-06-20 17:48 GMT+02:00 Martin Koppenhoefer :
>
>> another issue: housenumber added to a building. This is not going to work
>> in Italy, because every entrance of a building gets it's own housenumber.
>> https://www.openstreetmap.org/way/242789192
>>
>
>
> maybe there is more to this (like pre-compiled fields in the app?),
> because a business on the opposite side of the street has the same address:
> https://www.openstreetmap.org/node/4252088796
>
> cheers,
> Martin
>
>
> ___
> talk mailing list
> talk@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-ca] Fusions ou remplacement de chemins et les attributs originaux

[Pierre Béland]

Bonjour Claude
Avec tous les contributeurs qui interviennent, le monitoring des éditions est 
bien sûr important.  L'approche thématique, par exemple piste cyclables, peut 
se faire via des requêtes Overpass.  Il est possbile par exemple de voir les 
éditions au cours de la dernière semaine, du dernier mois.
Voici par exemple une requête couvrant un bbox. Zoom par exemple sur le sud du 
Québec. On y voie beaucoup de modifs depui début mai. 

Cette requête peut être révisée facilement pour y ajouter les différents objets 
reliés aux pistes cyclables. Et à chaque fois on modifie les dates au début de 
la requête.
http://overpass-turbo.eu/s/gTh

  
Pierre 


  De : Alouette955 
 À : talk-ca  
 Envoyé le : lundi 20 juin 2016 11h45
 Objet : [Talk-ca] Fusions ou remplacement de chemins et les attributs originaux
   
Bonjour, Depuis plusieurs semaines je vois apparaitre des réseaux cyclables 
bizarres sur la vue cycliste de osm.org.  En examinant de plus près je constate 
que de nombreuses fusions de chemins occasionnent une duplication des tags ou 
relations cyclables à des portions qui n’en sont pas et en d’autres occasions 
il s’agit de chemins recréés pour lesquels on ne transporte pas tous les tags 
originaux. J’en ai corrigé ou fait corriger des dizaines lorsque je les vois 
sur la carte cyclable. Par contre ceci peut toucher d’autres tags moins 
visibles (maxspeed, lane, oneway, etc ...). Y a-t-il actuellement d’ambitieux 
projets de redéfinition des routes et, si oui, que peut-on faire pour 
sensibiliser les auteurs à tenir compte des tags existants. Il est impossible 
de tous les détecter à l’oeil. Merci, Claude P.S. Malheureusement la vue 
cyclable met un long moment à se rafraichir et les aberrations y demeurent de 
longues semaines sinon des mois.  
___
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

[OSM-ja] 愛知県の佐久島

[Tomomichi Hayakawa]

Tomです。

今週末に、愛知県の佐久島に合宿に行きます。
たぶん、レンタサイクルでログを取ることができると思います。
夜には、コツコツとマッピングできるかと思われます。（飲みながら？）


もし、お時間ある方、後方支援、写経等・・・、いただけると嬉しいです。

http://www.openstreetmap.org/#map=16/34.7236/137.0423


-- 
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
はやかわ ともみち (Tomomichi Hayakawa)
tom.hayak...@gmail.com
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
___
Talk-ja mailing list
Talk-ja@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-ja

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Martin Koppenhoefer]

2016-06-20 17:48 GMT+02:00 Martin Koppenhoefer :

> another issue: housenumber added to a building. This is not going to work
> in Italy, because every entrance of a building gets it's own housenumber.
> https://www.openstreetmap.org/way/242789192
>


maybe there is more to this (like pre-compiled fields in the app?), because
a business on the opposite side of the street has the same address:
https://www.openstreetmap.org/node/4252088796

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Fabrizio Carrai]

Ottima iniziativa!
Mi sto muovendo localmente (per ora nessuna lista...)

FabC

Il giorno 19 giugno 2016 19:03, Francesco Piero Paolicelli <
pierso...@gmail.com> ha scritto:

> Ciao a tutti.
>
> Sono qui a lanciare un'idea / richiedere un consiglio.
>
> Ho realizzato un bot su Telegram, uno dei tantissimi che ho fatto, con uno
> scopo ben preciso.
>
> Insieme al vulcanico Matteo Tempestini, stiamo cercando di creare
> interfacce verso il consumatore finale che riusino opendata governativi o
> comunitari.
> Per rimanere in tema della lista, il bot riusa i dati presenti nel db di
> osm relativamente ai Defibrillatori.
> E' un argomento delicato che per lavoro (sono consigliere opengov in
> alcune PPAA) sto approfondendo. Ci sono alcuni dati a livello territoriali
> importabili ed attendibili. In verità troppo pochi e da valutare.
> A parte Lecce che rilascia in opendata l'elenco puntuale aggiornato ogni
> 15gg e a parte il funzionario del Comune a cui abbiamo insegnato come
> inserirlo in autonomia (il noi è riferito a me e Federico Cortese), gli
> altri elenchi in giro sono tutti da controllare puntualmente: Regione
> Sicilia, http://www.cecchinicuore.org/, http://dae.trentaore.org/
>
> Il totale invece mappato è molto basso: http://overpass-turbo.eu/s/gSj
>
> Il bot li estrae in base alla posizione dell'utente e crea il link per
> trovarli su osm.
> Il bot è anche inlinegeo cioè in qualsiasi chat o gruppo telegram vi
> troviate, basta abilitare il GPS e scrivere @defibrillatoribot e parte
> l'elenco dei più vicini (se presenti)
>
> Qui inizia il problema. Vorrei fare una campagna social di informazione su
> come mappare con pochi click i due tags fondamentali per il bot
> (emergency=defibrillator e name=quellochesivuole) ma partendo da lì
> ovviamente l'attenzione dell'utente potrebbe crescere ed avvicinarsi a
> tutto il mondo di osm e della mappatura.
>
> Quindi vorrei fare un depliant digitale o una pagina web ect da linkare
> nel bot, da promuovere sui socials ect.
> Magari taggando il Ministero della Salute in modo da preoccuparsi di fare
> un dataset a riguardo sul proprio portale opendata... Infatti i DAE
> installati sono segnalati al 118, quindi un censimento esiste...
>
> Una cosa grafica carina con i 3 passaggi magari con le apps più semplici e
> diffuse per ios o android. Stile wheelmap insomma.
>
> Che dite è fattibile? possiamo unire le forze e magari dividerci i compiti?
>
> aspetto le vostre opinioni.
> piersoft
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>
>


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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Martin Koppenhoefer]

another issue: housenumber added to a building. This is not going to work
in Italy, because every entrance of a building gets it's own housenumber.
https://www.openstreetmap.org/way/242789192

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

[Talk-ca] Fusions ou remplacement de chemins et les attributs originaux

[Alouette955]

Bonjour,

Depuis plusieurs semaines je vois apparaitre des réseaux cyclables bizarres sur 
la vue cycliste de osm.org. 

En examinant de plus près je constate que de nombreuses fusions de chemins 
occasionnent une duplication des tags ou relations cyclables à des portions qui 
n’en sont pas et en d’autres occasions il s’agit de chemins recréés pour 
lesquels on ne transporte pas tous les tags originaux.

J’en ai corrigé ou fait corriger des dizaines lorsque je les vois sur la carte 
cyclable. Par contre ceci peut toucher d’autres tags moins visibles (maxspeed, 
lane, oneway, etc ...).

Y a-t-il actuellement d’ambitieux projets de redéfinition des routes et, si 
oui, que peut-on faire pour sensibiliser les auteurs à tenir compte des tags 
existants. Il est impossible de tous les détecter à l’oeil.

Merci,

Claude

P.S. Malheureusement la vue cyclable met un long moment à se rafraichir et les 
aberrations y demeurent de longues semaines sinon des mois.

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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

2016-06-20 17:30 GMT+02:00 Lester Caine :

> The simple fact is that there is not a consistent structure for
> identifying 'landcover' on OSM and even natural=wood and landuse=forest
> make it difficult to decide what is naturally occurring and what is man
> made.
>
landuse=reservoir is a lot more practical where at times of the
> year the majority of the surface area is exposed. That is a totally man
> made situation for which 'natural' does not apply.
>


generally, reading "natural=*" as "made by mother nature" is a bogus
interpretation in my view. It is just a kind of feature-group (geographical
/ landscape feature) for things.




> And when moving onto
> areas like marinas which take several forms including basins on the
> waterway system, including land elements as 'retail' or 'residential'
> and water elements as waterway tags as part of the Relation:waterway.
> But the overall area's landuse is marina even if we currently tag it as
> leisure=marina without any agreement as to just what area that should
> cover.
>


the tag should cover the whole marina, is this difficult to apply?



>
> It's the insistence that water only applies to natural elements which
> just does not fit properly, and man_made=reservoir while much more
> accurate does not fit in with a consistent landcover/landuse overlay?
>


man_made=reservoir would be an option for reservoirs (nothing I would
introduce, just another tag for what already has 2 alternative mapping
methods).
What do you mean by "consistent landcover/landuse overlay"? Those are
orthogonal concepts, with often different boundaries, displaying both (all
of it) at the same time will most likely lead to un unreadable map.

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

Re: [OSM-talk-be] AGIV CRAB import

[Sander Deryckere]

Die beslissing werd genomen om uniforme data in OSM te krijgen, zo dat alle
bisnummers op dezelfde manier genoteerd worden.

Het is vergelijkbaar met een aantal straatnamen die met hoofdletters in
CRAB zitten (i.p.v. enkel de eerste letter een hoofdletter).

zie de code:
https://github.com/aptum/aptum.github.io/blob/master/loadStreets.js#L436

Op 20 juni 2016 17:17 schreef Sus Verhoeven :

> Hooi Sander,
>
> Met een "/" in plaats van een  "_" zijn er geen missings meer, maar dat is
> toch niet helemaal juist. Ik ga de anderen met een "_" maar laten.
>
> Toch bedankt en groetjes.
>
> Sus
>
>
>
>
> 2016-06-20 15:24 GMT+02:00 Sander Deryckere :
>
>> Met de import hebben we geprobeerd om het formaat uniform te houden. Een
>> ik denk dat enkel nummers als 10/4 aanvaard worden, en niet 10_4.
>>
>> Kan je eens met dat formaat proberen? Mogelijk werkt dit ook nog niet
>> meteen, en moet er nog iets aangepast worden aan de code.
>>
>> Mvg,
>> Sander
>> Op 20-jun.-2016 14:24 schreef "Sus Verhoeven" :
>>
>>> Dag Sander,
>>>
>>> In Balen 2490 zijn er missings omdat men daar bis-numbers gebruikt in de
>>> vorm van Nr_1, Nr_2, Nr_3, enz.. in plaats van NrA, NrB, NrC enz..
>>> CRAB en OSM slikken die alsook de zoekfunctie van OSM.
>>>  Zie:
>>> http://www.openstreetmap.org/way/139379759#map=19/51.15796/5.16556
>>> In de Hoolsterberg alleen zijn er  een tiental.
>>> Is daar iets aan te doen ?
>>>
>>> Sus
>>>
>>> ___
>>> Talk-be mailing list
>>> Talk-be@openstreetmap.org
>>> https://lists.openstreetmap.org/listinfo/talk-be
>>>
>>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Martin Koppenhoefer]

2016-06-20 15:03 GMT+02:00 Philip Barnes :

> I guess an example of what I am seeing as a poor quality edit,
> http://osm.org/changeset/40156579
>
> An embassy called Rachel?
> Mistagging of a Monument?
>



well, this seems to be more the kind of "test" some newbies think they have
to perform to really be sure that they are doing online edits ;-)

I have just discovered another type of problem:
* people adding full wikipedia urls into the website tag. In all cases
there was already a wikipedia tag present.

I have now started to add: "Please contact maps.me for further support." at
the end of my changeset comments ;-)

One thing is clear, this new editor brings us an order of magnitude more
edits and new users than before, and if OSM will survive it (i.e. data
quality does not reach abyssal levels) it will be a major boost.

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

Re: [OSM-talk] Failed water proposal reversal

[Lester Caine]

On 20/06/16 15:38, Martin Koppenhoefer wrote:
>> > Il giorno 20 giu 2016, alle ore 12:04, Tomas Straupis 
>> >  ha scritto:
>> > 
>> >  My main point is to get back to reservoir/basin being tagged as "landuse"
> 
> why would that be desirable? Basically landuse is a property of land, and 
> generally it's not very clear how to apply (it depends on the scale, and our 
> db doesn't have a scale). As opposed to this, mapping a reservoir or a basin 
> as a feature is much clearer, you don't have to worry whether you include 
> auxiliary stuff like the service road leading to the reservoir, or the 
> non-water-storage but legally associated areas around it to the feature (you 
> won't).

The simple fact is that there is not a consistent structure for
identifying 'landcover' on OSM and even natural=wood and landuse=forest
make it difficult to decide what is naturally occurring and what is man
made. landuse=reservoir is a lot more practical where at times of the
year the majority of the surface area is exposed. That is a totally man
made situation for which 'natural' does not apply. And when moving onto
areas like marinas which take several forms including basins on the
waterway system, including land elements as 'retail' or 'residential'
and water elements as waterway tags as part of the Relation:waterway.
But the overall area's landuse is marina even if we currently tag it as
leisure=marina without any agreement as to just what area that should cover.

It's the insistence that water only applies to natural elements which
just does not fit properly, and man_made=reservoir while much more
accurate does not fit in with a consistent landcover/landuse overlay?

-- 
Lester Caine - G8HFL
-
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk

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

Re: [OSM-talk-be] AGIV CRAB import

[Sus Verhoeven]

Hooi Sander,

Met een "/" in plaats van een  "_" zijn er geen missings meer, maar dat is
toch niet helemaal juist. Ik ga de anderen met een "_" maar laten.

Toch bedankt en groetjes.

Sus



2016-06-20 15:24 GMT+02:00 Sander Deryckere :

> Met de import hebben we geprobeerd om het formaat uniform te houden. Een
> ik denk dat enkel nummers als 10/4 aanvaard worden, en niet 10_4.
>
> Kan je eens met dat formaat proberen? Mogelijk werkt dit ook nog niet
> meteen, en moet er nog iets aangepast worden aan de code.
>
> Mvg,
> Sander
> Op 20-jun.-2016 14:24 schreef "Sus Verhoeven" :
>
>> Dag Sander,
>>
>> In Balen 2490 zijn er missings omdat men daar bis-numbers gebruikt in de
>> vorm van Nr_1, Nr_2, Nr_3, enz.. in plaats van NrA, NrB, NrC enz..
>> CRAB en OSM slikken die alsook de zoekfunctie van OSM.
>>  Zie:
>> http://www.openstreetmap.org/way/139379759#map=19/51.15796/5.16556
>> In de Hoolsterberg alleen zijn er  een tiental.
>> Is daar iets aan te doen ?
>>
>> Sus
>>
>> ___
>> Talk-be mailing list
>> Talk-be@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-be
>>
>>
> ___
> Talk-be mailing list
> Talk-be@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-be
>
>
___
Talk-be mailing list
Talk-be@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-be

Re: [Talk-cz] doplnění souřadnic rozcestníku na openstreetmap.cz

[Marián Kyral]

latitude: 50.2074461.16.8473917
longtitude: 0

Pěkný. Jak se ti to povedlo? :-D

V tomhle případě si s tím aplikace neví rady, protože se vygeneruje
odkaz:
http://www.openstreetmap.cz/?mlat=50.2074461.16.8473917=0=16#map=16/50.2074461.16.8473917/0

*@walley*: neměly by se ty souřadnice kontrolovat na to, že se jedná o
čísla? Přece jen, tři desetinné tečky jsou trochu moc ;-)

*@Petr1868*: Jaké jsou ty správné souřadnice? Zkusil bych to posunout
přímým voláním API.

Marián

Dne 20.6.2016 v 14:00 Zdeněk Pražák napsal(a):
> Toto nějak nefunguje - omylemnahrál jsem rozcestník s REF: UO016 se
> špatnými souřadnicemi a chtěl jsem jej tedy opravit:
> Dosadím UO016, odkliknu, objeví se tabulka, kliknu na osm.cz
> , objeví se bod na mapě - ale dále jsem nepřišel na to,
> jak jej přesunout na správné místo. Nefunguje ani poklikání ani přesunutí
>
> Dne 17. června 2016 10:39 Michal Grézl  > napsal(a):
>
> http://api.openstreetmap.cz/table/ref/xxx za to xxx dosad to co hledas
> pak klines na odkaz osm.cz  a muzes presouvat
>
> --
> Michal Grézl
> http://openstreetmap.cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-cz
>
>
>
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz

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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[Michael Meier]

> Weil die AFAIK aus unerfindlichen Gründen immer noch keine hstore-Datenbank
> verwenden und dann sind halt neue tags schwierig. Siehe auch
> Burgen/Schlösser.

Die unerfindlichen Gruende sind, dass "die" einen riesengrossen
Rundumschlag und alles auf einmal machen wollen, das muss einfach
schiefgehen und tuts ja auch :-/
Erst moechte man noch ausgiebig benchmarken, welche normalen columns man
entfernen und nur noch im hstore haben sollte, um vielleicht noch 1%
performance rauszukitzeln
(https://github.com/gravitystorm/openstreetmap-carto/issues/1504).
Und jetzt wo sich langsam die Erkenntnis rauskristallisiert, dass das in
diesem Jahrhundert wohl nicht mehr fertig wird, und man einfach so
hstore einfuehren sollte, haengt der entsprechende PR jetzt an
LUA-Problemen
(https://github.com/gravitystorm/openstreetmap-carto/pull/2128) :-/
Aber vielleicht wirds ja doch noch in den naechsten Monaten was.

> Ich lege schlichtweg Wert darauf, dass git blame auf den richtigen Menschen
> zeigt.  Ist das so schwer zu verstehen?

Ach DESWEGEN sind da auf github zwei commits durch den ueberaus
nachverfolgbaren Herrn "Admin @ Navi" ;) (SCNR).
-- 
Michael Meier, Zentrale Systeme
Friedrich-Alexander-Universitaet Erlangen-Nuernberg
Regionales Rechenzentrum Erlangen
Martensstrasse 1, 91058 Erlangen, Germany
Tel.: +49 9131 85-28973, Fax: +49 9131 302941
michael.me...@fau.de
www.rrze.fau.de

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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[Michael Meier]

> Wer einen Eindruck kriegen will wie das jetzt aussieht, hier ist eine URL,
> die auf meinen Testserver Zeigt:
> http://osm.geggus.net/map/ (Links OSMDE rechts OSM Carto)

Gibts auch irgendwo eine solche Vergleichsseite osm-carto-de <->
alter-osm-de?
Wie weit ist das ganze denn deiner Meinung nach? Planst du das ganze
demnaechst fuer die Karte auf openstreetmap.de zu deployen, falls keine
groben Bugs mehr auffallen?

Gruss,
-- 
Michael Meier, Zentrale Systeme
Friedrich-Alexander-Universitaet Erlangen-Nuernberg
Regionales Rechenzentrum Erlangen
Martensstrasse 1, 91058 Erlangen, Germany
Tel.: +49 9131 85-28973, Fax: +49 9131 302941
michael.me...@fau.de
www.rrze.fau.de

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 16:28, Stefano  ha scritto:
> 
> Ma talk-it è diventato talk-118 ?


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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 12:04, Tomas Straupis 
>  ha scritto:
> 
>  My main point is to get back to reservoir/basin being tagged as "landuse"


why would that be desirable? Basically landuse is a property of land, and 
generally it's not very clear how to apply (it depends on the scale, and our db 
doesn't have a scale). As opposed to this, mapping a reservoir or a basin as a 
feature is much clearer, you don't have to worry whether you include auxiliary 
stuff like the service road leading to the reservoir, or the non-water-storage 
but legally associated areas around it to the feature (you won't).

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Stefano]

Il giorno 20 giugno 2016 16:20, Martin Koppenhoefer 
ha scritto:

>
>
> sent from a phone
>
> > Il giorno 20 giu 2016, alle ore 16:13, Andrea Lattmann <
> andrea.guglie...@ga-2.it> ha scritto:
> >
> > Questo mi preoccupa perché è molto importante ossigenare!
>
>
> quando l'hai imparato? Pare che l'american heart association abbia
> cambiato le raccomandazioni per motivi di nuovi risultati di ricerca. Anche
> per me era una novità...
>
>
Ma talk-it è diventato talk-118 ?



> ciao,
> Martin
> ___
> 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] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 16:13, Andrea Lattmann 
>  ha scritto:
> 
> Questo mi preoccupa perché è molto importante ossigenare!


quando l'hai imparato? Pare che l'american heart association abbia cambiato le 
raccomandazioni per motivi di nuovi risultati di ricerca. Anche per me era una 
novità...

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

>non necessariamente soffiare.
Questo mi preoccupa perché è molto importante ossigenare!

Andrea Lattmann

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

>Nella realtà non aiuta quasi mai >nessuno, guardano tutti, anche se ogni 
>>persona con una patente di guida >dovrebbe aver fatto un corso di pronto 
>>soccorso...

Purtroppo hai ragione,  l'ho constatato quanto stavo facendo un massaggio 
cardiaco e chiedevo a gran voce di chiamare il 118, nessuno che si sia degnato! 
Oltre a guardare e a chiedermi se ero in grado di farlo non facevano altro!

Andrea Lattmann

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

Re: [Talk-cl] Como mapear paraderos y recorridos de micros?

[Danilo Lacoste]

Gracias Julio, me pondré a experimentar con esto de las relaciones de
rutas, creo que es algo nuevo para mi.

saludos.

2016-06-19 11:38 GMT-04:00 Julio Costa Zambelli :
> Hola Danilo,
>
> El tema del recorrido se hacía (en los tiempos en que se importaron los
> paraderos del Transantiago) con una etiqueta route_ref=* en el paradero, sin
> embargo esto hoy no es recomendado, y en cambio se pide agregar ese paradero
> a la relación de ruta (route=*) de cada recorrido (10, 12a, 12b, etc.).
>
> http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop
>
> http://wiki.openstreetmap.org/wiki/Relation:route#Bus_routes_.28also_trolley_bus.29
>
> Aquí tienes un ejemplo de una relación de ruta con sus paraderos:
> http://www.openstreetmap.org/relation/5963580
>
> Hay que tener cuidado de no romper otras relaciones al momento de construir
> las de rutas, particularmente cuando se corta un segmento de calle.
>
> En el tema de que el motor de enrutamiento sea capaz de considerar esto,
> dependerá de que este en particular sea capaz de interpretar las relaciones
> de ruta, que además por ahora no existen en Temuco
> (http://www.openstreetmap.org/#map=13/-38.7369/-72.5933=T) y son muy
> pocas en Santiago y otras ciudades.
>
> Saludos,
>
> Julio Costa Zambelli
> Fundación OpenStreetMap Chile
>
> julio.co...@openstreetmap.cl
>
> http://www.openstreetmap.cl/
> Cel: +56(9)89981083
>
> 2016-06-18 21:40 GMT-04:00 Danilo Lacoste :
>>
>> Estimados.
>>
>> En Temuco tenemos nuevos cartelitos en los paraderos que indican todos los
>> medios de transporte público que pasan;  ( por ejemplo micro 10, 12a;
>> 12b...etc) similar a los que se pueden  ver en el transantiago.
>>
>> Como se puede mapear eso?
>>
>> Me imagino que con todos los datos, un motor de rutas podría indicar que
>> micros tomar...
>>
>> Saludos
>>
>>
>> ___
>> Talk-cl mailing list
>> Talk-cl@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-cl
>>
>



-- 
Danilo Lacoste Z.   dan...@lacosox.org
Ing. Civil en informática
www.lacosox.org

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 14:28, Andrea Lattmann 
>  ha scritto:
> 
> E poi ho una domanda: si pensa al cuore, e la rianimazione respiratoria?


si, ovviamente rianimazione vuol dire soffiare in naso o bocca e poi tenere 
qualche flusso di sangue in azione tramite le spinte sul petto (poi, se sei un 
medico dai anche l'adrenalina sintetica ed altro).

Ho appena letto che sono cambiate le raccomandazioni e adesso si deve spingere 
al meno 100 al minuto e non necessariamente soffiare 


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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

sent from a phone

> Il giorno 20 giu 2016, alle ore 14:28, Andrea Lattmann 
>  ha scritto:
> 
> Comunque una rianimazione è più facile a dirsi che a farsi.


si, si vuole un po' di pratica. Con una mano tieni la mente in alto (per 
evitare che la lingua tappi il percorso) e col pollice chiudi la bocca, poi 
soffi nel naso (ovviamente prima devi verificare e liberare le vie 
respiratori). Io ho imparato 2 volte soffiare e 10 spinte sul petto (da solo), 
oppure 1 - 5 se sei in due, ma credo oramai le indicazioni sono leggermente 
cambiate (cambiano ogni qualche anno), tanto, più importante la differenza di 
fare e non fare che variare la quantità di spinte. Al meno in Germania, anche 
se sbagli grosso ma nella volontà di aiutare, nessuno ti potrà fare causa, 
soprattutto se non sei un medico ...
Nella realtà non aiuta quasi mai nessuno, guardano tutti, anche se ogni persona 
con una patente di guida dovrebbe aver fatto un corso di pronto soccorso...

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Philip Barnes]

I guess an example of what I am seeing as a poor quality edit, 
http://osm.org/changeset/40156579

An embassy called Rachel?
Mistagging of a Monument?

Phil (trigpoint)

Phil 

On Mon Jun 20 12:52:13 2016 GMT+0100, Philip Barnes wrote:
> On Mon, 2016-06-20 at 11:26 +0200, Martin Koppenhoefer wrote:
> > 
> > 2016-06-19 22:35 GMT+02:00 Ilya Zverev :
> > > As for the maps.me, I am glad that foreign names issue is basically
> > > the only one that most people agree on.
> > > 
> > 
> > there are lots of different issues, and even if many of them have not
> > yet commented on them, I still believe they do have the potential to
> > harm overall data quality. From the manual reviews I have performed
> > so far, the amount of new issues introduced was far bigger than the
> > useful information that has been added, but I didn't look at enough
> > data to make this representative in any way (of course).
> > 
> > Some of the issues that come to mind:
> > 1. stuff put projected to the middle of the road rather than the
> > actual position (common newbie error, possibly because that's how
> > google and others present search results)
> > 2. stuff put without a tag what it is (just a name and a property
> > like tourism=attraction)
> > 3. duplicates added (things that are already there)
> > 4. poor semantic level (very low detail in tagging, in some
> > occassions to a point where it becomes not understandable any more,
> > sometimes mistagged as something vaguely similar)
> > 5. sometimes missplaced objects far off (likely due to bad location
> > data in the device and users not familiar with the area, and not
> > willing to properly orient themselves)
> > 
> Many of these are newbie errors, the same as we see with any other
> editor however the big difference I see with maps.me is the apparent
> lack of reaction to changeset comments that allow the community to help
> newbies through their initial edits. When adding comments to maps.me
> changesets I do get the feeling I am wasting my time.
> Another observation I see is the geographical spread of edits, a bar in
> Portugal followed by a guest house in the UK about the local knowledge
> of what they are adding.
> Phil (trigpoint)
> 
>

-- 
Sent from my Jolla
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-it] DAE e furti

[Marco Predicatori]

Andrea Lattmann wrote on 20/06/2016 14:17:

> ...ho già in progetto di mappare nella
> mia zona quelli posti all' esterno dei fabbricati, che piano
> piano stanno aumentando.

Approfitto del thread per segnalare una cosa che spero sia solo una
mia paranoia. L'anno scorso, in occasione di un mapping party, è
stato mappato questo: https://www.openstreetmap.org/node/3822927184

Era lì da anni, e pochi giorni dopo la sua comparsa su OSM è stato
rubato:
http://gazzettadimantova.gelocal.it/mantova/cronaca/2015/11/13/news/ladri-senza-cuore-sparito-il-defibrillatore-dalla-piazza-di-volta-1.12442624

Mi è sembrata una coincidenza stratosferica. Quando mappate un DAE,
provate a vedere poi se per caso viene rubato. SGRAT! Hai visto mai
che diamo alle FFOO qualche spunto di indagine, tipo da che IP è
stato scaricato l'elenco dei DAE...

Qualche tempo fa il DAE di Volta è stato sostituito, ora l'ho rimappato.

Ciao, Marco

-- 
https://www.openstreetmap.org/user/marco69

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Oleksiy Muzalyev]

Maps.me editor has got the principal difference from other editors, - it 
can be used without an active Internet connection. It means it is 
possible now to map in wilderness, in mountains, while traveling without 
worrying about roaming fees. Couple of years ago I used the Google maps 
on smartphone for several minutes to find an address in Milan and paid 
later an equivalent of 400 USD of roaming charges.


Facebook is completely internationalized. One can use Facebook in 113 
(!) languages. Facebook users after signing into Maps.me Editor with 
their Facebook credentials, probably, also expect a seamless exhaustive 
internationalization, which is not the case for any world map yet at 
all. But they may not know it and keep using one of those 113 languages 
unsuspectingly for mapping too. We were already informed that Maps.me 
will address this linguistic issue in future releases.


Best regards,
Oleksiy

On 20.06.2016 13:52, Philip Barnes wrote:


Many of these are newbie errors, the same as we see with any other 
editor however the big difference I see with maps.me is the apparent 
lack of reaction to changeset comments that allow the community to 
help newbies through their initial edits. When adding comments to 
maps.me changesets I do get the feeling I am wasting my time.


Another observation I see is the geographical spread of edits, a bar 
in Portugal followed by a guest house in the UK about the local 
knowledge of what they are adding.


Phil (trigpoint)


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



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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Edoardo Yossef Marascalchi]

grazie alla tua mail ho mappato un defibrillatore in israele. a quanto
pare, l'unico mappato.
Mi impegno a mapparne altri :)

Il giorno 20 giugno 2016 15:28, Andrea Lattmann 
ha scritto:

> >in realtà le ambulanze hanno un >defibrillatore non automatico (al meno
> >qualche tempo fa era così).
>
> E' ormai da parecchi anni che hanno oltre al manuale, anche il DAE
> semiautomatico con personale certificato 118 all' utilizzo.
> Comunque una rianimazione è più facile a dirsi che a farsi. E poi ho una
> domanda: si pensa al cuore, e la rianimazione respiratoria? Se mappo un DAE
> e vedo che ci sono pure gli strumenti per la respirazione (cannula
> oro-faringea, ambu), c'è un tag specifico?
>
> Andrea Lattmann
>
> ___
> Talk-it mailing list
> Talk-it@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-it
>



-- 
Edoardo Yossef Marascalchi
skype: asca_edom
___
Talk-it mailing list
Talk-it@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-it

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

>in realtà le ambulanze hanno un >defibrillatore non automatico (al meno 
>>qualche tempo fa era così).

E' ormai da parecchi anni che hanno oltre al manuale, anche il DAE 
semiautomatico con personale certificato 118 all' utilizzo.
Comunque una rianimazione è più facile a dirsi che a farsi. E poi ho una 
domanda: si pensa al cuore, e la rianimazione respiratoria? Se mappo un DAE e 
vedo che ci sono pure gli strumenti per la respirazione (cannula oro-faringea, 
ambu), c'è un tag specifico? 

Andrea Lattmann

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

[OSM-talk-be] AGIV CRAB import

[Sus Verhoeven]

Dag Sander,

In Balen 2490 zijn er missings omdat men daar bis-numbers gebruikt in de
vorm van Nr_1, Nr_2, Nr_3, enz.. in plaats van NrA, NrB, NrC enz..
CRAB en OSM slikken die alsook de zoekfunctie van OSM.
 Zie:
http://www.openstreetmap.org/way/139379759#map=19/51.15796/5.16556
In de Hoolsterberg alleen zijn er  een tiental.
Is daar iets aan te doen ?

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

Re: [OSM-talk-fr] Bonnes et moins bonnes visibilités OSM

[Tony Emery]

Christian Rogel wrote
> Tony nous parle d’adresse cadastrale, il veut, bien sûr, dire «  adresse
> enregistrée dans le cadastre », sans qu’elle acquière une « nature »
> cadastrale.
> Fondamentalement, c’est un bien commun créé par l’autorité municipale et
> laissé à la disposition de tous. Une fois dans OSM, on ne doit y toucher
> que, si l’autorité publique la modifie.

Je ne sais pas si on dit la même chose mais, dans les faits, quand une
collectivité émet une délibération de numérotation d'une voie (publique ou
non, d'ailleurs), elle indique bien pour chaque numéro les parcelles
concernées par ce numéro. 

Par contre, il y a une relation complexe entre 1/n adresses <=> 1/n
parcelles <=> 1/n habitations

De manière générale, un numéro est attribué à une parcelle, mais on peut
avoir aussi :
- une parcelle qui contient plusieurs numéros parce qu'il y a plusieurs
habitations sur cette parcelle ;
- plusieurs parcelles ne contenant qu'une seule habitation et rattachées à
une seule parcelle ;
- plusieurs parcelles contenant plusieurs habitations et rattachées à une
seule parcelle ;

D'ailleurs, aux impôts, on préfère utiliser la "parcelle de référence" à la
place de la parcelle et on parle de "local" plutôt que "d'habitation".



-
Tony EMERY
Administrateur OpenStreetMap.fr
Mandataire Grand Sud-Est
Géomaticien & chef de projets
--
View this message in context: 
http://gis.19327.n5.nabble.com/Bonnes-et-moins-bonnes-visibilites-OSM-tp5875216p5875967.html
Sent from the France mailing list archive at Nabble.com.

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Andrea Lattmann]

>Se una persona ha un infarto e si >interviene nei primi 10 minuti ci sono 
>>speranze. dopo no..

...e poi ci vuole tanta fortuna Dipende da cosa è dovuto l' arresto 
cardiaco. 
Comunque ho già in progetto di mappare nella mia zona quelli posti all' esterno 
dei fabbricati, che piano piano stanno aumentando.

P.S.: 10 minuti mi sembrano un po tantini (a memoria ricordo 5), comunque prima 
è meglio è! ;-)

Andrea Lattmann

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

Re: [Talk-cz] doplnění souřadnic rozcestníku na openstreetmap.cz

[Zdeněk Pražák]

Toto nějak nefunguje - omylemnahrál jsem rozcestník s REF: UO016 se
špatnými souřadnicemi a chtěl jsem jej tedy opravit:
Dosadím UO016, odkliknu, objeví se tabulka, kliknu na osm.cz, objeví se bod
na mapě - ale dále jsem nepřišel na to, jak jej přesunout na správné místo.
Nefunguje ani poklikání ani přesunutí

Dne 17. června 2016 10:39 Michal Grézl 
napsal(a):

> http://api.openstreetmap.cz/table/ref/xxx za to xxx dosad to co hledas
> pak klines na odkaz osm.cz a muzes presouvat
>
> --
> Michal Grézl
> http://openstreetmap.cz
>
> ___
> Talk-cz mailing list
> Talk-cz@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-cz
>
___
Talk-cz mailing list
Talk-cz@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-cz

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Philip Barnes]

On Mon, 2016-06-20 at 11:26 +0200, Martin Koppenhoefer wrote:
> 
> 2016-06-19 22:35 GMT+02:00 Ilya Zverev :
> > As for the maps.me, I am glad that foreign names issue is basically
> > the only one that most people agree on.
> > 
> 
> there are lots of different issues, and even if many of them have not
> yet commented on them, I still believe they do have the potential to
> harm overall data quality. From the manual reviews I have performed
> so far, the amount of new issues introduced was far bigger than the
> useful information that has been added, but I didn't look at enough
> data to make this representative in any way (of course).
> 
> Some of the issues that come to mind:
> 1. stuff put projected to the middle of the road rather than the
> actual position (common newbie error, possibly because that's how
> google and others present search results)
> 2. stuff put without a tag what it is (just a name and a property
> like tourism=attraction)
> 3. duplicates added (things that are already there)
> 4. poor semantic level (very low detail in tagging, in some
> occassions to a point where it becomes not understandable any more,
> sometimes mistagged as something vaguely similar)
> 5. sometimes missplaced objects far off (likely due to bad location
> data in the device and users not familiar with the area, and not
> willing to properly orient themselves)
> 
Many of these are newbie errors, the same as we see with any other
editor however the big difference I see with maps.me is the apparent
lack of reaction to changeset comments that allow the community to help
newbies through their initial edits. When adding comments to maps.me
changesets I do get the feeling I am wasting my time.
Another observation I see is the geographical spread of edits, a bar in
Portugal followed by a guest house in the UK about the local knowledge
of what they are adding.
Phil (trigpoint)

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

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Philippe Verdy]

Osmose n'a pas à imposer cette norme, un point c'est tout. Il fait ça à
l'aveugle...

En revanche Osmose ferait bien de s'occuper de détecter l'usage des
abréviations impropres ("Bvd" au lieu du mot générique "boulevard", qui lui
aussi devrait garder sa minuscule...), et s'il veut peut aussi unifier les
acronymes (l'usage des points entre chaque lettre n'est plus la norme
depuis les années 1970, même si avant on écrivait "S.N.C.F." maintenant
c'est "SNCF".

De toute façon Osmose sur les valeurs de "name=*" devrit être bien plus
prudent, les formes sont libres et il y a plus de variété que ce qu'on
croit. Donc ne pas signaler ça en erreur, juste éventiuellement une alerte
avec un niveau de priorité très bas.

Les rendus peuvent alors faire les transformations qu'ils veulent selon le
style qu'ils veulent (y compris écrire les libellés entièrement en
capitales si ça les chante). En revanche le rendu  Mapnik d'OSM ne le fera
pas (son but est de montrer les données le plus fidèlement possible sans
transformations, et ses règles sont mondiales et il est très difficile pour
lui de connaitre les règles de toutes les langues puisqu'il ne les
distingue pas et n'affiche que les noms par défaut sans une langue supposée
locale).

Le 20 juin 2016 à 12:57, Francois Gouget  a écrit :

> On Mon, 20 Jun 2016, Philippe Verdy wrote:
> [...]
> > >  * Pour aider les moteurs de rendu, OpenStreetMap pourrait ajouter un
> > >champ 'ign_name' ou 'suggested_name_on_map' (nom du champ à définir)
> > >avec le nom suivant les règles de l'IGN. Mais je vois ça comme une
> > >question d'implémentation : un choix entre plus de code ou plus de
> > >données.
> >
> > Inutile: stocker directement les minuscules où elles sont permises. C'est
> > le rendu qui fera ou pas la conversion en majuscule de l'initiale ou de
> la
> > totalité du nom.
> > Pas besoin de cette redondance.
> [...]
> > Ce pseudo-standard imposé n'a pas lieu d'être dans les données.
> L'écriture
> > latine et le français sont bicamérals et les distinctions de casse sont
> > signifiantes dans de nombreux cas. Supprimer ces diférences c'est comem
> si
> > on imposait que les dictionnaires français ne contiennent que ds mots en
> > majuscules. En fait rien n'autorise de convertir automatiquement un "Le
> > ..." initial ou un "l'..." initial en "le ..." ou "l'...", alors que
> > l'inverse est possible de façon automatique. La remarque s'étend aussi
> aux
> > mots génériques (noms de rues: "rue Xyz" et non "Rue Xyz").
>
> Cet argument me va. Pour les problèmes de conversion majuscules <->
> minuscule je pensais principalement à la question des accents où dans
> certaines langues/scripts cela pose problème. Mais cet argument de la
> simplicité des règles typographiques pour les conversion minuscule ->
> majuscule par rapport aux règles pour la transformation inverse est tout
> à fait pertinent.
>
> Le problème c'est que si on n'est que deux à prendre cette décision ça
> ne va pas marcher. Peut-on établir un consensus plus large ? Et
> notamment il faudrait qu'Osmose soit adapté aux nouvelles règles.
>
>
> --
> Francois Gouget   http://fgouget.free.fr/
>  Research is the transformation of money to knowledge.
> Innovation is the transformation of knowledge to money.
>   -- Dr. Hans Meixner
___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk-fr] Majuscule à l'article défini sur les lieux-dits ?

[Francois Gouget]

On Mon, 20 Jun 2016, Philippe Verdy wrote:
[...]
> >  * Pour aider les moteurs de rendu, OpenStreetMap pourrait ajouter un
> >champ 'ign_name' ou 'suggested_name_on_map' (nom du champ à définir)
> >avec le nom suivant les règles de l'IGN. Mais je vois ça comme une
> >question d'implémentation : un choix entre plus de code ou plus de
> >données.
> 
> Inutile: stocker directement les minuscules où elles sont permises. C'est
> le rendu qui fera ou pas la conversion en majuscule de l'initiale ou de la
> totalité du nom.
> Pas besoin de cette redondance.
[...]
> Ce pseudo-standard imposé n'a pas lieu d'être dans les données. L'écriture
> latine et le français sont bicamérals et les distinctions de casse sont
> signifiantes dans de nombreux cas. Supprimer ces diférences c'est comem si
> on imposait que les dictionnaires français ne contiennent que ds mots en
> majuscules. En fait rien n'autorise de convertir automatiquement un "Le
> ..." initial ou un "l'..." initial en "le ..." ou "l'...", alors que
> l'inverse est possible de façon automatique. La remarque s'étend aussi aux
> mots génériques (noms de rues: "rue Xyz" et non "Rue Xyz").

Cet argument me va. Pour les problèmes de conversion majuscules <-> 
minuscule je pensais principalement à la question des accents où dans 
certaines langues/scripts cela pose problème. Mais cet argument de la 
simplicité des règles typographiques pour les conversion minuscule -> 
majuscule par rapport aux règles pour la transformation inverse est tout 
à fait pertinent.

Le problème c'est que si on n'est que deux à prendre cette décision ça 
ne va pas marcher. Peut-on établir un consensus plus large ? Et 
notamment il faudrait qu'Osmose soit adapté aux nouvelles règles.


-- 
Francois Gouget   http://fgouget.free.fr/
 Research is the transformation of money to knowledge.
Innovation is the transformation of knowledge to money.
  -- Dr. Hans Meixner___
Talk-fr mailing list
Talk-fr@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-fr

Re: [OSM-talk] Failed water proposal reversal

[Tomas Straupis]

> You need to decide if you want to abolish the water=* or if you just
> prefer using waterway=riverbank instead of natural=water +
> water=river - which does not in any way conflict with the water=* tag.

  Once again: I do not want to abolish water=*.

  My main point is to get back to reservoir/basin being tagged as "landuse".

  So basically getting back to the state things were before the water
proposal (and adding water=* for those who want to tag more details
about natural water bodies, because adding water=* does not break
anything while deprecating widespread use of
landuse=reservoir/basin/etc is breaking a lot of stuff).

-- 
Tomas

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

Re: [Talk-it] DAE su osm con la scusa di un bot Telegram

[Martin Koppenhoefer]

2016-06-20 8:16 GMT+02:00 Francesco Piero Paolicelli :

>
> il 118 sa che nella scuola XY c'è un DAE. il problema si pone non tanto
> per l'ambulanza che arriva sul posto (che ha il DAE con se) ma per i
> migliaia di volontari "laici" che hanno fatto il corso di primo intervento.
>


in realtà le ambulanze hanno un defibrillatore non automatico (al meno
qualche tempo fa era così).



> Se una persona ha un infarto e si interviene nei primi 10 minuti ci sono
> speranze. dopo no..
>


10 minuti mi sembra tantissimo, nel caso che il cuore non trasporta più
ossigeno al cervello, 5 minuti sono già un limite critico (dopodichè avrai
quasi sicuro i danni molto seri e inrevertibili). Oltre ad affidarsi ad un
defibrillatore automatico (che comunque male non fa se automatico e "spara"
solo nel caso che si deve) sarebbe da fare al più presto (ogni seconda
conta) una reanimazione per assicurare che un minimo di ossigeno arrivi nel
cervello, poi l'ambulanza avrà gli appositi mezzi per tentare di rimettere
il cuore in funzione "normale" (iniezione di medicinali, defibrillazione
nel caso di  fibrillazione/flutter/tachicardia/... ventricolare).

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

Re: [OSM-talk] Failed water proposal reversal

[Christoph Hormann]

On Monday 20 June 2016, Tomas Straupis wrote:
> >
> > If you want to eliminate use of water=* from OSM you'd need to
> > convince the community of this.  A formal proposal can be used but
> > without convincing arguments on the matter this stands little
> > chance in being approved.
>
>   I do not want to „eliminate“ water=*
>   I want to go back to the situation before the water proposal - with
> landuse=reservoir, waterway=riverbank, landuse=basin, etc. etc. As it
> used to be, and as it was and is still being mapped.

You need to decide if you want to abolish the water=* or if you just 
prefer using waterway=riverbank instead of natural=water + 
water=river - which does not in any way conflict with the water=* tag.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [OSM-talk] Failed water proposal reversal

[Christoph Hormann]

On Monday 20 June 2016, you wrote:
>
> I'd like to add to this that on a semantic / natural language level,
> waterway=riverbank (deliberately ignoring long standing, widespread
> use and acceptance) would seem to indicate a riverbank, i.e. the bank
> of a river, or in other words, the area along a river, which will
> occassionally but not always be flooded.

Indeed - not separating actual water mapping from mapping geomorphology 
is one of the primary disadvantages of the waterway=riverbank tag (for 
which as said there are advantages too) - and is partly responsible for 
quite a few cases where water mapping covers the whole floodplain of a 
braided river like here:

http://www.openstreetmap.org/#map=12/46.0764/12.8456

Similar situation by the way with landuse=reservoir/landuse=basin - 
acutal presence of water vs. dedication of an area for certain use.

-- 
Christoph Hormann
http://www.imagico.de/

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

Re: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru

[Kushan Joshi]

Hey Shibu,

> What kind of expertise(programming?) is required to participate in this event?

You don’t necessarily need to have an expertise, familiarity with languages 
that the OSM projects use would do. 
For e.g., in iD editor you need to be comfortable with Javascript and maybe a 
little bit of D3.

Let me know if you have any further doubts,

Kushan

> From: Kushan Joshi [mailto:0o3...@gmail.com ] 
> Sent: Monday, June 20, 2016 1:06 PM
> To: talk-in@openstreetmap.org 
> Subject: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru
>  
> Hey everyone,
> 
> I wanted to invite all of you to the OpenStreetMap hackweekend on July 2 and 
> 3 at Mapbox in Bangalore. We will spend two full days working on projects 
> like iD, openstreetmap-website, JOSM  etc. You can see all the projects and 
> ideas in the wiki 
> http://wiki.openstreetmap.org/wiki/Bengaluru_Hack_weekend_July_2016 
> . Pick 
> one or propose your own.
> 
> If you are in town and want to contribute to OpenStreetMap, this is a great 
> opportunity! Please RSVP (https://osmhackweekend.splashthat.com/ 
> ) and let me know if you have any 
> questions. 
> 
> Read more: https://www.mapbox.com/blog/osm-hackweekend/ 
> 
> Looking forward!
> 
> Cheers,
> 
> Kushan
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-in 
> 
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru

[Kushan Joshi]

Hey Shibu,

> What kind of expertise(programming?) is required to participate in this event?

You don’t necessarily need to have an expertise, familiarity with languages 
that the OSM projects use would do. 
For e.g., in iD editor you need to be comfortable with Javascript and maybe a 
little bit of D3.

Let me know if you have any further doubts,

Kushan

> From: Kushan Joshi [mailto:0o3...@gmail.com ] 
> Sent: Monday, June 20, 2016 1:06 PM
> To: talk-in@openstreetmap.org 
> Subject: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru
>  
> Hey everyone,
> 
> I wanted to invite all of you to the OpenStreetMap hackweekend on July 2 and 
> 3 at Mapbox in Bangalore. We will spend two full days working on projects 
> like iD, openstreetmap-website, JOSM  etc. You can see all the projects and 
> ideas in the wiki 
> http://wiki.openstreetmap.org/wiki/Bengaluru_Hack_weekend_July_2016 
> . Pick 
> one or propose your own.
> 
> If you are in town and want to contribute to OpenStreetMap, this is a great 
> opportunity! Please RSVP (https://osmhackweekend.splashthat.com/ 
> ) and let me know if you have any 
> questions. 
> 
> Read more: https://www.mapbox.com/blog/osm-hackweekend/ 
> 
> Looking forward!
> 
> Cheers,
> 
> Kushan
> ___
> Talk-in mailing list
> Talk-in@openstreetmap.org 
> https://lists.openstreetmap.org/listinfo/talk-in 
> 
___
Talk-in mailing list
Talk-in@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-in

Re: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru

[Shibu Narayanan]

HI,

What kind of expertise(programming?) is required to participate in this event?

 

Shibu Narayanan 



 

From: Kushan Joshi [mailto:0o3...@gmail.com] 
Sent: Monday, June 20, 2016 1:06 PM
To: talk-in@openstreetmap.org
Subject: [Talk-in] OpenStreetMap Hack Weekend at Mapbox Bengaluru

 

Hey everyone,

I wanted to invite all of you to the OpenStreetMap hackweekend on July 2 and 3 
at Mapbox in Bangalore. We will spend two full days working on projects like 
iD, openstreetmap-website, JOSM  etc. You can see all the projects and ideas in 
the wiki http://wiki.openstreetmap.org/wiki/Bengaluru_Hack_weekend_July_2016. 
Pick one or propose your own.

If you are in town and want to contribute to OpenStreetMap, this is a great 
opportunity! Please RSVP (https://osmhackweekend.splashthat.com/) and let me 
know if you have any questions. 

Read more: https://www.mapbox.com/blog/osm-hackweekend/

Looking forward!

Cheers,

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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

2016-06-20 11:29 GMT+02:00 Tomas Straupis :

>   My main point is that existing tagging (especially widely used one)
> should not be changed unless it gives some ontological benefit (new
> features/properties being added, features split etc.).
>


actually you do not have to change any existing tagging when you implement
the "new" water=* tags, both can coexist without problems. I do agree that
changing (i.e. removing of established tags) is not the right approach to
add more detail.

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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

2016-06-20 11:34 GMT+02:00 Tomas Straupis :

> > actually the way it was before HAD big issues, you could not even state
> if
> > something was a lake or just the basin of a fountain (most kind of water
> > areas just mapped as natural=water).
>
>   Everything what can be mapped with new water schema can be (and is)
> mapped with old schema.
>


no, or at least not with the same semantic detail (one example is in the
text you have cited above)




>
>   The problem with newbies adding everything as natural=water did not
> go away. Now most iD edits create natural=water|water=pond even if it
> is a reservoir or a lake. So once again - no ontological difference
> here.



Now you are mixing up tag semantics (what can be expressed with the tags)
with people not applying them correctly (e.g. supposedly for editing
software weaknesses), and then draw the conclusion that the tags are bad.

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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[Martin Koppenhoefer]

Am 20. Juni 2016 um 10:29 schrieb Sven Geggus :

>
> Ich habe mit views und hstore only eigentlich gute Erfahrungen gemacht.
>
>
> https://github.com/giggls/openstreetmap-carto-de/blob/master/hstore-only.style




ja, ich muss zugeben, ich verstehe auch nicht, warum das so langsam geht
beim internationalen Stil, der Performance-Malus ist AFAIR um die 10%, das
ist zwar nicht völlig ignorierbar, aber auch nicht so signifikant, dass es
rechtfertigen würde, weiterhin die meisten detaillierteren tags
wegzuschmeissen ;-)
OSM lebt ja u.A. auch von der Vielfalt und Tiefe der Informationen.

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

Re: [OSM-talk] Failed water proposal reversal

[Tomas Straupis]

> actually the way it was before HAD big issues, you could not even state if
> something was a lake or just the basin of a fountain (most kind of water
> areas just mapped as natural=water).

  Everything what can be mapped with new water schema can be (and is)
mapped with old schema.

  The problem with newbies adding everything as natural=water did not
go away. Now most iD edits create natural=water|water=pond even if it
is a reservoir or a lake. So once again - no ontological difference
here.

-- 
Tomas

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

Re: [Talk-de] Neues vom deutschen OSM-Kartenstil

[Martin Koppenhoefer]

Am 20. Juni 2016 um 09:40 schrieb Sven Geggus :


> Ohne technische basiskenntnisse hilft man mir halt nun mal nicht wirklich.
> Das Problem der Maintenance am deustchen Kartenstil (ich wiederhole mich)
> sind nicht neue features.
>


klar, technische Basiskenntnisse braucht man, aber die Frage ist in welchem
Feld. Es geht beim Kartengestalten halt nicht nur um technische
Programmierkenntnisse, sondern auch (und vor allem) um gestalterische
Fähigkeiten.

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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

2016-06-20 11:14 GMT+02:00 Tomas Straupis :

>   I do not want to „eliminate“ water=*
>   I want to go back to the situation before the water proposal - with
> landuse=reservoir, waterway=riverbank, landuse=basin, etc. etc. As it
> used to be, and as it was and is still being mapped.
>


actually the way it was before HAD big issues, you could not even state if
something was a lake or just the basin of a fountain (most kind of water
areas just mapped as natural=water).

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

Re: [OSM-talk] Failed water proposal reversal

[Tomas Straupis]

> I'd like to add to this that on a semantic / natural language level,
> waterway=riverbank (deliberately ignoring long standing, widespread use and
> acceptance) would seem to indicate a riverbank, i.e. the bank of a river, or
> in other words, the area along a river, which will occassionally but not
> always be flooded.
>
> I am at this point not proposing to remap all of these (unless there would
> be compelling agreement by many mappers), as this is a longstanding, very
> widespread tag (293.000 occurences, 31.700 of them relations) with
> supposedly uniform usage, but it should be noted that there are issues with
> it on a logical level.

  My main point is that existing tagging (especially widely used one)
should not be changed unless it gives some ontological benefit (new
features/properties being added, features split etc.). I think that
data consumers want stability more than they want tag names to be
defined with "more correct" words (especially then lots of consumers
are not from English speaking countries).

  This is why water proposal was wrong in the first place. I agree
that it somehow slipped (I accept my guilt as well because I didn't do
anything at the time of proposal). But if after five years mappers did
not accept it by mapping, maybe it is not too late to revert the
proposal (not tags by automated edits).

-- 
Tomas

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

Re: [OSM-talk] MAPS.ME edits - partly sub-standard

[Martin Koppenhoefer]

2016-06-19 22:35 GMT+02:00 Ilya Zverev :

> As for the maps.me, I am glad that foreign names issue is basically the
> only one that most people agree on.
>


there are lots of different issues, and even if many of them have not yet
commented on them, I still believe they do have the potential to harm
overall data quality. From the manual reviews I have performed so far, the
amount of new issues introduced was far bigger than the useful information
that has been added, but I didn't look at enough data to make this
representative in any way (of course).

Some of the issues that come to mind:
1. stuff put projected to the middle of the road rather than the actual
position (common newbie error, possibly because that's how google and
others present search results)
2. stuff put without a tag what it is (just a name and a property like
tourism=attraction)
3. duplicates added (things that are already there)
4. poor semantic level (very low detail in tagging, in some occassions to a
point where it becomes not understandable any more, sometimes mistagged as
something vaguely similar)
5. sometimes missplaced objects far off (likely due to bad location data in
the device and users not familiar with the area, and not willing to
properly orient themselves)

I guess it depends very much on the area where you are editing, in a
densely mapped, detailed area there is very few you can contribute with a
simple editor like maps.me, mostly useful to correct mispellings and
changes like things that have gone, while in a poorly mapped area we might
get useful contributions by at least something added where before there
were only voids.




> We are of course aware of it, and either in the coming release, or the one
> after it, we will introduce a multilanguage name editor.
>


this is great news. I suggest you first ask the users, which language they
are going to add the name, and then let them add the name (this way they
will be less likely modifying the existing  name in local language).

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

Re: [OSM-talk] Failed water proposal reversal

[Tomas Straupis]

> You are either deliberately or due to misinformation distorting things
> here.  The water=* is widely used and accepted, there are >700k uses in
> line with the proposal (an additional 255k for the deprecated
> water=intermittent).
>
> The waterway=riverbank tag is considered equivalent to natural=water +
> water=river, mappers may use either depending on what they prefer.
> There are good arguments for either of these options.
>
> If you want to eliminate use of water=* from OSM you'd need to convince
> the community of this.  A formal proposal can be used but without
> convincing arguments on the matter this stands little chance in being
> approved.

  I do not want to „eliminate“ water=*
  I want to go back to the situation before the water proposal - with
landuse=reservoir, waterway=riverbank, landuse=basin, etc. etc. As it
used to be, and as it was and is still being mapped.

> You however must not retag features with those tags to something else
> just for its own sake (i.e. outside normal mapping) - this would not be
> acceptable and would ultimately lead to reversal of such changes and
> possibly bans from editing.

  At least in Lithuania we have an agreement for YEARS as how to map
water bodies and we ARE updating mapping in Lithuania according to
those agreements, because this is what data consumers are expecting.

> If you want to do something productive you could clean up the frequent
> occurences of duplicate and sometimes contradicting tags on member ways
> and multipolygon relations for river mapping.  One of the problems of
> the waterway=riverbank tag is that it was originally meant and is
> widely understood to be a way tag while today it should normally be
> applied to the multipolygons relation.  Cleaning up such ambiguities -
> not mechanically as it has been suggested in the past but with
> individual verification - using either waterway=riverbank or
> natural=water + water=river would be a very good deed.

  If in the final GIS database we get a POLYGON with
waterway=riverbank I see no difference as to how it was mapped - as a
way, or as a relation.

  If you are referring to the old problem where tags are placed on
outer way in relation rather than a relation itself then yes, that is
a problem but it has nothing to do with discussion about water
tagging.

-- 
Tomas

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

Re: [OSM-talk] Failed water proposal reversal

[Martin Koppenhoefer]

2016-06-20 10:48 GMT+02:00 Christoph Hormann :

> If you want to do something productive you could clean up the frequent
> occurences of duplicate and sometimes contradicting tags on member ways
> and multipolygon relations for river mapping.  One of the problems of
> the waterway=riverbank tag is that it was originally meant and is
> widely understood to be a way tag while today it should normally be
> applied to the multipolygons relation.  Cleaning up such ambiguities -
> not mechanically as it has been suggested in the past but with
> individual verification - using either waterway=riverbank or
> natural=water + water=river would be a very good deed.
>


I'd like to add to this that on a semantic / natural language level,
waterway=riverbank (deliberately ignoring long standing, widespread use and
acceptance) would seem to indicate a riverbank, i.e. the bank of a river,
or in other words, the area along a river, which will occassionally but not
always be flooded.

I am at this point not proposing to remap all of these (unless there would
be compelling agreement by many mappers), as this is a longstanding, very
widespread tag (293.000 occurences, 31.700 of them relations) with
supposedly uniform usage, but it should be noted that there are issues with
it on a logical level.

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