Re: [OSM-talk] Changing Bing to bing

2017-03-27 Thread moltonel 3x Combo
On 6 March 2017 5:41:01 PM GMT+01:00, Andy Townsend  wrote:
>On 06/03/2017 07:32, Werner Poppele wrote:
>
>  I'd also suggest that
>whatever it is in JOSM that's recommending this be changed so as not
>to.  A couple of times in the past I've suggested that JOSM's rules be
>relaxed in this way and I've always found the JOSM developers to be
>extremely helpful with this sort of issue.

Done: https://josm.openstreetmap.de/ticket/14554

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


Re: [OSM-talk] OpenStreetMap merchandise

2017-01-31 Thread moltonel 3x Combo
On 30/01/2017, Paul Johnson  wrote:
> Do we have any cycling shirts or t-shirts available for sale?  Wouldn't
> mind wearing one while I'm doing surveys out on my bike.

And I'm looking for an OSM beany hat to hide my balding head on 360
survey photos :p Plenty of "custom embroidered/printed hat" companies
online, but they only print the front of the hat, not the top.

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


Re: [OSM-talk] Beware Pokemon users

2016-12-29 Thread moltonel 3x Combo
For what it's worth, I tested the hypothesis that Go uses OSM by
walking http://www.openstreetmap.org/way/142843552. It's a
highway=footway inside a leisure=park, which I added in OSM years ago
and still isn't in Google, Bing, ESRI, or HERE (they do have the rest
of the town mapped). This town is generally pretty boring to play Go:
no gym, 3 stops very far apart, and rather few spawns. I've been
playing Go regularly for a few months, here and in a much more
Go-friendly town.

While this is only an anecdotal result, there are clearly a lot more
spawns on this walk than in the surrounding area (I regularly get
10-15 spawns on this 700m footway, but only 1-2 covering the same
distance along the primary to get there).

IMHO, the biggest news here is that (a subsidiary of) Google is using
OSM data in a high-profile product. If this is true, this is a very
big "switch2osm" story and it'd be great PR for OSM. I encourage other
OSMers to test suitable areas. If the OSM community (which is IMHO
better suited at asserting this than the Go community) can gain enough
confidence that Go is indeed using OSM data, a friendly and public
request from the OSMF to get OSM credited in Go would be in order.


Concerning the fear that Go players will deteriorate the OSM data to
suit their Go needs, I'm not too worried. Being aware of potential bad
edits is good, but we've dealt with problematic user groups before
(bitcoin shops for example).

Having more OSM contributors is always good, but contributors coming
from the Go community would be particularly so, because it is has
demographic that differ from the OSM average (most notably by being
63% women), and OSM sorely needs more contributor diversity.

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


Re: [OSM-talk] Viewing pre-redaction OSM tiles?

2016-07-15 Thread moltonel 3x Combo
On 15/07/2016, Rory McCann  wrote:
> On 14/07/16 20:49, Michał Brzozowski wrote:
>> I would swear I saw a page doing exactly that (with a comparison slider).
>> The reason is I suspect that some website uses old cc-by-sa OSM data
>> (due to its nature, with their own updates) without attribution nor
>> with modified map data released.

If you dig through the history of
https://wiki.openstreetmap.org/wiki/Remapping you'll find lots of urls
that showed what impact the data redaction for the license change was
going to have. But probably none of those are still functional.

> I'm not sure, but could you download & use the files from here:
> http://planet.openstreetmap.org/cc-by-sa/ ? Import with osm2pgsql and
> display it yourself with openstreetmap-carto ?

I think that's the best bet at this stage. There a a few websites that
render OSM at differents snapshots in time, but I don't know of any
that have snapshots pre/post odbl.

Contributors have put a lot of effort into making the diff as small as
possible, and even in areas where the loss was significant (parts of
Australia for example), OSM recovered amazingly quickly afterwards.

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


Re: [OSM-talk] Bicycle GPS traces - more opendata

2016-04-27 Thread moltonel 3x Combo
On 25/04/2016, John Whelan  wrote:
> could the cycling fraternity come up with a process to
> store this type of data as open data?

Have you tried using OSM's existing trove of traces ? There's no
metadata to say wether it was a bicylcle ride or something else, but
most traces have timestamps that enable measuring the speed, so if you
filter out traces that go faster than ~35km/h or consistently slower
than ~10km/h, you should have bicycle traces.

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


Re: [OSM-talk] [BOT] [RFC]: water surfaces

2016-03-23 Thread moltonel 3x Combo
On 23/03/2016, Frank Villaro-Dixon  wrote:
> Maybe it's an higher priority, but that doesn't interest me. If someone
> wants to, good for them.

Fair enough, we all have different priorities.

> Now, the lower priority 'redundant tag deleting'
> is still needed, and if it can be done automatically (nobody still hasn't
> given me a fuckup example), then why not ? It's still usefull if you want
> to extract all the lakes of the world, for example.

How do redundant tags prevent you from extracting all the lakes of the
world ? It should be harmless, you'll just have some objects that will
be selected by two different criterias. For better or worse, any OSM
consumer has to deal with some level of redundant data.

As for problems with your algorythm, people in this list _have_
pointed out potential problems, such as missing non-duplicated tags
that are on the way rather than on the relation (To properly fix that
you need a human eye. Fix the automatically-detectable part of the
problem only and you've just succeeded in making the other problems
harder to detect). There's no need to point at actual osm objects with
those issues that your script changed when the failure case are so
easy to come up with.

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


Re: [OSM-talk] [BOT] [RFC]: water surfaces

2016-03-23 Thread moltonel 3x Combo
On 22/03/2016, Pierre Béland  wrote:
> This is a good proposition to look at unclosed polygons and see if a
> potential incorrect keys to fix.
>
> I agree with others that using a Bot is not a safe way to handle these
> problems. Could a script to extract such unclosed polygons be proposed?
> This way, each local community could take care to fix data for their area,
> importing and examining the data in the JOSM Editor. The Todo plugin could
> be used to go through the items to correct.

I was going to point you towards
http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script but
for some reason it doesn't support OSMI's multipolygon checks. Might
be worth pinging the qat devs.

Possible alternatives:
* Load OSMI's multipolygon checks as an imagery layer. If only it
didn't flag type=boundary as an error. As it is it's a bit noisy :/
* Use the OSMI website directly
(http://tools.geofabrik.de/osmi/?view=multipolygon). You can tweak the
error types to display, and load object via remote command.
* Use the qat plugin but with other sources than OSMI. For
multipolygon errors, it's IMHO not as good.

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


Re: [OSM-talk] [BOT] [RFC]: water surfaces

2016-03-23 Thread moltonel 3x Combo
On 22/03/2016, Frank Villaro-Dixon  wrote:
> On 16-03-22 10:23:51, Nicolás Alvarez, wrote 1.2K characters saying:
>>
>>> El 22 mar 2016, a las 10:10, Frank Villaro-Dixon 
>>> escribió:
>>>
>>> # First goal:
>>> First goal is quite simple. The idea is to work only on relations which
>>> have a natural=water .  Then, it will:
>>>* Delete natural=water from all the ways if they are NOT closed or
>>> ring 0.
>>
>>What if there is a way legitimately with natural=water that isn't closed
>> because of an error? The correct fix is to close it, not to remove the
>> tag. This cannot be done automatically.
>>
> It doesn't matter because this way will also be referenced by a relation
> which has the natural=water tag. Thus, it can be removed from the way.

If the way being closed or not doesn't matter, then it shouldn't be
part of your criterias ? I see this as a red flag indicating you
didn't think long enough about the problem, and that doesn't bode well
for an automated world-wide edit.

You're conflating two different problems:

1) Some multipolygon relations have improper geometry, such as non-closed rings.
2) Some tags are "needlessly" repeated between the relation and its members.

Neither of those problems are specific to water features.

The first problem has many QA tools to point it out, for example
OSMI[1]. Maybe some of them can be fixed automatically, but I'd much
rather go through them manually[2] because some cases are strange, and
often when one MP is broken there's lots of other bugs in the same
area by the same user that deserve a fix.

The second problem actually has the community a bit divided (last I
heard of it), as some people *want* to have the actual ways tagged
(usually for ease of consumption, but also for historical reasons). I
usually delete the superfluous tag when I happen to be editing the
object, but I wouldn't dare do this automatically on a global scale.
And as long as those duplicate tags aren't contradicting each other,
they are harmless.

[1]:http://tools.geofabrik.de/osmi/?view=multipolygon
[2]:http://wiki.openstreetmap.org/wiki/Quality_Assurance_Tools_script

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


Re: [OSM-talk] OsmAnd financially rewarding mappers

2016-03-04 Thread moltonel 3x Combo
On 03/03/2016, Richard  wrote:
>> Even without talking about nefarious schemes, even well-meaning users
>> will tend to change their mapping behavior because of this. In this
>> case it's about uploading more often, potentially making changes
>> harder to follow.
>
> imho it would be good if people would upload more often. Easier to revert
> if it is wrong, more likely the changeset will fit into a reasonable
> bounding box.

There's a happy middle. Some people make too many tiny changesets,
others make too few huge changesets. And nobody make the right amount
of correctly-sized changesets, because that's subjecctive :p

Analysing (perhaps even reverting) a swarm of small changesets is as
much a PITA as huge changesets. Avoid editing very distant points in
the same changeset. Avoid mixing very different tasks (say pure
armchair stuff and survey results) in the same changeset. Avoid doing
5 changesets in an hour for the same location/road/object. Rule of
thumb: if writing a reasonably-precise changeset comment is
complicated or if you used the same comment 20 times today, you should
review the size of your changesets.

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


Re: [OSM-talk] OsmAnd financially rewarding mappers

2016-03-03 Thread moltonel 3x Combo
On 03/03/2016, Marc Gemis  wrote:
> My point is that it might attract people that just upload data without
> any benefit to OSM (wrong data or data that is added in many
> changetsets (because that determines the ranking) instead of 1, as you
> would normally do..
> You can even write a script that creates a point in one changeset and
> deletes it in another. Over and over again.

Even without talking about nefarious schemes, even well-meaning users
will tend to change their mapping behavior because of this. In this
case it's about uploading more often, potentially making changes
harder to follow. Choose a differnet metric, and it'll have a
different problem. The HR industry has tried to find metrics of worker
productivity for decades, but most do not work.

Plenty of OSM projects have done various levels of edit gamification,
and this is fine as long as (counterintuitively) it doesn't push too
much contributors to edit. And when your start bringing money (even a
tiny amount) into the picture, behaviours can change drastically.


But encouraging contributions to OSM is a great idea, and OsmAnd is in
a nice position to do that. Some examples that probably wouldn't hurt:
* Give access to the paid version of OsmAnd if the user has passed
certain editing thresholds. This is similar to the original idea, but
there is no money directly involved, and most importantly this is a
once-off perk.
* Popup notifications about nearby QA issues, like Vespucci does.
* Look at the heatmap of the user's editing/visiting locations, and
prompt the user to go (re)survey if there is a nearby cold spot.

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


Re: [OSM-talk] Terms of Use Issue? - MapMyRide

2015-09-28 Thread moltonel 3x Combo
On 28/09/2015, Mike Thompson  wrote:
> Ian, Hans,
>
> Thanks.  I will write them an email this evening.

Complying with the OSM copyright just requires attribution, but
complying with the Google TOS is more complicated, because you can't
use Google's API (javascript library) to display non-google maps, and
you can't access Google map tiles using an API that isn't Google's:
https://developers.google.com/maps/terms sections 10.1.a and 10.4.e

Google is strong-arming people into using their api+data and nothing
else. My understanding is that legally the only way to display both
Google and non-Google maps on the same page is to use a different
javascript library for each. But of course in practice, everybody
ignores that and blissfully infringes the Google TOS ;)

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


Re: [OSM-talk] recent changes in rendering the map make it worse

2015-09-23 Thread moltonel 3x Combo
On 23/09/2015, henk van der laan  wrote:
> Now I'm really getting confused. osm-carto is the current version and
> gsoc the new one, right?

There's been a tremendous amount of discussion, feedback, a tweaks
about this change:
* https://github.com/gravitystorm/openstreetmap-carto/pull/1736
* http://www.openstreetmap.org/user/Mateusz Konieczny/diary
* various calls for participation on this mailing list.

OSM, and osm-carto in particular are developed in the open. If
anything, they are often flooded by feedback. Please use open source
to your advantage and check the process, the challenges and the
compromises before passing judgement, and contribute using those
channels if you can.

Osm-carto is full of compromises trying to reach a balance between all
the requirements, it is no easy task. For example, the tertiary roads
styling you bemoan has been heavily debated before reaching the
current conclusion; a tough requirements was keeping a high enough
contrast for non-ideal viewing conditions.

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-15 Thread moltonel 3x Combo
On 15/09/2015, Martin Koppenhoefer  wrote:
> thing is, a dismantled railway has no end_date, it only has a start_date and
> will continue to be a dismantled railway, till the end of time

Yes.

On 15/09/2015, Martin Koppenhoefer  wrote:
> railway=dismantled on the other hand is not a past feature, it is a
> dismantled railway now, in the present. In the past it was a railway=rail
> etc.

I don't understand how a feature can be both "dismantled till the end
of time" and "in the present". The only state that you can keep
forever is the state of not being. To me, "dismantled" as used in OSM
rails is a much stronger definition than "dismantled legos", it is a
synonym for "fully gone". Saying that something is "fully gone in the
present" is a roundabout way of saying that it is in the past.

