Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Richard Welty]

On 11/8/15 5:00 AM, Dave Swarthout wrote:
> Sorry to keep working this side topic but I want to add this
> information FYI. I just came across this interesting article that
> talks about the difficulty of editing relations in JOSM. Even though
> we're talking about routes in this thread I think it's still relevant
> to our recent discussions:
>
> http://sk53-osm.blogspot.com/2015/10/irish-vice-counties-creation-of.html
> ; and especially the section headed "Technical Aspects (OSM)". 
>
> In that section the author, sk53, says, "Creating a whole set of
> boundaries encompassing one country and part of another is not a light
> undertaking on OSM. It is fiddly work, and involves manipulating
> objects with many dependencies. In practice I find it somewhat
> reminiscent of software migration projects: mainly mundane but you
> need to keep your wits about you.
>
> Contrary to what some believe, none of the OSM editors can prevent
> damage to other objects in this process. Mapping boundaries on this
> scale inevitably involves relations, and relations are not
> semantically clean objects at the level of the OSM data model."
>
> I certainly agree with that assessment.
>
i have done a lot of work with admin boundaries in upstate NY and i find it
critical to have a well planned workflow when handling this situation.
otherwise
there are lots of things that are easy to forget.

richard

-- 
rwe...@averillpark.net
 Averill Park Networking - GIS & IT Consulting
 OpenStreetMap - PostgreSQL - Linux
 Java - Web Applications - Search




signature.asc
Description: OpenPGP digital signature
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Named junctions

[tomoya muramoto]

I'm a Japanese mapper, and I thank you for your work on Japan/Asia specific
problems.
It's very tough to read and understand a long discussion in English, so
maybe I'm lack of full understanding on this issue.

I'm sorry I couldn't grasp this problem at this time.
*Signals rendering is dependent on zoom level? -> Rendering priority can be
increased
*Multiple signals are shown? -> (1)Tagging rule can be changed to map only
one signal at the junction, (2)Rendering rule can be changed not to show
signals having same name
If existing tags are not enough, we need a new tag, like
traffic_signals_area

As for me, signals rendering seems not to be a big problem. Amenities
rendering also depends on zoom level. Multiple icon is better than nothing.

I think I'm not understanding this problem because I can *estimate* how
Japanese roads are. And I don't drive, so I don't know what informaiton are
useful for drivers.

If you need some opinion from Japanese community, I can post these issue to
Japanese ML.

muramoto

2015-11-07 11:50 GMT+09:00 John Willis :

> (This Was sent earlier but looks like it wasn't received. Cleaned up/
> clarified a bit and sent again).
>
>
> On Nov 6, 2015, at 1:30 PM, Marc Gemis  wrote:
>
>
> However, I do not see why the "ignorance" of the non-Asian mappers
>
>
> Full disclosure: I am an American. I moved to Japan in 2011, and my
> comprehension of written Japanese is poor (I don't know much kanji at all),
> which makes me much better than a tourist, but I can not claim to speak for
> native Japanese mappers, just what I see in the tagging/wiki. In some ways
> I am stuck in between, because my home (I'm married and not leaving Japan)
> and language don't currently line up yet, so I am very familiar with &
> mapping places I can't always parse the meaning of without research, and
> dependent on the EN wiki.
>
> 
>
> TL;DR:
>
> The English/German taggers are the leaders in the tagging scheme AFAIK, so
> it is important for you to be inclusive and flexible when making tagging
> schemes. This will solve issues that you will eventually have to solve
> anyway, so we might as well do it now, for the benefit of all regional
> maps, not just myself and my region. saying a regional rendering solves the
> issue just puts off solving the issue via making a proper tagging system
> that is flexible enough to handle the regional issues we don't know about
> yet.
>
> 
>
> There are many people who are native Japanese speakers mapping, as well as
> people who love Japan (and other Asian countries too, of course) but are
> native English speaking mappers - so I want to make OSM's default render as
> useful as the default render in Google Maps or better. At least I want to
> repair glaring omissions and polish when possible.
>
>
> AFAIK, the OSM JA mapping community Is similar to the Wikipedia community
> - they follow the lead of the larger English community. And since
> Europeans/English speakers are driving tagging and "proper tag
> documentation", they are following what we lay down in the wiki, as I
> understand it.
>
> So as we are driving the tag set being used and content of the wiki pages,
> that exerts a tremendous amount of control over everyone mapping
> everywhere.
>
> And since a lot of the world, map wise, is the same, the difficulties come
> up with difficult to imagine regional or cultural differences, which cannot
> always be solved by just having a region render it in their own style.
>
> I believe those regional differences should be rendered in the default
> OSM, as the default should be the most useful for all users.
>
>
> 1) Asian countries, due to the script barrier of their language, offer
> most everything (at least in Japan) in JA and EN - which is reflected in
> dual labels for of most navigation signs throughout all of Japan. This is
> embraced in the default view of google maps, but not in OSM/-carto. This
> idea of dual language labeling should eventually become standard for
> non-standard scripts makes it useful for visitors, residents, and other
> Asians. It also describes the situation on the ground - everything (in
> Japan at least) is coated in English for non-native speakers, so the
> default render of OSM should reflect that.
>
> 2) Font issues persist. I helped a bit with updating the fonts, but very
> complex characters are difficult to read, there are not many different
> character weights supported, and shields, even with the render change,
> still render Kanji refs badly.
>
> 3) Japan is hit by a spatial mapping issue triple whammy:
>
> - no road names on tertiary or below (90% of all roads have no name or
> ref)
> - A very very dense place name system & lot number based addressing:
> nothing is labeled in sequence along the roads - a map is necessary to
> locate almost any structure.
>
> - the need for signals to have consistently rendered icons and for some to
> be named for spatial / map usage for visual navigation. 

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Dave Swarthout]