The start_date of the railway=dismantled is the end_date of the
railway=abandoned/rail. So why not tag the railway=rail/abandoned with
the date of its demise (not with a trolltag like end_date, but with
something that doesn't trip up presentfans) instead of
railway=dismantled ?

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-14 Thread moltonel 3x Combo
On 14/09/2015, EthnicFood IsGreat  wrote:
> I guess we're asking that an exception to the "verifiable features only" rule
> be made for these features.

IMHO the exception that you are asking for is not to the "verifyable
only" rule but to the "presently existing" rule. All the
abandoned/dismantled railroads I've seen in OSM were verifyably
"previously existing" but also (where the conflict arrises as far as
I'm concerned) verifyably "no longer present".

This is not a rejection of your plea, just trying to make sure of what
we are talking about.

> Simply confining abandoned railroad
> features to OHM is not a good solution, because without being able to
> view them in the context of existing features, they lose a lot of
> their value.

Agreed, OHM is currently not very usable.



I've suggested that early on, and again in my latest reply to Russ : I
think that maping the past in OSM would be acceptable, if done
properly. Some kind of "OHM done right". Doing things really right
might require a modification of the data model, a cross-db
synbchronisation tool, or some other cool technology... But that's
just too far off, too hypothetical. The next best thing is a tagging
system for the past.

If it wasn't clear already, railway=dismantled, end_date, or any
system that mixes past and present in the same namespace is IMHO not
acceptable. Consumers, editors and tools should be able to filter out
historical data with a simple rule. I've suggested using "past:" as a
key prefix, with an optional " @ date - range" as a value suffix.
Didn't see any reply, what do people think ?

As for opening the floodgates of historical mapping, I do not like it
from a very personal POV, but I can recognise that there is a need,
that OSM might be the best tool to fill that need, and that it might
ultimately strengthen the poject. I just hope (and believe and work to
make it true) that it won't be too much of a nuisance to my usecase.
And if we do open up to maping the past, I don't think that it should
be reserved to railroads.

I've argued against maping no-longer existing railroads in way too
many emails at this stage, but I suggested this escape route early on.
Nobody picked it up but I think that's the only thing that currently
stands a chance of reaching consensus. EthnicFoodIsGreat, can you see
the working compromise that Russ cannot ?

That's it for me, bye bye railroad thread, I hope. Of course I'm only
one contributor, not a highly prolific or influential one, not an
authority, just a voice. Others have been less noisy but more dogmatic
than me on the subject. The community as a whole must decide wether
"we map the present" is still a hard OSM rule.

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


Re: [OSM-talk] Abandoned Rails

2015-09-09 Thread moltonel 3x Combo
On 09/09/2015, Martin Koppenhoefer  wrote:
>> Am 09.09.2015 um 13:14 schrieb moltonel 3x Combo :
>>
>> Martin, have a look at http://osm.org/go/Zc9j8qfSV-?m (near Russ's
>> most recent example) and tell me how this section "somehow has lasted
>> or has had a strong impact that is still observable today".
>
> how could I tell without going there?

I thought I had preemptively answered that :

On 09/09/2015, moltonel 3x Combo  wrote:
> When stuff have been contructed over the former railroad like this,
> there's no need for a local survey to see that nothing is left. IMHO,
> at most a section of Albert Street could have railway=abandoned as an
> additional tag. I have my doubts about the sections under the forest
> too, but that requires a survey to assert.

The line is going through multiple buildings and a wide low wall.
That's as unambiguous as it gets. The lack of any other sign on the
grass and highway areas are an additional good hint. If you're mapping
a railroad here, you're mapping the past.

Or are you saying that the imagery might be too old, the railway could
have been restored since ? The imagery was taken around the same time
as the first changeset, and the changeset sources either say nothing,
or bing, or osm wiki (!).

Talking about past features, tagging gauge=* on a railway=abandoned
way (which by definition does not have any tracks left) should be an
impossible combination. Tagging electrified=* is also a funny idea.

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


Re: [OSM-talk] Abandoned Rails

2015-09-09 Thread moltonel 3x Combo
TL;DR: argument repeat, sorry.

On 09/09/2015, Martin Koppenhoefer  wrote:
>> OSM is map of the current state of the world - not map
>> of the world how it was yesterday, 10 years ago or five thousands ago.
>
> Nobody is advocating to map the past, what is discussed is mapping those
> elements of the past which somehow have lasted or have had a strong impact
> that is still observable today.

Martin, have a look at http://osm.org/go/Zc9j8qfSV-?m (near Russ's
most recent example) and tell me how this section "somehow has lasted
or has had a strong impact that is still observable today". Whenever I
looked at some examples posted by Russ, these kind of sections weren't
far.

When stuff have been contructed over the former railroad like this,
there's no need for a local survey to see that nothing is left. IMHO,
at most a section of Albert Street could have railway=abandoned as an
additional tag. I have my doubts about the sections under the forest
too, but that requires a survey to assert.

So there is at least one contributor who "is advocating to map the
past". I have a feeling Russ is an exception in this respect (Lester's
view are close but more nuanced), but he is so passionate that this
thread keeps resurecting.

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


Re: [OSM-talk] old_name

2015-09-08 Thread moltonel 3x Combo
On 08/09/2015, Martin Koppenhoefer  wrote:
>> Am 08.09.2015 um 17:58 schrieb moltonel 3x Combo :
>>
>> It would
>> be a silly thing to do, as these names definitely are not a current
>> property of Dublin.
>
> I would bet most of them can still be found in today's city, e.g. in pub
> names or other business names.

Probably. Didn't find one in OSM data, but the same exercise with
"Lutèce" yields a lot of results in Paris. So what ? The name is a
current property of those businesses, not of the city the businesses
are in.

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


Re: [OSM-talk] old_name

2015-09-08 Thread moltonel 3x Combo
On 08/09/2015, Martin Koppenhoefer  wrote:
>> Am 08.09.2015 um 14:46 schrieb Mateusz Konieczny :
>> But I would not add old_name that is currently completely unused.
>
> there's one area where old names will be used for sure: old documents,
> books, film, signs, ...
>
> There is no such thing like a currently  completely unused old name,
> otherwise it wouldn't be an old name.
> Or maybe I don't understand "currently". Everything I may encounter now?

If you go that route, there's no limit to how far back an old name can
go. That'd mean that we should add, for example, all of [Dublin's old
names][1] to the osm object, since they are well documented. It would
be a silly thing to do, as these names definitely are not a current
property of Dublin.

IMHO the cuting point should be that the name is used by a living
person, with "used" defined as "when he thinks (out of some document
context) about that place, he (at least sometimes) thinks of it using
that name". It sounds really convoluted when you try a formal
definition, but I hope the ide is clear ? If some joking friend offers
to meet me in "Lutèce" I'll know in which city to go, but I certainly
don't expect OSM to know.


[1]:https://en.wikipedia.org/wiki/Dublin#Toponymy

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-08 Thread moltonel 3x Combo
On 08/09/2015, Martin Koppenhoefer  wrote:
>> Am 08.09.2015 um 13:58 schrieb Mateusz Konieczny :
>>
>> Historical data should not be added and if present - removed.
>
> what do you mean with "historical data", where do you draw the line? What
> about the old_name tags, do you advocate to remove them?

IMHO old_name is fine because it can actually describe the present. As
long as a place is still called or remembered by its old_name by some
living people, that name is a currently-existing property of the
place.

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-08 Thread moltonel 3x Combo
On 08/09/2015, Fabian Schmidt  wrote:
> On 09/08/2015 12:16 AM, Dave F. wrote:
>> I fail to understand why railways are singled out as a special case. If
>> roads, buildings or woods get demolished, they get deleted.
>
> please have a look at the tag definition in the wiki: "where the rails
> have been removed but the route is still visible in some way" [1]

Please have a look at previous discussions, the conflict is not about
railway=abandoned as defined in the wiki but about mapping
completely-disappeared railways where no feature (bridge, cuting, etc)
remains, and sometimes incompatible features (houses) have been built
at that location.

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-07 Thread moltonel 3x Combo
On 07/09/2015, Russ Nelson  wrote:
> We need an authoritative statement that says that deleting abandoned
> railroads is vandalism, and that people who do so in spite of being
> warned not to, will be banned from the project.

Please stop the name-calling. Two contributors disagreeing on what
should be mapped doesn't make one of them a vandal because he acts
uppon his opinion, whichever side of the fence he sits on. Vandalism
implies a purposeful deterioration of the map. But everybody who took
part in this railway debate actually wants to improve the map.

> Until I get that, I
> cannot in good conscience encourage any railfan to map railroads,
> because of the threat from vandals to delete their edits.

You're making this an all or nothing decision, but it isn't. I'm
convinced that most railway enthusiasts would be happy to add the
still-existing parts of railways into OSM, and use a different DB for
sections not suitable for the main map and extra info (like Tony Howe
seems to do).

> I could go through the discussion over the last month and identify a
> grand total of five people who reject mapping abandoned railroads.

And I could go back and find even fewer people who embrace mapping
dismantled railways (please note the abandoned/dismantled
distinction), and a lot of people who sit somewhere in-between. I'm
sure we're both biased, and anyway respondants on the mailing list are
not a democratic sample anyway.

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


Re: [OSM-talk] THIS is the kind of enthusiasm some would reject

2015-09-07 Thread moltonel 3x Combo
On 07/09/2015, Nicolás Alvarez  wrote:
> 2015-09-07 13:36 GMT-03:00 Maarten Deen :
>> On 2015-09-07 17:31, Russ Nelson wrote:
>>>
>>> https://www.facebook.com/groups/abandonedrails/permalink/1044885352211646/
>>
>>
>> It's on facebook and I have to log in to see it. I don't have a facebook
>> account, so could someone post here whay it says?
>
> "Added a Google Earth map of New York Central RR this morning. It
> includes construction history of each line based on ICC valuation info
> if you click the line. It includes abandoned routes, so it may be
> helpful in exploring those. I still have to add trackage rights in
> places. You must have the Google Earth program downloaded on your
> computer for it to open."
>
> And a link to a .kmz file for Google Earth.

I don't have Facebook either to check, but AFAIU this person has just
created his own data layer )in kmz format) separate from Google's main
map data (even if hosted on the same platform) ?

If that's it, it's something for which OSM is already well suited for
(uMap being the most directly-comparable tool) and I don't see why
that person would not feel comfortable in OSM (plus the usual benefits
of contributing to OSM rather than GM). And the fact that he's not
entering that data in GM proper IMHO an argument *against*
railway=dismantled in OSM (but a very weak argument to be sure).

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, p...@trigpoint.me.uk  wrote:
> We can map barriers and visible dividing marks, but land ownership has
> massive privacy and data protection issues.

In many countries, the geometry of land parcels is public data. Not
"this bit of land is owned by Phil Trigpoint" nor "this and that
parcel are owned by the same guy" but just how the land is
geographically divided.

I'm not saying that property data should go into OSM (:p), just that
it's probably not the privacy issue you think it is.

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, Lester Caine  wrote:
> On 02/09/15 12:56, moltonel 3x Combo wrote:
>> Sorry, I see residential areas, hedges, postcodes, etc, overall a well
>> maped area with usefull detail, but nothing mapping land property ? I
>> never suggested that this kind of data was out of scope for OSM,
>> please go ahead and map more of it. When I mentioned "land property"
>> I'm talking about legal ownership, parcels, cadastre, etc.
>
> The boundaries mapped are property boundaries as are the field
> boundaries around them.

When I think of mapping properties I expect a multipolygon, hopefully
following many physical objects such as hedges and fences, is that
what you have in mind ?

> Ideally I would like to add the NLPG reference
> to each but currently that is blocked by possible licensing problems. It
> WOULD be nice to complete the 'hidden' data

Assuming the license issue gets resolved, how will you import it,
conflate with existing data, tag ? How will you keep it up to date
when a field or a chunk of garden changes hand between neighbours ?
Who do you expect will make use of the data ?

I'm not saying that this data doesn't belong in OSM as much as I am
saying "I won't touch that kind of data with a 10 foot pole, it's too
hard to import/maintain, it's a huge amount of data (bloat) that will
complicate editing, and anyway it won't be usable for most usecases".
Go ahead and map the fences and anything else that gives a visual clue
as to where the property ends. But the actual legal property data ?
It's not worth it.

> in much the same way the
> postcode is added here so that searches can be done properly. Just
> because a post has not been put in the ground to identify a location,
> the location still exists if properly documented.

Postcodes, like all address components, are always welcome in OSM even
though they are not always phisically visible. Addresses are a major
OSM usecase. A postcode has a much lower granularity than a parcel. It
doesn't have to be exact and authoritative, it only has to lead to the
correct location.

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, Colin Smale  wrote:
> I see two separate issues getting mixed up: firstly, what types of data
> "belong" in OSM as a matter of principle, and secondly what quality
> criteria would apply. Clearly for the second point the data needs to be
> suitably licensed (if it is externally sourced) and it needs to be
> verifiable so "Joe Public" without any form of privileged access can
> verify its correctness. These are clearly principles which have existed
> in OSM for a long time. But a statement that certain whole categories of
> data do not belong in OSM *because* it sometimes might not be easily
> verifiable, is going a bit far.

Saying that land property has no place in OSM is just a conclusion
that comes from the observation that this kind of data generally poses
big chalenges to verifyability and corrrectness, and that its
usefullness in osm is limited because ownership is one thing where you
have no choice to use the official authoritative source.

If there's somewhere in the world where those concerns are not valid,
then go on and map properrty data there. Again, do you know of any
property data in osm ? What's the tagging schema ?

The principle of "what data belongs in OSM" is about the propeties of
that data, not what kind of data it is. But as it happens, a given
kind of data usually has the same properties, so "this kind of data
doesn't belong in OSM" is a usefull simplification.

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, Lester Caine  wrote:
> On 02/09/15 11:30, moltonel 3x Combo wrote:
>> I always understood that land property was out of scope for OSM. Do
>> you know of any osm data which records property ?
>
> So I should remove all the detail on
> http://www.openstreetmap.org/search?query=wr12%207ep#map=17/52.04851/-1.85665
> rather than adding the missing detail to the right?

Sorry, I see residential areas, hedges, postcodes, etc, overall a well
maped area with usefull detail, but nothing mapping land property ? I
never suggested that this kind of data was out of scope for OSM,
please go ahead and map more of it. When I mentioned "land property"
I'm talking about legal ownership, parcels, cadastre, etc.

> And the 'Abandoned Railway' to the left is a protected route which HAS
> encroachments onto it, but which is still potentially re-enstatable once
> the line to Broadway becomes active again. Using the ground for a long
> period does not always allow to take possession of it and rail routes
> are one of those documented exceptions.

Sure. It looks well mapped to me. Again, I don't see how your answer
relates to the subject of mapping land ownership, there's no ownership
mapped on these osm objects.

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, Russ Nelson  wrote:
> Too bad for that guy that he didn't check OpenStreetMap first, because
> there was an abandoned railroad mapped in his back yard.

Lots of former railway land is now privately owned, sometimes even
before the rails get removed. So the fact that there was an abandoned
(dismantled ?) railroad in his backyard didn't, on its own, mean that
he didn't own the place.

In many countries (not sure about the USA), there's also a legal
concept of "if you build on a piece of land and nobody complains for X
years (with X being quite high), then that piece of land defacto
belongs to you". This leads to people sometimes building on land with
a unclear ownership status, chancing it and hoping for the best.

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


Re: [OSM-talk] Abandoned Rails

2015-09-02 Thread moltonel 3x Combo
On 02/09/2015, Colin Smale  wrote:
> Are you suggesting that parcel boundaries have no place in OSM, or that
> only verifiable sources should be used? Suppose there was a suitably
> licensed source of such boundaries, with authoritative provenance. Would
> you be against this being in OSM on principle? Or is it only your
> supposition that such information cannot be sufficiently verifiable
> which gives rise to your concern?
>
> Anyway, fences, signs etc are not reliable indicators of parcel
> boundaries (where there are land registries), unless the boundary is
> legally described with reference to these physical artefacts.

I always understood that land property was out of scope for OSM. Do
you know of any osm data which records property ?

IMHO verifyability is a major issue here. Real-world barriers don't
match the legal ones, borders change regularly (that's a major
difference with admin boundaries), and even the authoritative source
is often murky (I'm now 3-4 months into the process of figuring out
wether I own a piece of land at the back of my garden).

On top of that, whenever you need to know about land ownership, you
are legally obliged to refer to the authoritative source. Looking up
the info in a crowdsourced db, even if it was completely correct,
would most often be a waste of time.

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


Re: [OSM-talk] Proposed mechanical edit: surface=soil to surface=dirt

2015-08-31 Thread moltonel 3x Combo
On 31/08/2015, Christoph Hormann  wrote:
> I would be careful here - 'dirt' is essentially a very vague term which
> probably originates from the concept of 'dirt roads' here.  'Soil' in
> the other hand is fairly precise, see
>
> https://en.wikipedia.org/wiki/Soil
>
> Only parts of the earth surface are actually covered by soil so if a way
> is correctly tagged with surface=soil (and i don't know if that is the
> case for the 400 cases you mention) this is something specific and
> potentially useful and should not be degraded by turning it into
> something as vague as surface=dirt.
>
> In general i think surface=ground is the most sensible tag for tagging
> ways that are just established somewhere without notible construction
> work when you can't be more specific - it implies that the way surface
> is essentially the ground there in its natural state.  surface=dirt
> OTOH can mean anything from the remaining tracks of a car driving
> across a wayless area to a solidly built gravel road.

Agreed.

Between soil, dirt, ground, earth, and mud, dirt is the worst defined
of the lot, and I would hesitate to use it for anything.

If you do want to consolidate tags, "earth" is a much better synonym
of "soil" and you should probably use that instead.

"Ground" is earth+rocks+sometimes_vegetation. "mud" is earth with a
lot of water and clay.

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


Re: [OSM-talk] OpenStreetMap Carto v2.34.0 release

2015-08-30 Thread moltonel 3x Combo
On 30/08/2015, Dave F.  wrote:
> Is man_made=bridge meant to be used on ways that represent disused
> bridges such as railways where all the track has been removed?

Meant to be used on any bridge. It gives the shape of a bridge, as
opposed to the highway(s) that it supports. There's also a type=bridge
relation to help with complicated multi-highway cases. Rendering
bridges even if the corresponding highway isn't rendered (such as
railway=abandoned) is one reason to render man_man=bridge, but
depending on who you ask it may not be the main reason.

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


Re: [OSM-talk] Abandoned Rails

2015-08-29 Thread moltonel 3x Combo
Sorry in advance, this mail just rehases arguments that I made before,
but it seemed polite to reply.


On 29/08/2015, Russ Nelson  wrote:
> moltonel 3x Combo writes:
>  > One can often assert that something was here even when nothing is left
>  > of that thing. And is nothing is left of that thing, it shouldn't be
>  > mapped.
>
> What about point A?  What about point B? The *endpoints* do indeed
> continue to exist, so "nothing is left of that thing" is not true
> about most dismantled railways.

That's precisely it, point A and B continue to exist, they can be
mapped as abandoned/disused. What's between A and B did not continue
to exist, and should not be mapped. We know perfectly where New York's
World Trade Center used to be but there's no tower=dismantled at that
location.

> Should the map look like this (A)?  ___   __ 
>
> Or should it look like this (B)?___---__-
>
> Some people are arguing for A. I argue that B is a better
> representation of what is there (the underscores) because it includes
> the dismantled portions (the dashes).

And unsurprisingly, I argue for A. Because it reflects the current
state of the railroad.

I do understant the appeal of being able to create a relation where
each member follow the previous one without holes. But if reality has
holes, so should the relation.

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


Re: [OSM-talk] Abandoned Rails

2015-08-27 Thread moltonel 3x Combo
On 27/08/2015, Andy Townsend  wrote:
> Back in
> https://lists.openstreetmap.org/pipermail/talk/2015-August/073669.html I
> had a look at what caused the current flurry of discussion.   Part of
> the line in question was deleted by a mapper new to OSM; it was their
> second and last OSM edit.  I find it hard to believe that this new OSM
> mapper "had a thing about deleting abandoned railways". Likely they just
> didn't understand something, were confused, and it somehow got deleted.

Good catch, sorry I forgot about it. I agree that
http://www.openstreetmap.org/way/259134943 should not have been
deleted, and that it certainly was just a mishap that the contributor
didn't even notice. So restore the way, send a "watch out" message to
the newbie, and call it a day (well, do also improve the tagging of
that abandoned railway : some sections are dismantled and some have
been converted to various types of highway, etc).

But I doubt that Russ would have had such a strong reaction if it was
just for that case. I'm sure there were other willfull deletions, and
lacks of communication.

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


Re: [OSM-talk] Abandoned Rails

2015-08-27 Thread moltonel 3x Combo
On 27/08/2015, Paul Johnson  wrote:
>  I believe we're talking about abandoned railroad rights of way that still
> mark the landscape, not something that no longer has a trace.

No :

Russ Nelson nelson at crynwr.com wrote Thu Aug 20 05:12:49 UTC 2015
> Here's a perfect example of how a railway should be mapped:
> https://www.openstreetmap.org/#map=14/42.92237423246795/-75.8534094581493

There is no real-life trace left of
https://www.openstreetmap.org/way/366610457 (amongst others) but it is
currently in OSM.

At we're not least not exclusively about still-visible abandoned; the
OP hasn't given a list of guilty deletions so it's hard to judge how
justified each deletion was.

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


Re: [OSM-talk] Preserving History ...

2015-08-25 Thread moltonel 3x Combo
On 25/08/2015, Blake Girardot  wrote:
> But in general if you want to map from scratch, make a new layer, map,
> merge layers, replace geometry, done, history retained and you mapped
> from scratch.

I wonder if JOSM could do that automatically. Before uploading, JOSM
would look at all objects deleted during this editing session,
fuzzy-match new objects at the same location and tags, and perform the
replace-geometry tag automatically.

> Same thing with roads that need updating, you just remap it and then
> replace geometry or use the improve way tool, either one will preserve
> history.

Another tip for preserving history in JOSM: if you split a way in two,
the start of the way is the one that retains history and the end of
the way (where the arrow is) is new. Reversing the way before spliting
it can help keep the history on the important section.

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


Re: [OSM-talk] Abandoned Rails

2015-08-25 Thread moltonel 3x Combo
On 25/08/2015, Blake Girardot  wrote:
> I am not a railway enthusiast, but I do recognize the important role
> they play in the development and landscape of the US and probably other
> countries.
>
> I really appreciate those who map in-use, disused and abandoned
> railways, thank you for adding important, rich and useful data to the map.
>
> I think part of this conversation should be reprized: Abandoned railways
> are recognizable by people who know what they are looking at, they are
> in essence "there on the ground currently", just because I don't have
> the knowledge to recognize and map them, does not mean they do not exist.

For the record again, lest people think that my views are more extreme
than they are, I agree with the above.

Where I draw the line is against railway=dismantled, which by
definition don't exist anymore. Typical examples are going thru a
housing estate, a demolished (and rubble cleared) bridge, or a field
where the former railway isn't even visible in crop groth differences.
When the state goes from "not obviously there" to "obviously not
there".

> All I understood Russ to be asking was to stop deleting and suggesting
> deletion of abandoned railways without checking with the person or
> people who know what they are doing in regards to mapping them and I
> agree that should stop.

Heavy changes to someone else's work should come with a message to
that someone else, but I'd argue that whoever deleted a railway=*
going thru a housing estate knew what they were doing.

> As mentioned above, I see no harm to mapping an abandoned railway, even
> if it is based on two end points and knowledge of the railway system.

One can often assert that something was here even when nothing is left
of that thing. And is nothing is left of that thing, it shouldn't be
mapped.

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


Re: [OSM-talk] Abandoned Rails

2015-08-25 Thread moltonel 3x Combo
On 24/08/2015, Richard Fairhurst  wrote:
> cycle.travel's rendering is 1300 lines of CartoCSS, 1400 of .mml, 300 lines
> of Lua preprocessing, and 350 lines of Ruby/PostGIS postprocessing.
>
> Of this, the code required to show only operational railways is 100
> characters - a rounding error. It's a detail in a 1400-character line of
> .mml and it was copied directly from OSM-Bright, the base style used by
> switch2osm. In other words, anyone setting up an OSM tileserver from the
> canonical instructions already gets this for free.

Fair enough, it's easy to get a bootstrap (for the record, I was
talking about knowledge, not lines of code). The bootstrap might not
have been used or might not be available for a particular usecase, but
I get your point. Sorry for placing the principle of least surprise
bar too high.

> There are plenty of issues with OSM railway tagging that make decent
> rendering, routing and analysis hard. (railway=station covering both
> mainline stations and preserved heritage attractions is the first that
> springs to mind.) railway=dismantled is not one of them.
>
> As to whether utterly dismantled railways belong in the OSM database, I
> couldn't really care less. In terms of doctrine, they probably don't, though
> let's not overstate the issue: I suspect more bytes have been spilled in
> this thread than it would take to encode a dump of current
> railway=dismantled in .pbf format.

I'm aware of that (and skewing the ratio even further as I write
this), but this is about more than just railways. Sorry for the
fearmongering, but letting one kind of nonexistent objects into OSM
opens the door to more. Countering with "existing crap in the db
doesn't justify adding more crap" hasn't worked well in the past.

To be honest, I too could live with a few railway=dismantled in the
db. The bigger issues are the idea of allowing some data in even when
you agree it shouldn't be there, protecting that data for political
rather than technical reasons, and the precedent this would set.

> But Gregory, Greg and Jason have it
> right. This is not about some precious notion of purity, it's about
> community.
>
> Outside the two fundamentals of "openly licensed" and "crowdsourced", OSM is
> characterised by its pragmatism. We do what works. What works is a community
> of people who feel respected and empowered.

By preventing contributors to fix errors in the db (as miscommunicated
as they were, I'm sure  the deletions that started this thread were
meant as fixes) just because they come from some kind of Most Valued
Contributor, you're disempowering the community as a whole to empower
a fraction of it. I'm not going to pull statistics out of my magick
hat, but to me this looks like a net long-term loss.

> And bearing in mind that we're
> talking about the US here, we need all the community we can get.
>
> Read Minh Nguyen's excellent new diary post
> (http://www.openstreetmap.org/user/Minh%20Nguyen/diary/35646). Even in the
> super-affluent, super-educated Bay Area, OSM is barely at the stage that
> Europe reached five or more years ago. It is "an endless parade of outdated
> street configurations, missing landmarks, test edits".
>
> But, he notes, there is "plenty of rail and bike infrastructure".
>
> This is what characterised OSM adoption here in Britain. The enthusiasts are
> the first to "get it": the railfans, the cyclists. Widespread take-up comes
> later, once the enthusiasts have built something good.
>
> The last thing we want to do in the US is drive away the few enthusiasts we
> currently have.

I know :( I'd hate to see someone leave because of that discussion.

I'd love to see improvements in the OSM tooling and/or schemas so that
we can properly map historical features. So that dismantled railways
(amongst other no-longer-existing features) can be mapped without
hurting present-day mapping, which was initially OSM's only usecase.
So that entering that kind of data isn't a deletion-worthy error
anymore, but a normal usecase.

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


Re: [OSM-talk] Abandoned Rails

2015-08-24 Thread moltonel 3x Combo
On 24/08/2015, Balaco Baco  wrote:
> buildings are usually
> replaced much faster than maps are expected to last, and the work of
> updating it twice, once for the "empty space, dem. building" and the
> future "new building outline" is better done only one time.

It's nice to avoid unecessary version churn, but if a mapper keeps up
with the real-world changes there's nothing wrong with updating OSM
too. If you search the archives you'll find plenty of discussions on
"mapping temporary features" and how ephemeral a feature needs to be
before it loses its mapworthyness. For example a road closed during a
weekend is a clear no-map, but construction work is usually considered
mappable if it'll last a few months and there is a local mapper to
keep track of the updates.

"how long a map is expected to last" is a tricky question especially
for OSM. Paper maps are often updated yearly but kept for decades in
people's homes. Google Map has TOS that mostly forbid cacheing data
yourself for later. Data on osm.org is updated minutely, but the osm
data on a satnav may never get an update at all.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-23 Thread moltonel 3x Combo
On 23/08/2015, mick  wrote:
> On Sun, 23 Aug 2015 00:09:43 +0100
> moltonel 3x Combo  wrote:
>> Do people actually do this ? It sounds like a strawman argument to me.
>> I do a fair bit of walking and cycling, and when planing a trip I look
>> at the global topographic data but it never occured to me to look for
>> railroads. Why use the local railroad hint when you've got the global
>> DEM data ?
>
> How fine is the granularity of the DEM data?

Between 30 and 90m depending on location, when you look at the most
common publicly-available data. Most of the world is at 30m now, and
most of the really bad artefacts have been fixed.

30m is plenty of granularity when you're planning a walk or a cycle.
It can miss a cutting or an embankment, but those areas are normaly
flat enough to begin with that you wouldn't have been put off by the
DEM data alone. I'm sure there are extreme cases where this isn't
true, but you still want to mainly look at DEM most of the time.

Tags that I actually look at when choosing an osm path/footway/track
is surface, tracktype, and sac_scale.

http://www2.jpl.nasa.gov/srtm/
https://en.wikipedia.org/wiki/Shuttle_Radar_Topography_Mission
https://en.wikipedia.org/wiki/Advanced_Spaceborne_Thermal_Emission_and_Reflection_Radiometer

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


Re: [OSM-talk] Abandoned Rails

2015-08-23 Thread moltonel 3x Combo
On 23/08/2015, Mike N  wrote:
> On 8/23/2015 2:03 PM, Dave F. wrote:
>> Are you saying if a building gets demolished & replaced with a new one,
>> you wouldn't remove the original outline from OSM?
>
> In my case, I've begun to do just that, adding a note to alert the 'Bing
> tracers' that something has changed.  But I would eventually remove it
> after Bing is updated.   Only historic or notable buildings would go
> into OHM.

That's actually something I do as well:
http://www.openstreetmap.org/node/2554879309 but I only add a note=*
node, I certainly don't keep any building=* closed way.

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


Re: [OSM-talk] Abandoned Rails

2015-08-23 Thread moltonel 3x Combo
On 23/08/2015, Balaco Baco  wrote:
> I don't think so. Wrong data happens to Bing Maps, to Google Maps and
> probably to any other map we can obtain, electronically or in a paper.
> Maps have dates attached to them - or should have, most of the time. The
> fact is that: if I browse around my city, looking for streets and
> brindges created in the last fews years, I will see mistakes (as I did
> before).

Yes, all maps have errors, wether it is outdated data, data that was
never right, or missing data.

> But it's better to have there what existed, as it was before,
> than have just an emptyness in the area.

How so ? Say I'm walking along an old railroad which OSM led me to
believe continued for 10km, but is impassable at various points
including a wheat field and a housing estate. Or I'm heading to the
convenience store only to find it has closed years ago. Outdated data
is wrong data, it is misleading and lowers the overall quality of the
map.

> Until someone fix it
> (hopefully) or at least mark it as old, potentially wrong (without
> deleting until an update is made!).

That's just the normal mapping workflow, nobody is arguing against
this. Nobody is proposing to "delete first, improve later". We make
the best map we can, within the bounds of our knowledge and time
constraints.

> In the context being discussed here, recent changes should also cause
> data deletion, but that's wrong, in my opinion. Data may be *replaced*
> with newer data, with everything that's needed.

Same thing here, we improve the map as much as we can. But maybe you
don't have enough time right now to map everything, or meadows are so
far off in your todo list that you never bother with them. But leaving
known-outdated data in place just because you can't yet make a fully
detailed mapping of the area doen't make sense either.

> If people are doing something that is fiercely against the community
> idea of OpenStreetMap, that it could be deleted. But that really seem
> far from the truth.

There are very few rules in OSM, but one of them is that we map on the
ground and that we don't map historical features/events
http://wiki.openstreetmap.org/wiki/Good_practice#Map_what.27s_on_the_ground
http://wiki.openstreetmap.org/wiki/Good_practice#Don.27t_map_historic_events_and_historic_features

Ways like https://www.openstreetmap.org/way/366610457 (and presumably
many other railway=dismantled) fail these checks.

> So that should be preserved, and its deletion, if
> decided to be made, should give a reasonable opportunity for the data
> contributors to backup that data - so their work is not lost, but may be
> used somewhere else.

Yes, giving a heads-up to a mapper when you edit a lot of his work is
good etiquette. As for backup, the data is versioned in the db, you
can always get the old data back.

> Further, I'm not one of the users that would be confused with that. I
> would find it unsual to see in a map. But being tagged and noted
> somehow, should not be a problem at all. And to say the users who would
> be confused with it are the "majority of them", is an vague argument you
> do just to give some apparent strength to your idea. And I repeat: I
> would not be confused with it, I don't think the majority of users would
> be.

Since OSM has always had a policy of containing only current data, it
stands to reason that the majority of users only expect to find
current data in OSM (or rather that anything that isn't current
anymore needs to be fixed, and that it was current when it was added
to osm).

Wether you get confused when stumbling uppon data which violates that
rule depends on what you're doing with the data. Remember that
interpreting osm data is actually a lot of work. Very few people have
the manpower to verify what railroad=dismantled actually mean to
decide wheter they want to use or filter out that data. Most of them
will just match railway=*, plus perhaps some special cases for
railway=rail and railway=subway. Now they're looking at historical
data without even knowing it. They are confused.

> P. S.: this mailing list does not add a "Reply-to" header to mail
> messages, as I'm used to. So I initially sent the answer to just one
> person. This should be changed - may it not confuse the majority of
> users!?

It normally does, not sure what happened here.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-22 Thread moltonel 3x Combo
On 22/08/2015, John Eldredge  wrote:
> So, if you are looking for a route without steep grades, a former
> railway is a natural choice.

Do people actually do this ? It sounds like a strawman argument to me.
I do a fair bit of walking and cycling, and when planing a trip I look
at the global topographic data but it never occured to me to look for
railroads. Why use the local railroad hint when you've got the global
DEM data ?

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-21 Thread moltonel 3x Combo
On 21/08/2015, Martin Koppenhoefer  wrote:
>> Am 20.08.2015 um 14:59 schrieb Pieren :
>>
>> where is the railway here ? were are the rails ?
>
> there aren't any rails, but there is a railbed, this cutting wouldn't make
> sense for a cycleway, would it? (inappropriate effort)

IMHO (and I've been arguing against mapping railway=abandoned in many
cases), I think that in this case tagging railway=abandoned (along
with highway=cycleway and cutting=yes) is acceptable, meaning that I
don't think the tag should be deleted, but I wouldn't add it myself.

For: even an on the ground unmoving observer would easily figure out
that this was a railway.

Against: it is neither a railway nor abandoned, it is a cycleway, the
characteristics of which can be fully described without refering to
its railway origin. There has to be a point in a way's physical
evolution when we can stop tagging railway=abandoned, where do you
draw the line ? The "it was a railway" fact can if desired be kept in
a relation with start/end tags (a rare case where these can work).

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-20 Thread moltonel 3x Combo
On 19/08/2015, Lester Caine  wrote:
> 98% of the history that we are looking to manage properly is currently
> existing in OSM. All that is needed is to add start dates to the bulk of
> the existing data.

What do you do when a road gets upgraded, widened, straightened,
renamed, or some combination thereof at various points in time ?
start/end_date tags are way too crude, they can't capture any
evolution (as opposed to construction/demolition) of the real world,
making their use very limited.

> The SMALL amount of material that
> is a result of new development work invariably maps into currently
> existing objects.

That's just not true, by definition new developments are new objects
(and often a lot of old objects relegated to the past). And the amount
of evolution in the real world is by no mean small.

> Insisting that this data is only available for
> rendering purposes in a second database is just wrong, and even worse,
> the 98% of the supporting data exists in OSM so why maintain a second
> copy of it.

I would actually love to be able to map the past in OSM. But if all
you have to offer me is start/end tags and some renderer/editor
workarounds, I'll say no thanks.

To me OHM's value is not so much in its data as in being a sandbox to
experiment with tooling to map the past, which can eventually be
merged back into OSM. I suppose the OSM data model itself has to be
modified to support a nonlinear history, but this is tricky.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-20 Thread moltonel 3x Combo
On 20/08/2015, Russ Nelson  wrote:
> moltonel writes:
> When they show up, we can have a discussion. In the meantime, I'm
> here, and many other mappers map abandoned and dismantled railways,
> and we would like to NOT HAVE YOU FRICK WITH OUR STUFF.

Please don't shout and curse, it just kills the debate. Your defense
of railway=* mapped thru buildings of a housing estate is something
that I (and AFAICT most of the community) cannot agree with, so that
topic has reached a dead-end and I'll stop discussing it.

Hopefully someday we'll get a proper way to map in the 4th dimention
in OSM (hint: OHM is not good enough yet). In the meantime, if I
happen to be mapping somewhere and see an abandoned/dismantled railway
going thru houses like in your "perfect example of how a railway
should be mapped", I'll delete it.



Regards.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-20 Thread moltonel 3x Combo
On 20/08/2015, Russ Nelson  wrote:
> moltonel 3x Combo writes:
>  > But it's equally annoying and tiring to repeatedly encounter the
>  > ludicrous kind of railway=abandoned,
>
> Then tag it as railway=dismantled. You won't find me defending
> incorrect tagging of anything.

If 'dismantled' is meant to be used for cases like going thru
buildings in a housing estate then no, this data just doesn't belong
in OSM.

> moltonel 3x Combo writes:
>  > To me the distinguishing criteria between disused and abandoned is
>  > wether the rails are still present or not.
>
> Indeed. disused means the rails are still there. Abandoned means that
> the rails are gone. Dismantled (or some people use razed) is when a
> section of the railbad cannot be seen. Railways that were never there,
> placed by mistake, should be deleted.

The wiki only describes abandoned and disused. Some people have
mentioned cases where the rails are still there but trees are growing
in the middle so it really should be 'abandoned' and/or there should
be a value between 'abandoned' and 'disused'. From what you said
earlyer, maybe 'dismantled' is the new 'abandoned' and 'abandoned'
sits somewhere between 'dismantled' and 'disused' ? Maybe you could
give the wiki some TLC.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-20 Thread moltonel 3x Combo
On 20/08/2015, Russ Nelson  wrote:
> moltonel 3x Combo writes:
>  > The demolished: prefix only makes sense when there is something left
>  > of the former feature, typically rubble (useful for example to alert
>  > boattripers of the hazard). When there is nothing left in reality,
>  > there should be nothing left in OSM.
>
> Question: should we tag the aqueduct underneath Sunrise Highway
> between Aqueduct Raceway and Freeport, NY?

I'm not at all familliar with that area, please provide some links.

>  > Deleting an object is hardly different from editing it as far as
>  > osm history is concerned.
>
> Except that deletion excises it from the database that you see when
> make an API call.

So does editing. When you change the geometry or tags of an object,
the old versions are not downloaded/displayed by you editor unless you
take special action. I know that outside of Potlach1 that "special
action" is a bit more complicated, but that is just an API issue that
will hopefully get fixed someday.

> In the case of dismantled railways, that is not
> accurate. There *is* a dismantled railway there, and you can tell
> because the railway was at point A and at point B, and you can still
> see it there, and so you should expect to see it in-between.

The argument (which is not making any progress so this might be my
last comment on it) is between *is* and *was*, and where to draw the
line. If there *is* an abandoned railway it can be mapped. If there
*was* a railway it cannot be mapped. "abandoned" isn't a synonym of
"was".

See for example http://osm.org/go/esz3FWUuB- (toggle satellite
imagery). There *is* an abandoned railway south of the river, there
*was* a railway north of it. The fact that you can infer that the
railway was indeed there because it's clearly visible again at
http://osm.org/go/esz18LcmF- (and visible all the way in the GSGS 3906
imagery) doesn't matter.

We've discussed a few criterias to distinguish between *is* and *was*
on this thread, but you've dismissed even the most basic "A building
has not been constructed at that location" one.

On the subject of is/was criterias, I'd like to weight against the
less basic "railway grade slope" one. Firstly because railways usually
followed existing flat grades instead of following them, secondly
because in other cases the cuttings and embankments should be mapped
for themselves rather than implied by a railway=abandoned. There might
be some cases where that argument still makes sense (montainside
railways come to mind), but it needs to be evaluated case by case
IMHO.

> I understand that most people don't give a crap about map feature X,
> Y, and Z. I get it, really I do. I look at things in OSM myself and
> wonder "why the hell did you map that?? Who cares??" And when it comes
> to railways, there's a lot of people who don't give a crap. Fine. Go
> ahead. Don't care. But I do. So don't delete the things that I (and
> other railfans) have added.

For the last time, this isn't about esoteric mapping topics (abandoned
railways is actually quite popular in OSM), but about reconising then
something just doesn't exist anymore and (in another part of this
thread) about wether mapping the past is acceptable in OSM at all.

> From whence comes this impulse to destroy other people's work? Cuz it
> seems pretty anti-community, anti-mapper, and anti-OSM.

Quality assurance. We all want the map to be as correct as possible,
and that sometimes require deleting data. The only anti-* case is when
the decision to modify/delete is controversial but not discussed.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-18 Thread moltonel 3x Combo
On 18/08/2015, Lester Caine  wrote:
> On 18/08/15 13:04, moltonel 3x Combo wrote:
>> Remember that deleted osm objects *are* kept in the osm history and
>> can even be undeleted (finding the old object id is currently a pain,
>> but I certainly hope that this'll become easyer someday). Deleting an
>> object is hardly different from editing it as far as osm history is
>> concerned. Russ singled out actual deletion as something specific, but
>> disagreement on if/how to map something happen all the time in OSM
>> (thankfully rarely with that level of drama), not just when deletion
>> is involved.
>
> On OHM these objects need to co-exist ... if OSM is going to create yet
> another version of the historic object if recovering from the change log
> we are going to get into even more of a mess. This is why 'delete' *IS*
> the wrong concept for objects that CAN be authenticated historically.
> The whole problem here is that objects like railways are going to evolve
> over time, and while some elements may no longer be visible, maintaining
> the sequence IS important even if some people think that there is no
> place for that information is OSM.

Are you implying that OSM should do what it can to be easily merged in
OHM ? Currently OHM is a completely different db, with its own object
ids. There's no link between OSM ids and OHM ids to keep track of. The
OSM data model would make that tracking very difficult (way
splits/joins, etc) but maybe it could work. More pragmatically, OHM
could have OSM data as an ever-evolving present day data layer, with
its own ids.

Or are you saying that OSM should take on OHM techniques (and thereby
become OHM) ? With OSM's data model, if you want to keep track of both
today's world and yesterday's, you're going to need to track two sets
of objects, not just two versions of the same object (because of
splits and such). Tracking this using tags is horribly messy at scale.
A better solution would require some data model changes and editor
support, but OHM currently has neither. So we currently say "no
thanks" to historical data in OSM.

In OSM's data model, deletion is not different from modification. If
your historical project can't deal with that, you need to get back to
the drawing board.


> I repeat what I have said many times before ... we are documenting that
> very history today, ad while the information is available from the
> change log, it ALSO needs to be directly accessible from the OHM view so
> why not simply maintain that information in a format that the CURRENT
> rendering tools can show and the current editing tolls can improve on.
> The change log is simply the wrong place for this data to exist in ...

Be carefull not to mix up database history and real-world history.
Database history keeps track of the mapping process, as geometry gets
refined, details get added, and blunders get reverted. World history
tracks what the world was like at a specific point in time. OHM has to
keep track of both, but OSM is (at least for now) only concerned about
db history.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-18 Thread moltonel 3x Combo
On 18/08/2015, Russ Nelson  wrote:
> Serge Wroclawski writes:
>  > TIGER wasn't what I was referring to.
>  >
>  > Please don't speak on my behalf.
>
> Very well. Feel free to point to anything anywhere that people are
> afraid to delete. I want to see 1) something that obviously doesn't
> belong there, 2) which isn't TIGER and 3) evidence that someone
> expressed a reluctance to delete it.

https://lists.openstreetmap.org/pipermail/talk/2015-August/073819.html

Didn't have to look far. But really this is a commonplace occurence.
Most of the OSM world isn't TIGER, and doubting one's edits (including
but not limited to deletions) is a healthy quality-assurance reflex.


> Is it unreasonable of me to ask for evidence of a claim that you have
> made? I mean, besides TIGER, which is a perfectly reasonable
> assumption for an ambiguous claim.

If I'm following things right, the claim was :

> in other parts, we have an abundance of bad imports, and a general
> timidness around the removal of data that we can't find the owner of, which
> leaves us with data that *we know is bad*, but where the individual mappers
> do not feel empowered to act on because of this exact attitude of needing
> to contact and work with the importer.
>
> This leaves our project with a problem of lots of data and no one feeling
> empowered to remove it.

I'm sure nobody will disagree that we have a lot of bad data (in
absolute numbers, not in percentage :p), and it's silly to think that
TIGER is the only source of it, or even that all TIGER data is bad.

In that context, arguing that deletions are intrinsincly a bad thing
does harm OSM's QA process. Clearly we should think twice before
deleting something and don't want to reach an extreme of "if in doubt,
delete", but what you've proposed is the opposite extreme and is just
as unhealthy.

For what it's worth, the only place I've felt disempowered in OSM
(appart from the lack of free time) is the very high bar set for
automated edits. Wether that disempowerment has resulted in a net
positive or negative for OSM is left as an exercise to the reader.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-18 Thread moltonel 3x Combo
On 18/08/2015, Warin <61sundow...@gmail.com> wrote:
> On 17/08/2015 10:48 PM, moltonel 3x Combo wrote:
>> On 17/08/2015, Martin Koppenhoefer  wrote:
>>>> Am 17.08.2015 um 02:39 schrieb moltonel 3x Combo :
>>>>
>>>> * A broken bridge with just a few meters left on both riverbanks
>>> I surely wouldn't have removed this one. Isn't this a significant feature
>>> to
>>> many people?
>> In only deleted the middle bit, not the bridge=yes stumps. At least
>> that's what I remember; I couldn't find it again in
>> https://www.openstreetmap.org/changeset/16286467. Maybe it was a
>> different railway line.
>
> Retag the middle bit demolished:bridge=yes would be a better solution?
> Retains all the data. If the bridge were rebuilt then it could simply be
> retagged back.
>
>>
>> On the other hand, there's an instance of a bridge that is the only
>> thing left standing (green undisturbed meadows on both sides), and
>> that bridge is kept in OSM (while the sections in the meadow were
>> not).
>
> Then retag the ways leading to the bridge using the prefix demolished:

The demolished: prefix only makes sense when there is something left
of the former feature, typically rubble (useful for example to alert
boattripers of the hazard). When there is nothing left in reality,
there should be nothing left in OSM.

Even when we expect the feature to be rebuilt someday (not the case
for this bridge), there's no advantage in keeping the OSM object
around just to simplify restoring it: creating a new osm way is just
as easy as retagging an old one.

Saying that we should retag no-longer-existing objects rather than
deleting them is like saying that we should always use strike-through
in a text document rather than using document history, or that we
should always comment lines in a program rather than using source code
management like git.

Remember that deleted osm objects *are* kept in the osm history and
can even be undeleted (finding the old object id is currently a pain,
but I certainly hope that this'll become easyer someday). Deleting an
object is hardly different from editing it as far as osm history is
concerned. Russ singled out actual deletion as something specific, but
disagreement on if/how to map something happen all the time in OSM
(thankfully rarely with that level of drama), not just when deletion
is involved.

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


Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]

2015-08-17 Thread moltonel 3x Combo
On 17/08/2015, Martin Koppenhoefer  wrote:
>> Am 17.08.2015 um 11:20 schrieb Mateusz Konieczny :
>>
>> Probably landuse=forestry and landcover=trees would be a good idea and I
>> would  support such proposal.
>
>
> how do you suggest to put names? On locality nodes? On landuse objects?

Usually on the landuse (or leisure or natural or...) area.

> If you do the latter you will often have to make compromises, because of 
> things
> that are part of the named forest but are different landuses, e.g. a lake,
> or buildings, campings, meadows, settlements, cemeteries etc.

That compromise is made all over OSM : we ignore the small areas
inside a landuse such as lakes, buildings, or corner shops in a
landuse=residential. Where to draw the line between too much detail
and too little is a very subjective decision.

> You would also have to have overlapping landuse forest areas.

When would you need that ?

> I believe it's
> impractical to have it all in one tag: forest objects, the information where
> trees grow and where the landuse is forest. Multipoligon relations also
> impose a limit then how detailed you can get without loosing editability or
> even hitting api limits.

The only detailed MP you really need is for landcover=trees, but
there's no reason to give this a name and therefore no reason to have
a single huge MP. You can split it arbitrarily to make it managable.

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


Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]

2015-08-17 Thread moltonel 3x Combo
On 17/08/2015, Warin <61sundow...@gmail.com> wrote:
> On 17/08/2015 7:20 PM, Mateusz Konieczny wrote:
>> In that case it is perfectly OK to do not edit map and keep it as it
>> was

The problem with that is that the map will be wrong for 5-15 years
(depending on what kind of trees are being grown). I suggest tagging
the logged area as natural=scrub, and leave the overall
landuse=forest(ry) as-is.

>> (yes, as I understand it and it seems to be a widely used in this way -
>> landuse=wood, natural=wood,
>> landcover=trees are used currently for the same objects).
>
> Err disagree, they are not the same.
> To me "landuse=wood" (or landuse=forestry) imply that the area is used
> to produce wood products.
>
> There are areas that have trees .. that are NOT used to produce wood.
> Here I would use natural=wood (or tree/s), landcover=trees.

Martin was talking about an area where the trees have recently been
logged (harvested), so this is absolutely about wood production.

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


Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]

2015-08-17 Thread moltonel 3x Combo
On 16/08/2015, Martin Koppenhoefer  wrote:
> which landuse is good for an area where trees have just been logged and
> will soon be planted again?

landuse=forest, which I've always reasoned of as being landuse=forestry :)

> Which landuse value is suitable for an area
> where the trees have just been extinguished by a fire?

Same landsue as before the fire, if there was any.

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


Re: [OSM-talk] landcover=trees [was Re: OpenStreetMap Carto v2.33.0 release]

2015-08-17 Thread moltonel 3x Combo
On 16/08/2015, Mateusz Konieczny  wrote:
> 2015-08-16 15:27 GMT+02:00 Greg Troxel :
>>
>> landuse=forest does not imply the area is completely tree covered.
>
> Note that in typical usage it means exactly this. Maybe original intention
> was for that tag was to mean something else - but it is not changing how
> it is used by most mappers.

If only there was a good way to assert "typical usage", we might have
managed to standardise on it and solve the problem by now.

The landuse=forest definition of "area where trees are grown for
commercial purposes, expected to be covered by trees by default but
often also natural=scrub for about a decade after logging" is fairly
typical too. FWIW, that's the definition I've been using in my
mapping, as all the others (managed, named, size, etc) seemed very
impractical.

If everyone adhered to my POV we wouldn't have a problem (sarcasm).
But I've given up hope of that happening, so the next best thing IMHO
is the landcover=trees reboot, which isn't perfect but which we can
hopefully agree on.


On 16/08/2015, Greg Troxel  wrote:
> One could argue that natural=trees is a synonym for landcover=trees.

That'd work for me as well, it actually sounds much better. But
pragmatically I prefer to follow the more popular tag, unless I see
some strong consensus for natural=trees elsewhere.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-17 Thread moltonel 3x Combo
On 17/08/2015, Martin Koppenhoefer  wrote:
>> Am 17.08.2015 um 02:39 schrieb moltonel 3x Combo :
>>
>> * A broken bridge with just a few meters left on both riverbanks
>
> I surely wouldn't have removed this one. Isn't this a significant feature to
> many people?

In only deleted the middle bit, not the bridge=yes stumps. At least
that's what I remember; I couldn't find it again in
https://www.openstreetmap.org/changeset/16286467. Maybe it was a
different railway line.

On the other hand, there's an instance of a bridge that is the only
thing left standing (green undisturbed meadows on both sides), and
that bridge is kept in OSM (while the sections in the meadow were
not).

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-16 Thread moltonel 3x Combo
On 16/08/2015, Martin Koppenhoefer  wrote:
> it really depends, this is an example for an abandoned railway where reading
> the traces is quite easy, and which is tagged (IMHO correctly) as abandoned
> railway in osm:
> http://www.dieter-kloessing.de/Berlin/Berlin-Zehlendorf3.html#Anchor-Stammbahn-47857

That actually looks like disused rather than abandoned to me.

> the wiki shows some interesting inconsistencies btw, it currently says
> disused are railways that could technically re-enter into service any time
> without much effort (track and infrastructure are intact), while abandoned
> are railways that railways where tracks and infrastructure are removed. This
> is there since 2012 (or 2011), but doesn't make sense because it leaves out
> at lot of stuff which would then fall between disused and abandoned.

To me the distinguishing criteria between disused and abandoned is
wether the rails are still present or not. This sometimes leads to
strange results (https://www.openstreetmap.org/way/223082804 would be
much harder to put back in service than
https://www.openstreetmap.org/way/216942301 despite being disused
rather than abandoned) but it's a nicely objective criteria.

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


Re: [OSM-talk] stop deleting abandoned railroads

2015-08-16 Thread moltonel 3x Combo
On 16/08/2015, Richard Fairhurst  wrote:
> Frederik Ramm wrote:
>> What everybody can see is a clearing or change in the surface
>> of something. That's fine to map.
>>
>> Inferring from that that there must have been a railway there is a
>> step too far. We are mappers, not trappers.
>
> Ok, let's try an experiment.
>
> Go to http://cycle.travel/map/journey/15120, click the route highlight (in
> purple), and click 'Find photos'.
>
> I spot a bridge in the characteristic Victorian railway style, a viaduct,
> the remains of a signal box, a large embankment of the type used to build
> railways and nothing else from that period, and A SODDING RAILWAY PLATFORM
> FOR CRYING OUT LOUD.
>
> Tell me again you can't infer there must have been a railway there. I dare
> you. I double dare you.

Sure, no need to be an expert to spot the former railway in this case.
I'm pretty sure Frederik had some less obvious examples in mind. But
that's IMHO not the point : the discussion is more about what's
mapworthy than what's inferable.

The "problem" with railroads is that because they are so long and
straight, it's easy to spot the missing sections wich wouldn't stand
out on their own. That's surely an important reason why we have more
arguments about dismantled railways than dismantled anything else.

IMHO being able to assert "there was a FOO here" does not imply that
we should map that FOO. At most, we should map the signs, such as
leftover embankments, sections of the railway that are now highway=*,
tree rows, etc. Some signs that help spot former railways but are IMHO
not reason enough to map a railway=abandoned include
differently-colored crop in a field, and neat long aligments of
various features.

Here are some railway sections that I have deleted, always aiming to
be conservative and giving a heads-up to the other mapper :
* Going through buidlings, a pond, and uneven slopes
* Running alongside (even reusing some nodes of) a perfectly modern highway=*
* Buried under the 15m high embankment of a trunk road
* A broken bridge with just a few meters left on both riverbanks
* Going across a field with just the faintest crop color difference
* Going between fields with just a 1m hedge separating them

I do empathise with Russ being angered at his work being deleted
without discussion. I'm sure most of his railway=abandoned are of the
mapworthy kind (yes, I know we don't have an objective definition for
this) and if those got deleted by an overzealous or badly-advised
contributor, it sucks.

But it's equally annoying and tiring to repeatedly encounter the
ludicrous kind of railway=abandoned, just because the mapper could
infer the location of the former railway using nearby visible sections
or old maps, or because he feels that former railways *must* be mapped
as an unbronken string of osm ways.

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


Re: [OSM-talk] OSM in India

2015-06-16 Thread moltonel 3x Combo
On 16/06/2015, moltonel 3x Combo  wrote:
>> We have had trials with localized maps
>> http://yogiks.github.io/osm-kn/map/ but apart from being good PR they
>> have
>> limited practical use in daily life.
>
> That looks good :) Add a proper domain name and a bit more dressing up
> work, and it could become more than just a PR stunt.

Also, even if Hindi maps have no practical use and are "just" good PR,
it is worth it. Publicity is a Good Thing when you're trying to grow a
community. Find ways to bootstrap the virtuous circle.

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


Re: [OSM-talk] OSM in India

2015-06-16 Thread moltonel 3x Combo
On 16/06/2015, Arun Ganesh  wrote:
> Businesses throughout the country want to list themselves on GM to get more
> customers. I have been to remote parts of the country where hoteliers or
> shop owners ask me how they can be listed. This POI database is massive and
> along with it comes address information which is data gold in India for
> geocoding. There is low business incentive for anyone to list themselves on
> OSM, moreover the computer skills to do that is lacking by most people.

That argument isn't specific to India, and hasn't stoped OSM growth
elsewhere. Note that it takes a long long time between "OSM data is
much better than GM" and "OSM is well known and used by the general
public".

> If there were more users of openstreetmap, this can change quickly.

Yes, it's logarythmic, beginings are slow.


> Its a given that most users of new technology in the country are familiar
> with English, or atleast the Latin alphabet. One may not be able to speak
> the language but can easily read street signs and it is more familiar than
> localized signage.

Same in Ireland, even the most hard-core Gaeltach advocates speak good
English. But that doesn't mean that nobody wants a map in Gaelic. For
most it's a cultural identity thing. They've been colonised by the
English in the past and want to assert their roots. In India this
ought to be even stronger, for all the people to whom English is a
foreign language.

> We have had trials with localized maps
> http://yogiks.github.io/osm-kn/map/ but apart from being good PR they have
> limited practical use in daily life.

That looks good :) Add a proper domain name and a bit more dressing up
work, and it could become more than just a PR stunt.

> We would need to support 22 languages and in offline mediums to make the
> maps truly accessible to most of the people.

Once you've got things working in one language, adding the other 21 is
little extra work and some extra hardware ressources (surely not 20x
more ressources).

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-16 Thread moltonel 3x Combo
On 16/06/2015, Andrew Wiseman  wrote:
> Something else semi-related that might be a terrible idea: I wonder if
> there ought to be some way to show which edits are by remote mappers and by
> locals? Could you do this automatically via IP address or something by
> seeing who was nearby and who was not?


That's an interesting approach. I don't think IP-based identification
would work because of all the false-positives : I spend my time
between France and Ireland, and I'm a local in both places even if I
edit while in the other country.

What I've been mulling over is the "home location" data on the
profile. Right now it's close to useless. I'd like to be able to set
multiple areas (not points) and rate them "can survey / good local
knowledge / particularly interested". The tricky part is creating a UI
that isn't overwhelming. Appart from categorising if an edit is
"local" or not, it'd be very helpfull to contact relevant contributors
for an area. Pascal Neis's tools are usefull (and have the advantage
of not requiring opt-in), but not as good as explicit information
would be.

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-15 Thread moltonel 3x Combo
On 15/06/2015, Arun Ganesh  wrote:
>> Not at all. I'm asking a contributor who feels that his local
>> community is not very strong if there's anything specific he thinks
>> could improve things.
>
> The very simple answer is that most people who know English and can afford
> a smartphone already use Google maps which work reasonably well in India.
> OSM is atleast 10 years behind in coverage and there is just a handful like
> me who have the luxury of free time who can see the long term benefits of
> contributing to open source. To the rest, they already have working maps,
> so why bother.

Fair enough. Although a quick mapcompare session shows that GM has
nowhere near the quality that it has in Europe/America, so it should
be less work for OSM to overtake GM in India than it took in Europe (I
know, if the community is tiny, "less overall work" is still way more
work for each individual).

You point out an interesting bit of information though: GM is for
English speakers. Do you render a Hindi (and other languages)
slippymap ? Provide Hindi OSMand and Garmin maps ? That might catch
the attention of many users. In Ireland we have an all-Gaelic map
(http://maps.openstreetmap.ie/?zoom=9&layers=00BFF&lat=52.92847&lon=-7.65252)
that attracts people from outside OSM.

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-15 Thread moltonel 3x Combo
On 15/06/2015, Lester Caine  wrote:
> You think it's only India that has problems with bad/expensive network
> coverage?

Not at all. I'm asking a contributor who feels that his local
community is not very strong if there's anything specific he thinks
could improve things. Since this thread mentions the "westerner bias"
a lot, I prefer to ask to get educated about a particular local
community.

> I can't drive down the M5 without loosing a data connection,

Me too, losing network on the go, I hate it. But let's be honest :
this pales in comparison to the coverage issues in many countries
(presumably like India, but my experience in the matter is getting
old).

> so OSMAND is the only way to work and that works on cheap android
> devices. I've actually got it running on a £40 tablet for a bigger sat
> nav display ...
>
> All that is lacking is that other apps go to OSMAND rather than trying
> to get google maps running ... which only works with a network link?

I've got a pretty good todo-list of what would improve my European OSM
contributor's life, but I was curious about India. It has a huge
population, good level of IT skills, offline functionality needs,
good-but-not-great Google maps... It ought to be a prime location for
OSM to shine, but it isn't (yet). I wonder why.

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-15 Thread moltonel 3x Combo
On 15/06/2015, Martin Koppenhoefer  wrote:
>> Am 15.06.2015 um 01:24 schrieb Warin <61sundow...@gmail.com>:
>>
>> There was a humours suggestion to map animal paths, rejected as not
>> something wanted in OSM.

For the record: http://www.openstreetmap.org/user/Pascal%20Cuoq/diary/1

> who in osm would be able to reject what can be mapped?

It's not rejected, it's discussed and argued about. In the link above,
the mapper was asking for community opinion to begin with.

>> To some native farmers those paths may be very significant. The rejection
>> reflects a 'western culture'.

I plead guilty of westerner bias in my answer in that blog, but the OP
was mapping in France, so a westerner POV was needed in this case. And
I maintain that animal trails probably should not be mapped in France.

> farmers or hunters? If something is sufficiently significant  to someone
> (and persistent) to map it and potentially maintain the mapping, he will
> just do it, not?

I agree with that, in France or elsewhere. *IF* the trails are
significant, persistent, and OSM-maintainable, they should be mapped.
But I think that the conditions are rarely met. Surely there are
regions of the world where they are more easily met, and asking the
local community will yield a different answer. Hopefully there's a
local OSM community there :)

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-15 Thread moltonel 3x Combo
On 15/06/2015, Arun Ganesh  wrote:
> Maps are a relatively new concept in Indian society and is still used only
> by a small minority in urban areas in daily life. Naturally one cannot
> expect strong OSM communities at this stage till maps gain wider
> reach. Remote mapping in cases like this can serve to catalyze the process
> by making the maps more attractive to use. I happened to talk about a few
> of these points in my lightning talk at SOTMUS last week which might give
> more context on mapping in India:
>
> https://youtu.be/4fK_cWhCQbE?t=22m1s
>
> Devoting more resources to make these maps and tools accessible to the
> common person would be more fruitful than worrying about colonizing
> countries by remote mapping.

Do you have any specific ideas on what would make OSM more compeling
in India ? I'm thinking along the lines of working better with cheap
phones and bad/expensive network coverage.Maybe smarter
surveying/editing tools. Maybe a combined Mapillary photo + OSM note
app.Maybe offline maps that are cut into smaller pieces.Maybe a smart
social media campaing.

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-14 Thread moltonel 3x Combo
On 13 June 2015 15:37:22 GMT+01:00, Frederik Ramm  wrote:
>http://groundtruth.in/2015/06/05/osm-mapping-power-to-the-people/

I really liked that article, but to me it doesn't argues *against
remote mapping* as much as it argues *for local mapping*.

I think everybody already agreed that local trumps remote, and the
article is enlightening about how important that is and even how to
define "local". But that doesn't mean that remote mapping is a bad
thing. To me, remote and local are two necessary tools in the box. OSM
wouldn't be hafl as good as it is today without that combinaison of
multiple mapper profiles who contribute to a given area.

If remote mapping slows local community growth (I have my doubts), or
if a New Yorker newbie makes a mess of african highway classification,
the way to treat this is to get more contributors, locals spread
everywhere, real strong diversity, better tools and documentation.
etc. The "solution" of holding off remote editing, letting the map
linger in a not-very-usable state for a potentially very long time,
does not sound very sensible to me.



> frede...@remote.org

Starting a thread arguing against remote mapping from an "@remote.org"
email address ? Love it :p

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


Re: [OSM-talk] Some thoughts against remote mapping

2015-06-14 Thread moltonel 3x Combo
On 14/06/2015, Kate Chapman  wrote:
> On Sun, Jun 14, 2015 at 9:26 AM, Simon Poole  wrote:
>> Further we have additional material in the early simulations that Matt
>> Amos did that indicate that this is not unexpected given some
>> assumptions about editor motivation.
>>
> This sort of work has not really been updated recently however. The
> community has grown and changed over the years. I think if we were to look
> at motivations today vs. years ago they would likely be different. As OSM
> is used on larger and larger platforms it is possible that people have
> begun mapping to see their edits on Foursquare or Craigslist rather than
> previously where people might be mapping to make their own map.

Another aspect I see is that in the western world, proprietary maps
were already pretty decent when OSM started. In that context, the fun
of mapping a whole town is a important factor of community building.
Because otherwise, pragmatism entice people to contribute to the
proprietary map that they already use instead.

But if you're in an area of the world where government and commercial
maps are bad, and a HOT task suddenly propels OSM to being very
obviously the best map available for the region, then pragmatism
brings contributors to OSM instead. Compounding this effect, if you
live in these areas, chances are that life is hard and the you don't
have much time for editing or much mood for fun town drawing. In that
context, you're more likely to contribute if you can add a street name
here and a POI there than if you need to trace the basic road network
first.

You can take these musings with a grain of salt since I bring no study
to show how important these effects are, but I'd be really surprised
if the criterias that drive community-building of Nepal or Liberia
were the same criterias as for the USA or Netherlands.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-06-01 Thread moltonel 3x Combo
On 01/06/2015, Martin Koppenhoefer  wrote:
>> Am 31.05.2015 um 23:19 schrieb moltonel 3x Combo :
>> In both cases, it doesn't look like a take that routers and renderers
>> would want to take into account.

s/take/tag/

> why not? both seem to cover exactly the topic of on the ground signage that
> we discuss in this deviation of the thread

Both unsigned_ref and visible_name have obviously been chosen
specifically to not be picked up by the usual renderers and routers,
so these consumers should probably respect the maper's intent. In
contrast to the various signed=* tags which say "this is an actual
name/ref, but you shouldn't display it to the end user" that are
intended to be used by consumers.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-31 Thread moltonel 3x Combo
On 30/05/2015, Martin Koppenhoefer  wrote:
> there are ~600 visible_name

On Overpass there's actually only two places where "visible_name" has been used:
* In Venice, associated with a corresponding name=*, looks completely
superfluous.
* Somewhere else in Italy, associated with noname=yes and a note on
why the signposted name isn't a proper one.

In both cases, it doesn't look like a take that routers and renderers
would want to take into account.

> 37000 unsigned_ref

And 3 of those are associated with a ref=*. Not sure how this is
supposed to be used, it seems like a poorly-designed tag to me. Is
that inherited from TIGER ?

> 518 unsigned
> 400 signed
> 161 name:signed
> 124 name:sign
> 86 ref:signed
> 48 unsigned_name
> 47 ref:unsigned
> 16 name:signposted

Yup, founds those too after Simon explained things a bit.


> It seems that for names nobody cares to say whether they are signposted or
> not (or maybe only when the sign is different from the actual name), while
> for ref it seems common practice(?) to use unsigned_ref

I wouldn't trust or interpret unsigned_ref until I understand a bit
more about it.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, SomeoneElse  wrote:
> I've used name:signed=no (though this is by no means an accepted tag,
> and if anyone can come up with a more accepted version that does the
> same job I'm all ears).
>
> Maybe something like "name:signed=en;cy" might solve the "name
> verifiability" problem for Abergavenny?

I'll keep those in mind next time I survey such an area.

I'm not a fan of (un)signed=* (the most common in tagginfo) because
their meaning is not obvious enough. "name:signed=en;cy" would be a
first and open the multiple-value can of worms. But name:signed=yes/no
has 161 uses in taginfo, and name:CC:signed=yes/no seems like an
obvious extension.

>> What's wrong with "name" ? What's the UK policy on the content of
>> "name" for places with Welsh and English names ? If you want to see
>> Welsh names as often as possible but still make the local name more
>> prominent, use "local name (welsh name if different)" in your map
>> generating script.
>
> The problem here is that there are two* equally valid and correct
> "name"s (in on-the-ground verifiable terms) for Abergavenny.

Some communities pick one of the names for the "name" tag and others
put both in. In either case, it should be sufficient for following
directions. In this case we have name=Abergavenny, so local mappers
favored the english name.

While it's not necessary for following directions (use "name" for
that), I agree that it would be nice to know which languages are
signposted and verifyable on the ground. IMHO a signpost has never
been a requirement for name:CC (or even name actually). Which leads to
the "name:signed" discussion above. Would that cover all the usecases
and make people happy ?

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, Philip Barnes  wrote:
> On Fri, 2015-05-29 at 13:14 +0200, moltonel 3x Combo wrote:
>> And as it
>> happens, Абергавенни comes from Abergavenny rather than Y Fenni,
>> showing that some discernment was applied.
>
> Not sure I understand that statement, transliterating Y Fenni is equally
> valid in my view.

Precisely, transliterating Y Fenni would have been equaly easy, but
the contributor chose the transliteration of Abergavenny instead to
use in Russian. That choice was made by a human. That brings
Абергавенни closer to being an actual name rather than an automatic
transliteration.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, Maarten Deen  wrote:
> It depends on what you want. When someone asks me to navigate to
> Natanzon, Haifa how can I enter it when the only name in the map is
> נתנזון, חיפה?