Sorry to keep working this side topic but I want to add this information
FYI. I just came across this interesting article that talks about the
difficulty of editing relations in JOSM. Even though we're talking about
routes in this thread I think it's still relevant to our recent discussions:

http://sk53-osm.blogspot.com/2015/10/irish-vice-counties-creation-of.html ;
and especially the section headed "Technical Aspects (OSM)".

In that section the author, sk53, says, "Creating a whole set of boundaries
encompassing one country and part of another is not a light undertaking on
OSM. It is fiddly work, and involves manipulating objects with many
dependencies. In practice I find it somewhat reminiscent of software
migration projects: mainly mundane but you need to keep your wits about you.

Contrary to what some believe, none of the OSM editors can prevent damage
to other objects in this process. Mapping boundaries on this scale
inevitably involves relations, and relations are not semantically clean
objects at the level of the OSM data model."

I certainly agree with that assessment.

Cheers,
Dave

On Sun, Nov 8, 2015 at 1:55 PM, Martin Koppenhoefer 
wrote:

>
>
> sent from a phone
>
> > Am 08.11.2015 um 05:47 schrieb Richard Welty :
> >
> > otherwise
> > you get into relations that you can barely if at all load into an editor.
>
>
> +1, also the risk of a conflict on upload is higher for big relations
>
>
> cheers
> Martin
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>



-- 
Dave Swarthout
Homer, Alaska
Chiang Mai, Thailand
Travel Blog at http://dswarthout.blogspot.com
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Named junctions

[johnw]

> On Nov 8, 2015, at 7:17 PM, tomoya muramoto  wrote:
> 
> I'm a Japanese mapper, and I thank you for your work on Japan/Asia specific 
> problems.
> It's very tough to read and understand a long discussion in English, so maybe 
> I'm lack of full understanding on this issue.

Just trying to solve mapping issues where I am ^_^

> 
> I'm sorry I couldn't grasp this problem at this time.
> *Signals rendering is dependent on zoom level? -> Rendering priority can be 
> increased

rendering priority for signals should be increased, at least to make the map 
better in Japan. This is the reason a traffic signal is an original emoji icon 
- for map display (AFAIK). 

> *Multiple signals are shown? ->

> (1)Tagging rule can be changed to map only one signal at the junction,

Cant do that. The need the signal to know when a car encounters a signal

> (2)Rendering rule can be changed not to show signals having same name

that is a possibility, but I think that would require a relation.

> If existing tags are not enough, we need a new tag, like traffic_signals_area

Which is why it was brought up. 

> As for me, signals rendering seems not to be a big problem. Amenities 
> rendering also depends on zoom level. Multiple icon is better than nothing.

If there is one set of signals, I would like one consistent icon. 

If you use a map for driving outside of Tokyo, counting lights is a big part of 
navigation - both how you tell people where to go. Business' billboards & signs 
show you   direction via light counting.  Without street names to reference in 
many places, it is the only reference point to have. 

and in OSM, zooming out a bit to see the route, the lights disappear. 

> I think I'm not understanding this problem because I can *estimate* how 
> Japanese roads are. And I don't drive, so I don't know what informaiton are 
> useful for drivers.