Your software should know about both names (so that you can search for
either) and show you the local name (so that you can compare to
streetsigns) in addition to the name in a language of your choosing
(so that you know what you're doing).

And yes, I see the combination of "name" and a long list of "name:CC"
as a good backend for that requirement.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, SomeoneElse  wrote:
> I'd say that whether or not a name is actually usable to help navigate
> to a place is a pretty important piece of information.

True. And that what "name" should give you. The "name:CC" tags should
not be a hindrance, at most they should be given alongside "name" by
your satnav.

> For example,
> when processing OSM data for my own use I'll try and drop unsigned names
> and refs from roads (there's no point in saying "turn left on Foo
> Street" if "Foo Street" does not appear on the sign).

That's really neat. How do you know wether a street is signposted or
not ? I don't know of any tag that gives that info. I can't imagine a
good heuristic using name:CC.  I've added quite a few unsignposted
street names by asking locals.

> It's the same
> principle here - if there are 300 names for a place, are you really
> suggesting that I have to do an external check to some other database to
> find that as it's in South Wales, signs are likely to be in Welsh and
> English, so it's those language names that I need to look out for?

What's wrong with "name" ? What's the UK policy on the content of
"name" for places with Welsh and English names ? If you want to see
Welsh names as often as possible but still make the local name more
prominent, use "local name (welsh name if different)" in your map
generating script.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, p...@trigpoint.me.uk  wrote:
> On Fri May 29 11:27:41 2015 GMT+0100, moltonel 3x Combo wrote:
>> Even if it was justified, the reversals were either sloppy or biased : see
>> http://www.openstreetmap.org/node/10021976/history which got
>> "name:ru Лестер" deleted but was allowed to keep "name:ukЛестер".
>
> The Ukrainian names were added after the mapper engaged the UK community.

If that's the case, it means the reversal was biased rather than
sloppy, which is arguably worse. name:ru was first added 4 years ago,
name:uk 1 year ago. The more recent changesets that re-added name:ru
got a changeset discussion where the contributor explained his
verification process, which isn't much but is probably as good as can
be in this case. "Лестер" is the same message from Ukraine and from
Russia, but in the second case the messenger was shot.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, SomeoneElse  wrote:
> how do we distinguish in the Abergavenny case between the two
> established names and the "up to 7,000" (but realistically in the short
> term a few hundred) translations?  That's unfortunately something that
> name:xx in OSM doesn't give us currently

You don't distinguish them, and that's fine. There may be many many
more pleople using "Abergavenny" than "Абергавенни", but that doesn't
mean that the name isn't established, at its more limited scale.

Speaking of plain dumb transliterations that got established, have a
read of https://en.wikipedia.org/wiki/Place_names_in_Ireland . Despite
sharing the latin alphabet, all Irish placenames have been
systematically "translated" when Ireland was under British rule. The
transliteration job has been ridiculed by the locals and is no better
than what a modern algorythm would do, but for better or worse today I
live in "Kilkenny" more than I live in "Cill Cainnigh".

> A question to those suggesting "Абергавенни" as a name:ru for
> Abergavenny / Y Fenni - how to distinguish the latter (both are names
> that you can to compare with signposts to see that you're going in the
> right direction) with the former (which you can't, but a speaker of that
> language might use to refer to that place in their own language)?

Where the signpost toward "Pékin" (the french name for Beijing) ?
Where on UK soil can I find the city sign for "Londres" ? Foreign
names for local places *are* harder to verify, and we rightfully cast
a more critical eye on them. But we've got plenty of hard-to-verify
data in OSM, and we rarely take a deletionist approach to it. And for
better or worse, Russia-based contributors are better suited to know
what should go into name:ru than UK-based contributors. And as it
happens, Абергавенни comes from Abergavenny rather than Y Fenni,
showing that some discernment was applied.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, Martin Koppenhoefer  wrote:
> TL;DR; wikidata is a gorgeous project, combining their knowledge with ours
> is very promising. Still, in my opinion, for the current state of where
> they are (and where the tools to combine both are), I would _not remove
> tags_ from OSM just because the same information might be available in
> wikidata.

Agreed fully. It's not "either or" but "and". And the first step is
tooling : until I see a map that renders names in my language taken
from wikidata (at scale please, the qLabel demo is not good enough) or
that points me to the wikipedia article in my language, I won't bother
investing time in editing Wikidata for mapping purposes.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-29 Thread moltonel 3x Combo
On 29/05/2015, SomeoneElse  wrote:
> On 29/05/2015 07:07, Andrew Hain wrote:
>> Thank you Dave. As a British mapper I am ashamed that some people want
>> to make the map of my country less useful, and not only to Russian
>> speakers a long way away.
>
> Hang on, where is _anybody_ saying that?  The whole point of the thread
> is about whether it would be possible to use wikidata to make the map
> _more_ useful to people who don't speak a particular language, not
> less.

The thread opening was indeed about using wikidata translations (which
would make the map more usefull for all) and perhaps deprecating
name:CC in OSM as a result (which is much more debatable).

But then the question came up (By Richard I think ?) of which name:CC
should be kept for a particular object, and the large number of
name:ru in the UK (reverted by you and others) was given as an example
of an unaccepable name:CC. And then some agreed that name:en in
non-English-speaking coutries should get the same treatment.

This second paragraph can be seen as making the map less useful (I
share that POV). It has been argued that the reverts were justified
because the names were just transliterations and not real names, but I
think that this was overzealous (it wasn't blind tranliteration, there
was human skill involved). Even if it was justified, the reversals
were either sloppy or biased : see
http://www.openstreetmap.org/node/10021976/history which got
"name:ruЛестер" deleted but was allowed to keep "name:ukЛестер".

And just to be clear: pushing the decision of whether Лестер is the
correct russian name of Leicester to wikidata just so that OSM looks
cleaner is not a solution.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
On 28/05/2015, Andrew Guertin  wrote:
> Considering the existence of the former Soviet Union, and especially
> that there are areas of Ukraine where both Russian and Ukrainian are
> spoken and most roads, places, etc have names (and thus tags) in both
> languages, this number of 582,653 name:ru tags is hard to interpret.
>
>
> My skill with overpass-turbo isn't the best, but I was able to
> relatively easily limit a search to a bounding box around North and
> South America. Within that box, a search returned 2648 nodes and 909
> ways with name:ru (relations timed out).

Taginfo offers a quick way to view this:
http://taginfo.osm.org/search?q=name
http://taginfo.osm.org/keys/name%3Aen#map
http://taginfo.osm.org/keys/name%3Aru#map
http://taginfo.osm.org/keys/int_name#map
http://taginfo.osm.org/keys/name%3Aja#map
http://taginfo.osm.org/keys/name%3Ade#map
http://taginfo.osm.org/keys/name%3Afr#map
http://taginfo.osm.org/keys/name%3Aar#map

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
On 28/05/2015, Andy Mabbett  wrote:
>>>https://www.wikidata.org/wiki/Q84
>>>
>>> You can see its names in various languages by clicking the "Labels
>>> list" tab (then note slidebar)
>>
>> Call me stupid, but I don't see any clickable label list tab ?
>
> Sorry; you won't see it if you're not logged in.

Ah, I thought for a moment that I'd need to create an account and log
in, but then I saw that anonymous edits were accepted, so I assumed
that I could see everything that was to be seen. Then I saw the
translations in the json output that somebody linked, and wondered
again if I was blind when reading the renderd html.

> You'd need to log in and enable this gadget:
>
>https://www.wikidata.org/wiki/Wikidata:Tools/Gadgets#LabelLister
>
> I'll ask if there's a method for non-logged-in users to see them.

Please do.

I'm really surprised that translations aren't visible like every other
properties. Is there a technical or editorial reason ?

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
I agree with Dave here, but add some general remarks :

Please handle the questions of "should FOO-language name of an object
be allowed in the database ?" and "should that databse be OSM or
Wikidata ?" separately. The decision of whether "Абергавенни" should
be recorded as the Russian name for "Abergavenny" should be the same
for Wikidata and OSM.

I disagree with the idea that only local languages are acceptable,
firstly because you don't know that there isn't a local speaking that
language natively, and secondly because people have given names to
foreign places before even the first maps were drawn. A name doesn't
have to go through a vetting process to become a name. It becomes one
as soon as it is used and recognised by more than one person.

There's no point in complaining about name:ru (580k) when name:en is
at 1320k, name:ja 320k, name:de 280k, name:fr 270k, and the taginfo
map for all of those shows a worldwide distribution roughly matching
the worldwide OSM data density.

You can argue against machine-made non-reviewed translitterations,
because they don't add anything that a data consumer couldn't and
because they likely contain mistakes. But that's apparenlty not the
case of the name:ru changeset that got reverted.

I'm not worried about all named osm objects someday getting thousands
of name:CC tags because realistically that's not going to happen.
London still has a measly 154. Europe 46. Worldwide interest will
decide how far a given name goes, but I'd be surprised (and pleased)
if one place ever goes above 500.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
On 28/05/2015, moltonel 3x Combo  wrote:
> On 28/05/2015, Frederik Ramm  wrote:
>> If we could offload 99.99% of all name:xx tags to
>> Wikidata and keep them only in edge cases like your Scalinata di Trinità
>> dei Monti, why not? Why would a few cases in which name:xx tags remain
>> ruin the whole scheme?
>
> I really like the idea of offloading "translation" work to wikidata,

BTW, the usual way that OSM "offloads work from other projects" is by
importing said work into OSM...

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
On 28/05/2015, Martin Koppenhoefer  wrote:
> Another issue that can be seen here: nobody will want this "Puente Nuevo
> (París)" as a label for a bridge on a map (París)
> Funny ah? Every single entity in wikidata I have looked at had some issues
> in one or the other way, I believe we would get more problems than we would
> solve.

The issue here is that these strings are the name of the wikipedia
article in various language, which is *not* the same as the name of
the location in various languages. Wikipedia likes to add some
disambiguation text, which we do not want in OSM.


On 27/05/2015, Andy Mabbett  wrote:
>https://www.wikidata.org/wiki/Q84
>
> You can see its names in various languages by clicking the "Labels
> list" tab (then note slidebar)

Call me stupid, but I don't see any clickable label list tab ? The
closest thing I see is the list of wikipedia articles, which has the
problem mentioned above.

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


Re: [OSM-talk] Can wikidata links help fight name inflation?

2015-05-28 Thread moltonel 3x Combo
On 28/05/2015, Frederik Ramm  wrote:
> It is my impression that a large proportion of name:xx tags in OSM are
> added by "naming specialists" who do little else than large scale name
> additions.

Nothing wrong with that, a lot of OSM contributors specialize in some
type of data.

> it would probably not be too much to ask for them to indulge
> Wikidata instead of OSM.

Probably not.

> If we could offload 99.99% of all name:xx tags to
> Wikidata and keep them only in edge cases like your Scalinata di Trinità
> dei Monti, why not? Why would a few cases in which name:xx tags remain
> ruin the whole scheme?

I really like the idea of offloading "translation" work to wikidata,
but I see important issues :

1) Consuming the data at scale is not trivial. Querying wikidata API
for each osm object with a wikidata link would kill performance.
Consumers would need to mirror wikidata (with some luck just a dump of
Id->names) and keep it as up to date as the osm data.
1.2) It'd be a great thing to do regardless of what OSM decides about
its name:CC tags. But OSM shouldn't change its behavior until 1 or
more major rendering, geocoding, and routing projects have implemented
the workflow and come back to talk about it.

2) The cutoff for which name:CC belongs into OSM or not is arbitrary.
Ireland's first official language is Irish, but in most you won't find
anybody who speaks mainly Irish (yet we hope to reach 100% name:ga
coverage in OSM). At the other end of the scale, London is one of the
most cosmopolitain city in the world, so there's a fair chance that
all 154 London names in OSM correspond to the native language of
somebody currently living there.

3) Contributing to OSM is already very hard: most people in OSM's
target audience of "people whi have VGI to contribute" are not
tech-savvy. Raising the bar by making wikidata (with its different UI
and community style) doesn't sound like a good idea.

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


Re: [OSM-talk] Portal for users/casual mappers (Re: Tagging FOR the renderer)

2015-05-19 Thread moltonel 3x Combo
On 19/05/2015, Bryce Nesbitt  wrote:
> On Mon, May 18, 2015 at 9:14 AM, Simon Poole  wrote:
>>
>> You must have misunderstood something there, the top 50'000 (roughly 10%
>> of all) or so mappers have contributed essentially all (roughly 95%)
>> data to OSM. The long tail is not unimportant, but from a pure volume
>> point of view OSM is very dependent on its core contributors. Not that
>> this is a surprise or different than any other similar enterprise.
>>
>
> Keep in mind the type of contribution is different.
>
> This year I edited 250,000 trees with a bad tag.  That's a huge number of
> nodes, but not a significant contribution of knowledge.
> The "long tail" editors on the other hand may be supplying data in unique
> ways requiring local knowledge.

It's also likely that prolific contributors will work on mostly
armchair-mappable stuff, while the long tail will just add a
particular POI they care about. So once the initial basemap is "done"
by big contributors, I expect the number of changesets (but not the
amount of data) to shift toward long tail contributors.

Arguably, the long tail is what crowdsourcing is all about. But to
make it possible, we first need a huge amount of data, which comes
from top contributors. Both contributor profiles are necessary for
OSM.

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


Re: [OSM-talk] Tagging FOR the renderer

2015-05-18 Thread moltonel 3x Combo
On 18/05/2015, Daniel Koć  wrote:
> I think the mission will be accomplished once we have it integrated with
> OSM website somehow, just like we did with routing: there were already a
> few routing services using our data, so we may not care, but for average
> user they were just not here. And so is uMap.

Routing is different in that it is immediately useful to
*contributors*, who can now check that the OSM data is correct for
routing, just like the slippymap is useful to check that the data
looks good. uMap not so much : as a contributor, I'd rather use josm,
taginfo, overpass, or even data dumps.

As nice as it'd be, http://osm.org/ is not trying to be
http://maps.google.com/. It's not trying to be the One True Map Portal
that caters to every needs.

Some reasons off the top of my head, some strong and some weak :
 * The needs of contributors and users can easily conflict, and
priority is/should be given to the contributors.
 * Even without conflicts, the size of the contributor-focused todo
list means that enduser-focused features get constantly pushed back.
Help welcome.
 * Becoming the internet's one-stop map website would require huge
server ressources. Getting the kind of money required to run them
would require huge changes to the way OSM is run, which'd be dangerous
for OSM's freedom.
 * Similarly for manpower requirements; volunteers wouldn't be enough anymore.
 * A healthy ecosystem of commercial users is important for OSM. And
they should be able to do a better job of serving the end-user, so
it's probably a bad idea to compete with their use-case.

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


Re: [OSM-talk] Tagging FOR the renderer

2015-05-17 Thread moltonel 3x Combo
On 17/05/2015, Daniel Koć  wrote:
> 1. We should have some tools to let people render their own style, no
> matter how crazy. It's possible of course from the technical point of
> view (the data and tools are available and the licenses are open), but
> that is far too complicated for average Joe or Jane.

Did you even try the existing tools ? Tilemilll is very userfriendly,
and if Joe or Jane has trouble setting it up, they can just use the
MapBox instance. There's very little skill needed to start tweaking an
existing style, and the learning curve is IMHO not too steep,
considering how intrinsically complicated the task is.

> I suspect kind of P2P tools would be great, but have no clear ideas about it.

I have no idea how you'd apply P2P to map style design. It sounds like
you; ve heard of a great technology, and want to apply it to every
problem without fully understanding the technology and/or the problem.

> 2. But default map style is still underused. Reluctance to show
> "everything" on merits that it's "impossible", because it should be "a
> mess", probably does not take into account that some features may be
> rendered only on highest zoom levels.

I assure you the osm-carto devs are competent and take those things
into account. It's a design decision, they want the map to be pretty
as well, not just a show-everything endeavour. They've also stoped
rendering some things that they felt didn't match the usecase.
Nevertheless, they managed to continually increase the data density,
while making the style more eye-pleasing. Congrats to them.

That said, you really shouldn't focus too much on "the default map
style". Stop puting it on a pedestal, there are plenty of other
high-quality styles, and one size does not fit all. The fact that
anyone can make his own style (and that the data is rich enough to
warrant it) is one of OSM's strenghts. I wish we could emphasize other
syles more on osm.org.

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


Re: [OSM-talk] Mapillary plugin for JOSM

2015-05-04 Thread moltonel 3x Combo
On 04/05/2015, Jo  wrote:
> The Mapillary plugin for JOSM project was accepted. Coding will start in
> about 1 month. You can expect something to test by the end of June. Traffic
> signs may or may not make it in by the end of August.
>
> Peter Neubauer (from Mapillary) did mention that they are planning to
> 'locate' signs automatically which are in more than one photo on their side
> (using interpolation or is that extrapolation?), but that may be for later
> on. By locating I mean: the location of the picture showing the sign is not
> the location of the sign, obviously. Except in a close up taken on foot,
> maybe.

Looking forward to the josm plugin and the merging/locating of signs :)

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


Re: [OSM-talk] GeoHipster comment on OSM

2015-05-03 Thread moltonel 3x Combo
On 01/05/2015, Simon Poole  wrote:
> Am 01.05.2015 um 02:29 schrieb Nicholas G Lawrence:
>> Exactly why this is necessary is a mystery to me. If business wants to
>> make use of OSM data, they can download the planet file just like anyone
>> else. If business wants to contribute data, or donate equipment or
>> sponsor events, those things are also possible.
>
> It should be pointed out that during 2012 and 2014 and continuing with
> at least the LWG till today, dozens of companies and organisations
> (outside of the geo-industry) with questions have had no problems
> contacting the OSMF and getting an answer back, typically within less
> than 24 hours. The OSMF even has a published and working postal mail
> address (contrary to certain other organisations).

Contacting the OSMF is one thing, but for most companies the only
reason to do that is to clear a license question (which sadly come up
much more often than they should). The other reasons to want a single
point of contact is to get technical support and all kind of services,
which companies like Mapbox and Geofabrik cater for (I'm sure they can
proxy legal questions as well).

I can't help but draw a parallell between OSM and PostgreSQL, which
has the same "actual product is only owned by a community, but lots of
companies offer commercial support" structure. Nearly all other big
databases are backed by a single company, and PG regularly gets
feedback about people turned off by the lack of an official PG
company. No matter how many companies offer high quality support, and
that this setup is demonstrably better for the project as a whole,
some potential users will always be turned off.

So I feel that we don't have a problem with the current structure, but
perhaps we could present that structure better. Compare for example
http://www.postgresql.org/support/professional_support/ to
http://wiki.openstreetmap.org/wiki/Companies. Gary's "OSM for business
consortium" also has a nice ring to it (if anything, because the
members would be self-selected, it'd avoid a wiki edit war or a
complicated OSMF-led selection process).

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


Re: [OSM-talk] How to report spam/abuse on the wiki?

2015-03-30 Thread moltonel 3x Combo
On 23/03/2015, Bryce Nesbitt  wrote:
> More generally, is there a way to write a message a wiki admin may see, in
> the case where the matter may be more subtle than a simple spam delete?

Add an entry to http://wiki.openstreetmap.org/wiki/Spam

Reaction time varies, but some admins do keep an eye on this page.

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


Re: [OSM-talk] Voting on voting system for proposals

2015-03-19 Thread moltonel 3x Combo
On 19/03/2015, Clifford Snow  wrote:
> Requiring an accepted proposal plus good documentation sound like a
> reasonable policy. I would probably add, that the tag is sufficiently used,
> and/or be very desirable.

Note that actual use is far more important than documentation. For
example, some time ago a change in tagging of power stations that had
gone through the wiki voting process by the book did not get
considered immediately because of usage stats and perceived
usefullness. The thread is worth reading in full for people interested
in osm-carto decision making :
https://github.com/gravitystorm/openstreetmap-carto/issues/230

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


Re: [OSM-talk] Routing across parks

2015-03-11 Thread moltonel 3x Combo
On 10/03/2015, Mike N  wrote:
> On 3/10/2015 12:56 PM, Volker Schmidt wrote:
>> If I understand correctly that you want routing to cross a park as long
>> as the way in and the way out are connected to the perimeter of the
>> park. This is only correct in parks where you are free to walk anywhere.
>> Most parks in continental Europe do not work this way. Typically, but
>> not always, you have to stay on the paths.
>>
>> To solve this, one needs possibly a new (?) tag for parks like
>> stay_on_path=yes|no
>
> I agree - there needs to be areas of general walk permission established
> before a router can include that area.

Another common usecase is surface car parks. You've got lots of
pedestrian paths that lead to it, but nothing explicit inside it, and
even following the service=parking_aisle ways would be too
restrictive.

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


Re: [OSM-talk] Problem with usage of other values than yes for key building

2015-03-11 Thread moltonel 3x Combo
On 11/03/2015, Andreas Vilén  wrote:
> I map buildings with the bulding_tools plugin and it would take
> considerably longer if I looked for a better tag for each building I map,
> and retag every tagged building=yes

The way I handle that is by tracing buildings by type. All houses
first, then all garages, etc. Then I search for "new building=yes",
mass-tag them to the correct value, and move on to tracing the next
type. Usually there isn't more than 3-4 building types in an area, so
it really doesn't take much more time than using "yes" everywhere.

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


Re: [OSM-talk] Problem with usage of other values than yes for key building

2015-03-11 Thread moltonel 3x Combo
On 10/03/2015, Stefan Keller  wrote:
> Then, when looking at the wiki page [2] it mostly points to
> alternative tags, like
> * building=apartment => tourism=apartment
> * building=hotel => tourism=hotel
> * building=warehouse => shop=department_store (no indication to that
> in warehouse
> * building=church/cathedral =>  amenity=place_of_worship
> * building=school/hospital => amenity=school/hospital

They are not "alternative tags", but tags that are often associated
with that building type. For example appartments are very often
private, not touristic. Most warehouses are used for storage, not
shops. Churches can be deconsecrated and not a place of worship
anymore. Etc.

Use building=* for what the building *is*, and the other tags for what
the building is *used for*.

Tagging the building type is very usefull: they can be rendered
differently, QA tools know that sheds don't have an address (only the
house beside it), city officials get a good view of what's constructed
where, etc. "building=yes" is ok as a default, but you should consider
upgrading it to a specific value.

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


Re: [OSM-talk] Mapping dangerous bicycle locations?

2015-03-09 Thread moltonel 3x Combo
On 09/03/2015, Warin <61sundow...@gmail.com> wrote:
> Sharp curves .. would they not be obvious from the map it self .. one
> node on the sharp corner compared to many for a 'smooth' corner.'Masked'
> corners where some object hides on coming traffic (e.g. building,
> vegetation)  are also a hazard.
>
> These hazards exist for all kinds of traffic and not indicated on maps.
> Usually people are expected to be aware of their surroundings, not to
> rely on other aids as to what is visually obvious? :-\

From the osm perspective, all these extra bits of information may not
maped yet (road width, vegetation height...) or ever (relief). Even
when they are, deducing the visibility algorythmically is hard. You
might not want to render hazard=curve, but still want to provide it to
drive-assist software.

As for drivers being aware of their suroundings, if the local
authority decided to signpost a curvy road, it's a good hint that osm
should as well. It's not much different from tagging maxspeed.

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


Re: [OSM-talk] Mapping dangerous bicycle locations?

2015-03-09 Thread moltonel 3x Combo
On 09/03/2015, Bryce Nesbitt  wrote:
> There are in places bicycle specific warning signs (e.g. "sharp curve
> bicylists beware")
> and THOSE can definitely be mapped.

Agreed, we can probably draw the line on wether the hazard is
signposted. And most of the values in taginfo and the proposal look
like they can fit that criteria.

Note that http://wiki.openstreetmap.org/wiki/OpenHazardMap seems to
use a different set of keys, with usage stats comparable to hazard=*.
We probably want to merge the two schemes together.

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


Re: [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

2015-03-02 Thread moltonel 3x Combo
On 02/03/2015, Martin Koppenhoefer  wrote:
> He was interested in
> "special" trees and was asuming that trees close to other trees were less
> "special" (something I don't agree with per se, but in practice might have
> worked back then, because the mappers mapping "special trees" were
> typically mapping only those special trees, hence there was less
> probability of other trees _mapped_ nearby, even if there were actual trees
> in the real world).

Ok, that's a reasonable intent. But not a reasonable method, because
the heuristic is flawed, because "storing the result of an osm query
in osm data" is bad practice, and because a list of "normal" trees is
insanely harder to maintain than a list of "special" trees.

So there's not much to redeem the tag AFAICS. I'm happy to see it
deleted from objects, surely starting with that one import and then
double-checking the other changesets.

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


Re: [OSM-talk] [Talk-de] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

2015-03-02 Thread moltonel 3x Combo
On 02/03/2015, Martin Koppenhoefer  wrote:
> I can imagine people using it to determine importance of trees for rendering.

Out of curiosity, how would you render denotation=cluster differently
than other denotations ? Automatically create a forest polygon around
them ? Render them narrower than "normal" trees ? Why ? I can see the
interest in rendering landmark and natural_monument more prominently,
but the usecase for cluster is much harder to define (and if it
exists, a spatial query would probably still be better ?).

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


Re: [OSM-talk] Formal proposal: mechanically reverting fixme=set␣better␣denotation / denotation=cluster

2015-03-02 Thread moltonel 3x Combo
On 01/03/2015, Bryce Nesbitt  wrote:
> This is now a formal proposal to mechanically remove:
>
> denotation=cluster
> fixme=set␣better␣denotation
>
>
> From 200,000+ nodes.  See
> http://wiki.openstreetmap.org/wiki/Mechanical_Edits/Bryce_C_Nesbitt

I agree with deleting the fixme tag.

Concering the deletion of the denotation tag, on the one hand I agree because
 + its meaning is not obvious, and it doesn't seem to play well with
other denotation values
 + the same information can be obtained from a spatial query.

however:
 - there are ~20K uses of denotation=cluster that aren't associated
with the fixme, and therefore seemingly not done by the automated
edit. Please either delete all denotation=cluster tags regardless of
their origin, or explain why the cases are different.
 - The other most-common denotation values (urban and avenue) suffer
from the same issues. It would seem that *if* cluster is to be
deleted, urban and avenue ought to suffer the same fate.

I'm saying all this without having read the old discussions on the
topic; sorry if I'm beating a dead horse.

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


Re: [OSM-talk] [Imports] Mechanically Cleaning Up FIXME Tags

2015-02-27 Thread moltonel 3x Combo
On 27/02/2015, Christoph Hormann  wrote:
> fixme=stream␣attributes␣missing
> fixme=stream␣attribute␣data␣missing
>
> have not been added by an import but in an attempt to fix a broken
> import.  As far as i can see they indicate the waterway in question
> lacks a tag indicating if it is permanent or intermittent while the
> source data (NHD) generally contains such attributes and in the area in
> question a large fraction of waterways are non-permanent.
>
> Sensible ways to fix this particular problem would be
>
> (1) on the ground survey/check via aerial images (obviously)

Aerial images won't let you decide between stream=intermitent and
stream=ephemeral. At best you can rule out stream=permanent. So on the
ground survey it is.

> (2) deriving the corresponding tag from existing 'nhd:fcode' tag (like
> for example here: http://www.openstreetmap.org/way/45949047)
> (3) newly getting the corresponding tag from the NHD source data (by
> matching with geometry or id)

That looks like a good idea, that kind of data would be interesting to
import. 3) should be more robust than 2).

Note that in this context, having the objects tagged with fixmes is useless :
 * the list of stream ways with no stream type can be easily obtained
using an overpass query
  * if importing the stream types from some existing source, the
import won't care wether stream=fixme is set or not (it should of
course warn about other stream=* values and leave them as-is).

Even though there may not be an existing QA tool that checks the
presence of stream=*, these tags seem to be as useless as
fixme=name_missing. That doesn't mean that I'm eager to see them
mass-deleted. IMHO the harm they do is about on par with the version
churn of a mass delete would do.

As a comparison, getting off-stream-topic for a bit, in Ireland we
imported placenames from GNS a while ago, with a bunch of gns tags
included just in case at the time and now deemed useless. We still
have 7k such objects but we're not planning a mass-cleanup, we're
quite happy to manually cleanup whenever we happen to be updating the
place for some other reason.

> (4) remove the whole data where it has not been been modified by manual
> edits
> Given the  generally sorry state of the NHD/Canvec waterway data in America 
> option
> (4) might be the better thing to do (we are talking about stuff here
> that has not been touched for five years).

Is the data so bad that you would consider removing it regardless of
its fixme tags ? That seems a bit strange to me, but I admit not
having looked at the data much. I've said it before, but the presence
of bad fixme tags *should not influence* the decision to delete the
object or not.

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


Re: [OSM-talk] Standard rendering totally fuzzy for countries boundaries

2015-02-26 Thread moltonel 3x Combo
On 26/02/2015, Severin Menard  wrote:
> Hi,
>
> I would like to know where is the good door to knock on to report an issue
> with the OSM standard rendering. For a few months, it became totally fuzzy
> regarding the countries boundaries, almost preventing to distinguish the
> countries from each other. Eg in Westerm Africa from zoom 4, then zoom in
> on Senegal and Gambia down to zoom 9:
> http://www.openstreetmap.org/#map=4/15.88/-6.37
> I suggest to use the great improvements made on the osmfr rendering
> .

There's already quite a lot of discussion on github on this subect:

https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+boundaries
https://github.com/gravitystorm/openstreetmap-carto/issues?q=is%3Aissue+is%3Aopen+admin

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


Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags

2015-02-26 Thread moltonel 3x Combo
On 26/02/2015, Andreas Labres  wrote:
> On 25.02.15 08:01, Frederik Ramm wrote:
>>I think in many cases the proper action to perform on an object with
>> a FIXME tag that has "a low chance of ever getting addressed" is deletion.

highway=service
access=private
surface=asphalt
fixme=the surface type changes here according to imagery

Clearly that fixme is unlikely to be resolved anytime soon (survey
needed but impossible). And your suggested action is to delete the
actual way object ?? I wouldn't even remove the fixme.

Sorry for only offering an anecdote against your "in many cases", but
it reflects my general feeling. Deleting an unfixable fixme tag can
make sense; deleting the underlying object doesn't. The fixme tag may
be a hint that the underlying object is so bad that it needs to be
deleted, but the tag itself is no reason to delete. An interesting
version of "don't shoot the messenger" :p

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


Re: [OSM-talk] Mechanically Cleaning Up FIXME Tags

2015-02-26 Thread moltonel 3x Combo
On 26/02/2015, Bryce Nesbitt  wrote:
> *One)* We have a "fixme" system where human mappers are encouraged to pay
> extra attention to particular areas or objects.
>
> *Two) *There is an issue of mapper fatigue: each mapper will look at only
> so many such tags in a lifetime of mapping.
>
> *Three)* The fixme system is not self-cleaning.  Certain conditions result
> in fixme tags that are unlikely to be acted on.  There are some 1.3 million
> open fixme tagged items, more than half from mechanical tagging.
>
> *Four)* In some cases the fixme tags happen to be associated with poor
> quality imports. But this is not universal: some poor data has fixme tags,
> other poor data does not.

+1 on all that, except that 4) is barely relevant. If an import is so
bad that it needs to be undone, I really hope that the presence of a
fixme tag is not the only way to detect said import.

> -
> How about a two step process:
>
> *Step One ) * People who wish to delete a particular import look through
> the FIXME tagged items, and  propose specific deletions.  For example
> there's a bus stop import that looks to be of bad quality.  If that data is
> removed, the fixme tag will go with it. Problem solved.  *Make a specific
> proposal showing why the fixme tag is needed in order to clean the data.*

Fair enough, but note that the problem being solved is the bad import,
not the distracting fixme tags.

> *Step Two )  *Remaining fixme values with a count above 1 are
> reviewed.  If they are deemed to add value, or if they come from
> many hand mapping efforts, they stay.  The rest are mechanically trimmed.

The usual "find a frequently-used tag that ought to be deleted an
maybe its associated data fixed" process then. Not really specific to
fixme tags, until you point out a particular fixme value that deserves
the treatment.

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


  1   2   >