I have driven ~ 400,000 km in the US before moving, and about 100,000 KM in 
Japan since 2010. I have visited places all over Honshu, from Morioka to 
Hiroshima. my hobby is photography in the mountains (Gunma/Nagano/Gifu/Niigata 
Prefectures), so I spend a lot of time on the tollways driving, and going to 
places where I have not been before by car, and places that usually do not have 
train access. This means I get a lot of practice navigating Japan via car, and 
using guides brochures printed for tourists who drive to locations. 

> 
> If you need some opinion from Japanese community, I can post these issue to 
> Japanese ML.

Thanks for the offer! I’m sure the mailing list will use that. 

Javbw


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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[moltonel 3x Combo]

On 08/11/2015, Dave Swarthout  wrote:
> In that section the author, sk53, says, "Creating a whole set of boundaries
> encompassing one country and part of another is not a light undertaking on
> OSM. It is fiddly work, and involves manipulating objects with many
> dependencies. In practice I find it somewhat reminiscent of software
> migration projects: mainly mundane but you need to keep your wits about
> you.
>
> Contrary to what some believe, none of the OSM editors can prevent damage
> to other objects in this process. Mapping boundaries on this scale
> inevitably involves relations, and relations are not semantically clean
> objects at the level of the OSM data model."

While I agree that relations can break and can be tricky to edit, I
find it tiring to see this argument repeatedly used against the use of
relations for this or that usecase.

The stuff we map is becoming more complex and, in increasingly many
cases, relations are the best available tool for the job. Why complain
about the difficulty of editin boundary,multipolygons,or routes
relations when maping the same features without relations would be
even worse ?

There are some grey areas: when do I switch from a shared-nodes closed
way to a multipolygon (or from ref tag on ways to a relation), but
we're lucky enough to have options. Let each maper decide wich
technique makes the best use of his (an furture contributors's) time.

Sure, It'd be great to have proper Area (and maybe even Multiline)
elements in the OSM data model to replace hacky uses of the Relation
element. Or even "just" have the API check uploaded relations for
geometrical correctness. But don't wait for that to start using
relations.

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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Dave Swarthout]

On Mon, Nov 9, 2015 at 5:39 AM, moltonel 3x Combo 
wrote:

> While I agree that relations can break and can be tricky to edit, I
> find it tiring to see this argument repeatedly used against the use of
> relations for this or that usecase.
>

Your point is well taken. You've heard the last on this topic from me. I
suppose in some way my arguments are an attempt to raise awareness of the
limitations of the tools we use to work with relations not with the use of
relations, which are certainly necessary to deal with complex mapping
situations.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Andy Townsend]

On 07/11/2015 23:02, Martin Koppenhoefer wrote:


Are multiple relations for (pieces of) the same route really a big problem? We 
could have multiple relations until they meet and then merge them.



The problem isn't that we can't merge multiple relations later, it's 
that we can't stop them being created in the first place.  Also "we can 
merge" might need a survey to resolve differing tag issues, as the the 
knowledge of "how to merge relations" and "what it's actually like on 
the ground" will likely be in different people.


Cheers,

Andy (SomeoneElse)



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

Re: [Tagging] Proposal: Sunset ref=* on ways in favor of relations

[Colin Smale]

 

Surely the fact that it is difficult to get it 100% perfect should not
stop us from moving at all? As with all "big" problems, a
divide-and-conquer strategy often helps to make things achievable which
at first glance seem insurmountable. 

As this functionality really should be built into each and every editor,
we need a mechanism to make sure that all editors implement the same
rules. To me, that means documenting something in a way which
distinguishes between right/good and wrong/bad, which is often thought
to be against the laissez-faire nature of OSM because it limits the
freedom and creativity of mappers. Getting that balancing act right is a
difficult challenge. 

//colin 

On 2015-11-08 13:33, Andy Townsend wrote: 

> On 07/11/2015 23:02, Martin Koppenhoefer wrote: 
> 
>> Are multiple relations for (pieces of) the same route really a big problem? 
>> We could have multiple relations until they meet and then merge them.
> 
> The problem isn't that we can't merge multiple relations later, it's that we 
> can't stop them being created in the first place.  Also "we can merge" might 
> need a survey to resolve differing tag issues, as the the knowledge of "how 
> to merge relations" and "what it's actually like on the ground" will likely 
> be in different people.
> 
> Cheers,
> 
> Andy (SomeoneElse)
> 
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
 ___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging