from:"Minh Nguyen"

[Talk-vi] Thay thế danh sách thư talk-vi bằng diễn đàn chính thức

2023-11-10 Thread Minh Nguyen

Chào các bạn,

Tôi rất mừng nhận được các thư gần đây về cách đặt địa chỉ tại Huế. Lâu
lắm không thấy danh sách thư talk-vi nói năng gì hết. Chắc các bạn quá
bận lập bản đồ suốt ngày suốt đêm. :-)

Hiện tại cộng đồng Việt Nam/tiếng Việt của OSM không có một nơi thảo
luận "chính" như các cộng đồng khác. Trong số nơi thảo luận tiếng Việt
chỉ có danh sách thư này hoạt động trên máy chủ chính thức của Quỹ OSM.
Vào 14 năm hoạt động của danh sách này, mỗi năm chỉ có một vài thư trung
bình. Quỹ OSM đang định cho các danh sách không tích cực "về hưu", làm
cho người ta không thể đăng bài và chỉ có thể đọc các thư lưu trữ.

Ngoài danh sách này, nhiều người ghé thăm trang Facebook thường xuyên
[2], nhưng hình như chỉ có một vài người tham gia giúp đỡ người ta về
tagging và những chủ đề kỹ thuật khác. Một vài người cũng tham gia máy
chủ Discord toàn cầu [3], kênh châu Á trên Telegram [4], và không gian
Slack của OSM Hoa Kỳ [5]. Các kênh trò chuyện này rất tiện nhưng không
phù hợp việc thảo luận về quy định và những điều khác cần tra cứu sau.
Wiki của OSM phù hợp với mục đích này nhưng khó sử dụng để thảo luận.

Năm ngoái Quỹ OSM đã thay thế diễn đàn (forum.osm.org) và trang hỏi đáp
(help.osm.org) bằng một diễn đàn Discourse khang trang mới mẻ
(community.openstreetmap.org). Phần mềm Discourse rất dễ sử dụng đối với
danh sách thư:

* Tự động sử dụng tài khoản OSM của bạn, không cần đăng ký riêng
* Giao diện toàn tiếng Việt
* Nhúng hình ảnh để cho thí dụ
* Trả lời bằng emoji để không làm phiền cả cộng đồng
* Tiếp tục nhận các tin nhắn qua thư điện tử dùng "chế độ danh sách thư"
* Hoàn toàn là phần mềm nguồn mở giống như OSM

Diễn đàn có thể giúp chúng ta tăng trưởng cộng đồng này vì được tích hợp
với trang OSM chính cũng như cộng đồng OSM nói chung. Đây là diễn đàn
toàn cầu có bài đăng trong nhiều ngôn ngữ, nhưng mọi bài đăng có nút
tiện để dịch máy sang tiếng Việt. Ngoài ra, mọi cộng đồng địa phương có
thể lập một chuyên mục riêng dành cho ngôn ngữ của họ.

Tôi nghĩ chúng ta nên bắt chước các cộng đồng Đài Loan, Hàn Quốc, Thái
Lan, Mỹ, Úc... bằng cách dành riêng một chuyên mục cho những người đến
từ Việt Nam, đóng góp vào bản đồ Việt Nam, hoặc nói tiếng Việt. Năm
ngoái Nguyễn Quang Huy đã thử tạo ra một chủ đề về Việt Nam tại diễn đàn
[6], nhưng chúng ta vẫn cần tuân theo quá trình: chính thức yêu cầu
chuyên mục, biểu quyết chọn điều hành viên.

Thứ nhất, các bạn có đồng ý đóng cửa danh sách thư này theo kế hoạch của
Quỹ OSM không? Thứ hai, các bạn có đồng ý thiết lập chuyên mục Việt tại
diễn đàn không?

Thân mến,
Nguyễn Xuân Minh

[1] https://github.com/openstreetmap/operations/issues/975
[2] https://www.facebook.com/groups/openstreetmapvietnam/
[3] https://discord.gg/openstreetmap
[4] https://t.me/OpenStreetMapAsia
[5] https://slack.openstreetmap.us/
[6] https://community.openstreetmap.org/t/osm-vietnam-community/1226

--
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-vi] Addresses in Hue

2023-11-10 Thread Minh Nguyen


Vào lúc 00:07 2023-10-27, Vũ Phạm Minh Tuấn đã viết:
Kiệt 66 = Alley no. 66 > you can refer to this as the *street 
name*, since it's the closest street available.


What's interesting is that the 'number' of the alley is the house number 
of the Alley on the main street as well. In this case, generally the 
"Kiệt 66" stands next to House number 68, or 64 of Le Loi Street

Lê Lợi = the Street = Le Loi Street (the Main street)


Do we need to introduce addr:substreet or addr:parentstreet as the UK 
mapping community has done?




If this is a common need, then we can ask the iD project to add a field 
for it to the Address field for Vietnam.


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] Proposed bulk removal of service=driveway2

2023-06-27 Thread Minh Nguyen


Vào lúc 05:42 2023-06-27, Yves via talk đã viết:

That would be again discussing with the proponent, as Brian started.
Taginfo chronology already show one mass edit and revert, best to make 
sure there's not another waste of energy beforehand.


The mass edit and revert were performed by the same mapper, who seems to 
be open to performing the edit again. (If not, I'm sure we can find 
others would be.)


The DWG had requested that Brian restore the 9,500 or so occurrences of 
service=driveway2 until the community could reach consensus on this 
issue after a discussion on one of the mailing lists. [1] The most 
definitive answer that came out of the discussion was a suggestion to 
deal with these ways on a case by case basis, which turned out to be 
aspirational.


After a brief pause, the mapper who introduced these tags continued to 
do so at a steady clip. As far as I can tell, no other user has been 
deliberately adding this tag since the matter came before this list; 
most new occurrences by uninvolved mappers have been the result of 
splitting ways. [2]


The tag's proponent is asserting that removing these tags would squander 
their unparalleled effort. [3] The counterargument has been that adding 
these tags in the first place was and continues to be wasteful and 
misguided.


In my opinion, this is an easy call. We should redo the mass deletion. 
To the extent that this episode reveals any gaps in the tagging 
vocabulary, JaLoo(oo)Nz is invited to put forward a reasonable proposal 
through the usual process and respect the outcome.


[1] https://www.openstreetmap.org/changeset/125373826
[2] https://overpass-turbo.eu/s/1wF6
[3] 



--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] Intercultural differences / cultural diversity / OSM communication behaviors

2023-05-19 Thread Minh Nguyen


Vào lúc 19:03 2023-05-03, Imre Samu đã viết:
In addition to this, new OSM community members should be prepared for 
the potential culture shock they may encounter, especially those who 
come from a top-down corporate environment. It's important to remember 
that OpenStreetMap is characterized by a bazaar-style, bottom-up 
communication approach, which may be an adjustment for some. Embracing 
this unique aspect of the community will help newcomers adapt and thrive 
in the OSM environment.


In fact, this is a big topic, and when I consider the OSM community 
problems from the past few years through the viewpoint of cultural 
differences, it gives me a good understanding of the reasons.


First of all, I appreciate that you're avoiding the pitfall of 
suggesting a technical solution for a social problem.  ;-)


Maybe you're right that we should all build character and develop 
thicker skins. But there are alternative communication channels that 
don't place this burden on newcomers, not to mention alternatives to OSM 
that are competing for people's limited leisure time. After all, this is 
a mailing list in service of the OSM project, not the other way around.


Most of the Americans I've introduced to OSM are enthusiasts and curious 
onlookers who have never experienced a top-down corporate environment. 
They *expect* an egalitarian model. Yet I would hesitate to throw them 
into any of the larger mailing lists. There's too much office politics, 
too many hidden red lines to cross by accident. If a topic doesn't 
result in a pile-on, it is met with silence or peters out without consensus.


If we had a comprehensive how-to guide on the wiki about effective 
persuasion on the mailing lists, maybe the mailing lists would look a 
little more attractive -- or just difficult. Otherwise, you all wouldn't 
appreciate Eternal September anyways.


Generally, the OSM Talks mailing list is characterized by *"deep-level 
diversity," and as a result, more productive conflicts are expected than 
usual,* which is normal based on some diversity research [3]. This means 
that diverse perspectives and experiences can lead to more engaging 
discussions and ultimately result in innovative solutions and ideas for 
the community.


What about the inverse? If an OSM communication channel doesn't 
experience the same degree of conflict, does that necessarily mean it 
lacks the depth of diversity found here on the mailing lists, or is 
there some other relevant factor?


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] Extending the 'geo:' uri scheme: Adding parameter 'osmid'

2023-01-10 Thread Minh Nguyen


Vào lúc 00:59 2023-01-03, Simon Poole đã viết:
Not quite unexpected this discussion has already gone off on a tangent 
about stable ids. My question on the other hand would be: what do you 
actually want to achieve and what would you expect an application to do 
with the parameter?


Furthermore, would these goals align with the goals that the IETF laid 
out for the geo: URI scheme in RFC 5870?


* Compact
* Simple
* Human-readable
* Protocol-independent

An OSM element ID is compact, and a number is simple. But an element ID 
by itself is neither human-readable nor protocol-independent. This 
sounds more like a proposal for a new URI scheme that happened to latch 
onto geo: because it's also about geography.


While I think it would be an uphill battle to convince the IETF that OSM 
is important enough to have its own standard URI scheme, it would be 
much more feasible to register a URN namespace under the urn: scheme. 
For example, node 8330986510 could be .


You could think of it as the machine-readable analogue to how mappers 
often refer to "node 8330986510" in the middle of a sentence. It would 
allow software to decide whether to resolve the URN as:


https://www.openstreetmap.org/node/8330986510
https://www.openstreetmap.org/api/0.6/node/8330986510
https://nominatim.openstreetmap.org/ui/search.html?q=n8330986510
etc.

A formal, keyword-like URN namespace can be registered with IANA as long 
as it meets some requirements. [1] It needs to have organizational 
backing, which sounds like a role for the OSMF or one of its working 
groups. A given URN would need to be stable: for example, if one refers 
to a particular restaurant in Medellín, then the restaurant can close 
and be deleted in OSM, but the URN can never refer to a barber shop just 
because a mapper repurposed the OSM node to represent the barber shop 
across the street.


IANA also accepts informal, sequentially numbered namespaces that aren't 
subject to these constraints. For example, there's an informal namespace 
for Wikitravel, which uses Wikitravel article names (just as stable as 
OSM Wiki article names) as the identifier string following the 
namespace. [2] Someone would just need to write up an application and 
send it to IANA, but I suspect it still need to convincingly answer the 
question, "What for?"


[1] https://www.iana.org/assignments/urn-namespaces/urn-namespaces.xhtml
[2] https://www.iana.org/assignments/urn-informal/urn-6

It should be noted that we already have a couple of URI schemes in use 
for OSM based tools/editors, and naturally the website object/element 
browsing support.


Simon

Am 02.01.2023 um 18:57 schrieb Sören Reinecke:


Hey,

It came into my mind to get IETF to standardize a parameter explicitly 
linking to osm objects with their corresponding type and id.


The 'geo' URI scheme is standardized as RFC 5870 
 with examples of usage 
. It allows us to 
link to geospatial ressources from web pages or applications 
supporting URI schemes in general. It allows (web) developers to 
direct their users to their map browser of use e.g, Organic Maps, 
Google Maps, Apple Maps, ... The official osm.org makes use of this 
specification in the "share" feature already. Currently it only 
supports linking to geospatial ressources by their coordinates and not 
some id. As OpenStreetMap is playing an important part in the 
geospatial world, the OSMF should try to get IETF convinced.


See registered URI parameters in the 'geo' URI scheme:
'geo' URI Parameters registry at IANA.org 



Our own parameter could have the following syntax:

osmid=(N|W|R)


What do you think?

Greetings

Sören Reinecke


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


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


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] StateOTMap 2015 video is "private"

2022-12-16 Thread Minh Nguyen


Vào lúc 08:18 2022-11-24, Andy Mabbett đã viết:

I've just been told that the video of my 2015 SotM talk:

https://2015.stateofthemap.us/wikidata-for-mappers

https://www.youtube.com/watch?v=O6pnDQcrtwQ

will not play, being listed as "Private".

Does anyone know why, and who can unlock it?

Other talks, such as:

 https://www.youtube.com/watch?v=n8PVx0oudnA

seem fine.


All the videos from State of the Map U.S. 2015 should be publicly 
accessible again [1], along with videos from the WikiConference North 
America + Mapping USA conference last month [2]. Sorry again for the 
inconvenience!


[1] https://www.youtube.com/playlist?list=PLqjPa29lMiE2IlsRsfhi1aFGZfQLQDCrS
[2] https://www.youtube.com/playlist?list=PLqjPa29lMiE17qqIDxgONEMVkHzYjtLtW

--
Minh Nguyen
President, OpenStreetMap U.S. Board of Directors



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

Re: [OSM-talk] razed railways and other things that don't exist today

2022-12-05 Thread Minh Nguyen via talk


Vào lúc 09:55 2022-12-05, Zeke Farwell đã viết:
That is a good summary, though "Once the OSM available satellite imagery 
does not show the feature" is perhaps a bit too strict.  Some things 
aren't always visible or clear from aerial imagery and need to be 
surveyed in person.  I'm sure the intent of this phrase is not to 
encourage people to delete anything they can't see on aerial imagery, 
but it could be interpreted that way.


Yes, there have been several disputes between editors because of this 
exact scenario.


Also, I often need to keep a disused:shop=* around because the newest 
street-level imagery in an area is from before the shop closed. 
Sometimes mappers can be complacent about street-level imagery being 
fresher or more ground-truthy than aerial imagery, but this is not 
necessarily the case.


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] StateOTMap 2015 video is "private"

2022-12-01 Thread Minh Nguyen


Vào lúc 14:21 2022-12-01, Michał Brzozowski đã viết:

 > but apparently changing them en masse would spam the
channel's followers with notifications. (

Are you sure? If you upload a video (which in many contexts works like 
making it public) you can choose not to notify the subscribers.
I found this: 
https://www.reddit.com/r/youtube/comments/9qgg9u/any_way_to_publicate_an_unlisted_video_without/ 


Thanks, I forwarded that to our staff. For what it's worth, apparently 
these videos went private because of a YouTube-wide permissions change 
last year. [1] Again, apologies for the inconvenience.


[1] https://support.google.com/youtube/answer/9230970?hl=en

--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

2022-11-30 Thread Minh Nguyen


Vào lúc 06:49 2022-11-29, Simon Poole đã viết:


Am 29.11.2022 um 15:30 schrieb Greg Troxel:

   It seems obvious that asking a US
entity to enter into a contract under foreign law (and the same is
almost certainly true for any government entity in any other
jurisdiction) is just not going to fly.


You are assuming that the OSMF would require UK law, which might or 
might not be the case.


The contributor terms in question state:


This Agreement shall be governed by English law without regard to principles of 
conflict of law.
[1] 
https://wiki.osmfoundation.org/wiki/Special:PermanentLink/9165#Miscellaneous


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] FYI: Board now requires imports list (in)compatibility with OSM CT (& will work on a template)

2022-11-28 Thread Minh Nguyen


Vào lúc 15:48 2022-11-28, Tobias Knerr đã viết:

On 28.11.22 at Simon Poole wrote:

What is "OSM Contributor Terms compatibility" supposed to be?


Ok, this is clearly imprecise wording.¹

The context is that we would like to offer data donors a standard legal 
text that they can use to make their data available to OSM in such a way 
that we would expect it to survive a hypothetical license change. And 
yes, this would perhaps look similar to a CC0 waiver, except that it 
could potentially be a bit more limited (in a similar way the CT limits 
the set of licenses under which the OSMF can choose to publish the 
database).


So the column would be mostly about whether this legal text or something 
equivalent has been signed or not (+ perhaps public domain/CC0 data that 
has the ability to survive a license change by default could also check 
the box).


Could you clarify the "perhaps" here? If something has been explicitly 
dedicated to the public domain via CC0, a similar statement, or a 
relevant law, should it not survive any relicensing attempt? Or is this 
just about the editorial decision of whether to leave the table cell 
blank if relicensing is irrelevant for a given import? The wiki has a 
{{n/a}} template for this purpose.


I've already heard concerns from a couple U.S. mappers about this 
thread, because the community here been operating under the assumption 
that public domain datasets are the best-case scenario for inclusion in 
OSM. If a local government agency has already released something into 
the public domain, irrevocably and so forth, it would be 
counterproductive to send their legal department a scary-looking 
document to fill out. I don't know how I'd convince them that they have 
the legal authority to enter into an agreement governed by English law. 
Hopefully I'm overreacting.


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] StateOTMap 2015 video is "private"

2022-11-24 Thread Minh Nguyen


Vào lúc 08:18 2022-11-24, Andy Mabbett đã viết:

I've just been told that the video of my 2015 SotM talk:

https://2015.stateofthemap.us/wikidata-for-mappers

https://www.youtube.com/watch?v=O6pnDQcrtwQ

will not play, being listed as "Private".

Does anyone know why, and who can unlock it?

Other talks, such as:

 https://www.youtube.com/watch?v=n8PVx0oudnA

seem fine.


Hi Andy, we're not sure what happened, but at some point the access 
setting for nearly all the SotMUS 2015 videos got changed to private. 
We've been changing it back to public for individual videos as we hear 
about them, but apparently changing them en masse would spam the 
channel's followers with notifications. (These videos are all wonderful, 
but not all of them are evergreen!)


I'll follow up with our staff and hope to get your video sorted out 
shortly. Sorry for the inconvenience!


--
Minh Nguyen
President, OpenStreetMap U.S. Board of Directors


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

Re: [OSM-talk] Use of "Proprietary" imagery to edit OSM

2022-10-30 Thread Minh Nguyen


Vào lúc 07:11 2022-10-30, Greg Troxel đã viết:

But then the company doing the editing should document which company's
imagery and which revision year they are using.   Things should be as
transparent as possible, and this doesn't feel that way.


There was a recent subthread on this issue on the tagging mailing list 
too. I recently asked Lyft about the vintage and they said the 
street-level imagery they map from is mostly less than six months old, 
which editor-layer-index can't compete with. They expressed openness to 
sharing more details whenever there's a debate about something specific. 
I'll link the start of the mailing list discussion here so I don't have 
to repeat myself. ;-)


https://lists.openstreetmap.org/pipermail/tagging/2022-October/066080.html

For what it's worth, the argument about transparency would probably be 
more effective if it were actually an upfront expectation that applies 
to everyone. As it is, anyone could simply set source=survey or 
local_knowledge on their changeset and call it a day.


Unless I take the time to take more polished photos along my daily walk 
and upload them to Wikimedia Commons or Flickr with the correct 
metadata, my photos are copyrighted, all rights reserved, as unpublished 
works. The same goes with my field notes, which I've long deleted as 
soon as I finish mapping, never to be recovered by a fact-checker. 
Sometimes I'm left wondering if I made a typo until I return to the spot.


We could ask if the honor code should apply to such a prolific editing 
team. But do we actually have a problem with Lyft fabricating edits? I 
haven't seen evidence of that; it would be quite surprising for a 
company so invested in our project.


(Meanwhile, the U.S. community has had to spend quite a bit of energy 
following up on mappers who profit from mapping on NFT-based games, some 
of whom copy from Google Maps but lie about local knowledge.)


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] razed railways and other things that don't exist today

2022-10-27 Thread Minh Nguyen


Vào lúc 16:41 2022-10-26, Zeke Farwell đã viết:
On Wed, Oct 26, 2022 at 1:11 PM Greg Troxel > wrote:



I think people should keep in mind that a culture of deltionism is
demoralizing to contributors and harms OSM more than a few  marginal
items in the database.


This is a fair point, but given how often this comes up, it doesn't seem 
like it's just a few marginal items.  Also it's just as demoralizing for 
a well intentioned mapper who maps an area and removes some former 
railway in the process to then get berated for it.


I also agree with stevea@ -- old railways are usually visible in the
landscape, and the data about where they were in between visible places
seems more useful than harmful.


There is no question that the data about the location of former railways 
is useful.  However, data being useful is not the standard for inclusion 
in OSM.  We map the world as it exists today and this excludes plenty of 
useful data.  Former features that no longer exist are simply out of 
scope for OSM .


Also note that people who do not like railroads often do not see the
evidence as well as people who are used to looking for it.


I support mapping old rail beds as railway=razed where they are visible 
in forests, fields, and other open land.  These traces are often not 
visible to those with an untrained eye and that's certainly an issue.  
However, I draw the line at sections going through buildings, highways, 
excavated areas, or under water where there really are no visible traces 
by any reasonable standard.  In these situations, a person with a 
trained eye may see clues and patterns leading them to the deduction 
that a railway used to be there, but this is not the same as visible 
remnants.  This is mapping something that is really no longer there in 
any meaningful way.


I've deduced underground pipelines by similar methods, for example a 
natural gas pipeline that obviously follows a road as it crosses 
multiple streams above the ground. But I've done so with confidence that 
the visible portions must be connected somehow. There's much less reason 
to assume that the traces of a former railway continue to be connected 
below newer development. The pipeline would also be marked at regular 
intervals, so there's a strong possibility that a field mapper could 
improve upon the geometry that I've mapped from an armchair.


One could describe footway=crossing crossing=unmarked ways as another 
kind of deduced feature, connecting sidewalks on either side of an 
intersection. But there's a practical justification for their inclusion 
(routability), as well as a legal justification in some regions.


Some historic railway mappers would quibble at the notion that they're 
merely connecting the dots. Over the years, I've heard some rather 
tortured arguments, forcefully delivered, about these ways being the 
result of intense surveying. I tip my hat to anyone willing to devote 
their time to finding mappable railroad spikes via metal detector. 
However, we should expect them to document their findings meticulously, 
beyond just tagging source=survey on a railway=* and expecting to be 
consulted when it comes up for deletion many years later.


Personally, I never got into abandoned/razed railway mapping until I 
started contributing to OpenHistoricalMap. Former railroads are 
impossible to ignore when detailing the histories of so many towns 
across the U.S. Indeed, their remnants are all over the place; it's fun 
to realize that a tree line or embankment that you always took for 
granted fits into a hidden puzzle of former railroads. As a layperson, 
I'm only able to make these connections because of historic maps, 
photos, and timetables, the kinds of sources that are irrelevant to OSM 
but central to OHM.


I think historic railroad mappers who limit themselves to OSM's 
railway=abandoned/razed tags are missing out. Why not map the whole rail 
network as it was, unapologetically? In the areas where I map, OHM 
already has more former railroads than OSM will ever have, even despite 
the real ergonomic issues mentioned earlier in this thread.


--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] razed railways and other things that don't exist today

2022-10-25 Thread Minh Nguyen


Vào lúc 06:40 2022-10-25, Marc_marc đã viết:

when to migrate the data to ohm, I am convinced.
however, having tested it this month, it's horribly non-ergonomic
and I don't believe for a moment that it's within the reach of
an iD contributor nor of an average contributor with josm,
unless a plugin exists, which I haven't seen


Thanks for giving the project a look. In the long term, I think a 
credible OpenHistoricalMap project will be valuable to OSM as an outlet 
for this kind of information that people will inevitably want to map. 
It's good for us to know what we're sending history-minded mappers into.


I'm not surprised that you found major ergonomic issues. OSM 
unsurprisingly gets more attention from software developers than OHM, 
and not all of the OSM software that OHM forks was originally designed 
to be forked. If you have time to write up your experiences in OHM's 
central issue tracker [1], it could have a concrete impact on the project.


Some good news: the iD fork is being redone based on the latest version 
of iD, with more usable customizations than before. [2] The development 
team is working on some deployment issues, but the new version should be 
live soon.


[1] https://github.com/OpenHistoricalMap/issues/issues/
[2] https://github.com/OpenHistoricalMap/iD/pulls?q=is%3Amerged

--
m...@nguyen.cincinnati.oh.us



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

Re: [OSM-talk] remove link to Wikidata from infoboxes is a valid arg to remove it from wiki page and data items ?

2022-09-30 Thread Minh Nguyen

Vào lúc 08:46 2022-09-30, Andrew Hain đã viết:
The Wikidata links haven’t gone away; they’re in the OSM data items
where they are easily machine readable and can be curated against
accidental divergences between languages. The other description
arguments could just as easily follow (there’s no problem with them
being listed in the wiki infoboxes) but, given the similarities between
data items and Wikidata, I suppose it makes sense to start here.

Thank you for this clarification. I was momentarily confused by the
discrepancy between what was proposed in [1] and the alarm expressed in
this thread. Mateusz already went out of his way to accommodate us
Wikidata aficionados, sending his QID removal idea through the feature
proposal process instead of discussing it on an obscure template talk
page like most template edits.

I can see how it still came as a surprise to those less familiar with
how the templates work, but I don't think these edits are actually of
much consequence, because the data item statements remain. In the
future, if the community ever changes its mind about showing the QIDs on
the infobox, the infobox template can simply read it directly from the
data item.

It would be quite ironic for any data consumer to be scraping an unused
template parameter to discover a Wikidata QID of all things. I would
expect any data consumer enlightened enough to work with these QIDs to
also be capable of accessing the data items. (Data items are a joy to
work with compared to scraping wikitext. Changed my life. [2])

Mateusz, if this bot gets a mind of its own and starts deleting P12
statements from data items, please let a wiki administrator know. We can
temporarily block the bot while you make repairs.

[1]
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2410997#Remove_wikidata_parameters_from_infoboxes
[2]
https://wiki.openstreetmap.org/wiki/Special:PermanentLink/2399907#Getting_compound_key_documentation_from_the_MediaWiki_API

--
m...@nguyen.cincinnati.oh.us

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

[Talk-cr] Etiquetas ambiguas en las relaciones de ruta

2022-06-28 Thread Minh Nguyen


Hola,

La comunidad estadounidense está desarrollando OpenStreetMap Americana, 
un estilo de mapa nuevo que marca las rutas de carretera con los 
“escudos”, como en los mapas tradicionales. [1][2] Quisiéramos incluir 
los escudos de ruta de cada país, especialmente los países americanos. 
Usamos las etiquetas network=* para distinguir las redes dentro de y 
entre los países, sin mantener demasiadas reglas específicas para 
procesar las etiquetas ref=* prefijadas en las vías. Tentativamente las 
redes de carretera no reconocidos sólo tienen los números básicos en vez 
de los escudos correctos.


Desafortunadamente, en Costa Rica, todas las relaciones de carreteras en 
la Red Vial Nacional tienen la misma etiqueta network=CR:national, sin 
distinción entre las rutas primarias, secundarias, y terciarias, aunque 
cada clasificación deben tener escudos distintos en un mapa. [3] ¿A la 
comunidad costarricense le interesaría cambiar network=CR:national por 
los valores más específicos en estas relaciones? Con este cambio, Costa 
Rica podría ser uno de los primeros países latinoamericanos en que este 
mapa muestre los escudos correctos.


[1] https://zelonewolf.github.io/openstreetmap-americana/#7/9.818/-84.219
[2] https://wiki.openstreetmap.org/wiki/OpenStreetMap_Americana
[3] 
https://github.com/ZeLonewolf/openstreetmap-americana/pull/458#discussion_r906877834


--
Minh Nguyen 


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

Re: [Talk-vi] Chất lượng dịch kém của JOSM

2022-06-23 Thread Minh Nguyen

Mãi đến hôm qua dịch vụ biên dịch Launchpad mới xóa sạch các chuỗi dịch
thô. Cám ơn nhà phát triển Taylor Smock đã nhắc nhở Launchpad giúp chúng
ta khắc phục vấn đề này và ngăn trở các tình trạng tương tự trong tương
lai. [1]

Vì tỷ lệ dịch phần mềm đã sụt từ 60% xuống còn 0,5%, JOSM sắp sửa xóa
hẳn giao diện tiếng Việt trong vòng vài ngày. Nếu các bạn muốn khôi
phục, cải thiện giao diện tiếng Việt, xin mời các bạn đóng góp vào dự án
biên dịch JOSM. [2] Đây là một phần mềm khá ích cho cộng đồng OSM, nhất
là khi cần nhập dữ liệu từ cơ sở dữ liệu khác hoặc dọn dẹp các lỗi rất
phức tạp trên bản đồ.

[1] https://josm.openstreetmap.de/ticket/21720#comment:31
[2] https://translations.launchpad.net/josm/trunk/+pots/josm/vi/+details

Vào lúc 14:09 2021-12-30, Minh Nguyen đã viết:

Chào các bạn,

Tôi thường đóng góp vào OpenStreetMap dùng trang Web nên cũng đóng góp
vào bản dịch tiếng Việt của openstreetmap.org và iD. Tuy không nói tiếng
Việt như ngôn ngữ mẹ đẻ, nhưng tôi cố gắng giữ gìn chất lượng dịch cao
và chú trọng sử dụng thuật ngữ chính xác của dự án OSM.

Gần đây tôi tình cờ mò vào JOSM (ứng dụng vẽ bản đồ nâng cao dành cho
máy tính để bàn) và phát hiện rằng bản dịch của JOSM hoàn toàn sai lầm,
hình như bị dịch máy dùng một chương trình còn lộn xộn hơn Google
Translate. Chẳng hạn:

* Reverse Way => Cách Xếp
* Closing of changeset {0} failed because it has already been closed. =>
Bế mạc changeset {0} không bởi vì nó cóĐã bị đóng cửa.

* This is technically allowed => NàyLà kỹ thuật cho phép

Có khoảng 7.800 chuỗi sai như vầy, tức phần lớn của JOSM. [1] Tôi cảm
thấy bản dịch này rất khó sử dụng trừ khi đã quen sử dụng bản gốc tiếng
Anh. Tình trạng này sẽ làm người ta cảm thấy dự án OSM chế nhạo người Việt.

Bản dịch này được xuất bản năm 2015, khi ai đó ghi đè một số chuỗi dịch
chính xác của tôi và vài người khác bằng hàng ngàn bản dịch thô. Đáng
tiếc là phần mềm Launchpad lại có lỗi gì đó đổ thừa *tôi* đã nhập các
bản dịch thô này. [2]

Tôi đã yêu cầu xóa sạch bản tiếng Việt. [3] Tuy nhiên, nhóm phát triển
đã nghi ngờ bản báo cáo của tôi, từ chối xóa các bản dịch thô, và khuyên
cộng đồng người Việt cố gắng sửa chữa cả bảy ngàn chuỗi một cách thủ
công. Đáng tiếc là cộng đồng OSM Việt Nam vẫn nhỏ, còn nhóm người Việt
đóng góp vào phần mềm OSM còn nhỏ hơn. Tôi chẳng biết phải tốn bao nhiêu
thời gian để cải tiến bản dịch này.

Xin các bạn cho ý kiến bằng cách đăng nhận xét vào ticket [3]. Mong họ
xóa sớm để người Việt đỡ phải chịu rác rưởi trong phần mềm. Các bạn cũng
la làng thì chắc nhóm phát triển phải nghe thôi.

Thân mến,
Nguyễn Xuân Minh

[1] https://translations.launchpad.net/josm/trunk/+pots/josm/vi/+details
[2]
https://translations.launchpad.net/josm/trunk/+pots/josm/vi/+filter?person=mxn

[3] https://josm.openstreetmap.de/ticket/21720

--
m...@nguyen.cincinnati.oh.us

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

[Talk-vi] Chất lượng dịch kém của JOSM

2021-12-30 Thread Minh Nguyen

Chào các bạn,

* Reverse Way => Cách Xếp
* Closing of changeset {0} failed because it has already been closed. =>
Bế mạc changeset {0} không bởi vì nó cóĐã bị đóng cửa.

* This is technically allowed => NàyLà kỹ thuật cho phép

Thân mến,
Nguyễn Xuân Minh

[1] https://translations.launchpad.net/josm/trunk/+pots/josm/vi/+details
[2]
https://translations.launchpad.net/josm/trunk/+pots/josm/vi/+filter?person=mxn

[3] https://josm.openstreetmap.de/ticket/21720

--
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Washington DC place node cleanup

2020-12-05 Thread Minh Nguyen


Vào lúc 03:01 2020-12-04, Frederik Ramm đã viết:

Hi,

when reverting an edit this morning I noticed that the node for
Washington (https://www.openstreetmap.org/node/158368533) has myriad
name:xx tags, many of which seem to be some variant of "Washington D.C."
(with or without commas or dots), whereas the "local" name seems to be
just Washington, without the D.C.

As a native speaker of German I can assure you that we don't call the US
capital "Washington D.C." as the name:de tag claims; I would assume that
it is similar for most other languages. The German-language OSM map at
https://www.openstreetmap.de/karte.html?zoom=10=38.70174=-76.93764
has a mechanism where it displays the German name and then, if the local
name is different, the local name below; since the German name
"Washington D.C." and the local name "Washington" are different, this
leads to a somewhat funny display (whereas the logic works ok for other
US cities).

I could of course fix the German name but I think that it might need a
more thorough review and I don't feel competent for that.

Two name tags (and this is checking only those that use Roman letters)
look like they might be entirely wrong and refer to the District of
Columbia only:

name:lfn=Distrito de Columbia
name:mi=Takiwā o Columbia


Most of these localized names were added in changeset 76520412 [1] based 
on labels on the associated Wikidata item. [2] So this time it was not a 
case of promoting a particular minority language. In fact, I don't think 
much attention was paid to the names being added, or perhaps the Tajik 
name would've remained to the effect of "Washington District of 
Columbia" instead of being changed to "Washington (city)".


This same changeset changed the name of the District of Columbia 
relation to "Washington, D.C." in many languages, including English. [3] 
This results in Nominatim returning results like "Washington, D.C., 
Washington, D.C." I think it was inappropriate to rename the district 
this way. I think it was another oversight on the part of the 
changeset's author, because Wikidata has a distinct entity for the 
district. [4]


[1] https://www.openstreetmap.org/changeset/76520412
[2] https://www.wikidata.org/entity/Q61
[3] https://www.openstreetmap.org/relation/162069
[4] https://www.wikidata.org/wiki/Q3551781


Then again, I've heard people say "I was in D.C." and mean the city, so
perhaps that *is* a legitimate name for the city? Maybe someone in the
US community wants to have a look and do this right.

It is a bit of a conundrum in OSM - we usually say that local knowledge
tops everything, but then again for many of the languages there might
not even *be* a local Washington mapper in OSM ;)


As others have pointed out, a local would refer to the city as "D.C." 
even while acknowledging that the city's formal written name is 
"Washington" or "Washington, D.C." I think common sense would require us 
to relegate "D.C." to loc_name or short_name, just as a general-purpose, 
global map would only shorten San Francisco to the local shorthand 
"S.F." and Salt Lake City to "SLC" when space is at a premium.


Thanks in part to the D.C.-based Voice of America, I'm sure you could 
find a local to get the translated name of Washington, D.C., for many 
languages, but I'm not confident they would choose the same names as 
Wikidata.


For example, both VOA and the local Vietnamese media still generally 
call the city "Hoa Thịnh Đốn", a relic of the early 20th century when 
Vietnamese still borrowed Chinese characters for world-class cities. 
"Hoa Thịnh Đốn" is easy for a Vietnamese speaker to pronounce, but it 
only kind of sounds like "Washington" in the way that an eggcorn sounds 
like its original phrase. It's archaic and probably unknown to the 
younger generation in Vietnam. The Vietnamese government prefers the 
phonetic respelling "Oa-sinh-tơn", which conversely is unknown to older 
Vietnamese Americans.


When I originally tagged the D.C. node with Vietnamese names in 
changeset 5439052, I intended for the fallback to be "Washington", as a 
compromise between the traditional and more modern names. But I 
hesitated to explicitly tag name:vi=Washington because it's incompatible 
with the Vietnamese alphabet. I guess I should've added it as a bulwark 
against armchair linguistics. Changeset 76520412 set name:vi to 
"Washington, D.C.", which to a Vietnamese speaker is rather like 
labeling New Orleans as "New Orleans, LA" on a map.


Long story short, I find changeset 76520412 to be problematic in the 
languages I know, let alone the many languages I don't. Thanks for 
bringing it to our attention.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] While we're fixing things in iterations

2020-09-24 Thread Minh Nguyen


Vào lúc 15:56 2020-09-23, Andy Townsend đã viết:
I'm actually surprised that someone associated with the OSM US community 
hasn't created a proof-of-concept "good US road route rendering" variant 
of the OSM Carto style on a live server that people can use for 
reference (I'm guessing ongoing server costs wouldn't be huge - a couple 
of $ a day at one of the cheaper hosters).  Of the issues above (1) you 
can ignore in a proof of concept (or deal with some of the edge cases), 
(2) isn't an issue if you're just rendering the US and (3) isn't a 
problem if you can live with downtime at the occasional reload (or have 
two databases - one live, one available to be reloaded if you can't).


In 2012, Phil Gold and Richard Weait developed a "shield renderer" and 
set it up on an OSMUS server. [1] The renderer not only eschewed way 
refs in favor of route relations but also used the network=*, ref=*, and 
modifier=* keys to choose accurate shields consistent with road signage 
-- not a small feat for the U.S.


It was something of a proof of concept, apparently taking an approach to 
processing the relations and generating shields that would've been a 
nonstarter for the openstreetmap-carto project. The project did get 
pretty far in terms of supporting not only state-specific shield designs 
but even plenty of county-specific shield designs and some one-off 
shields. [2] However, the server isn't maintained. It ran out of disk 
space, so it hasn't kept up with OSM planet updates.


More recently, Kevin Kenny reimplemented the shield renderer using a 
more robust approach [3] and has discussed route relation support with 
the openstreetmap-carto developers. [4]


OSMUS is interested in offering an Americentric renderer replete with 
shields. If anyone would like to help with the server situation, let's 
get in touch. Also I'm sure Kevin would welcome any pull requests to his 
osm-shields project, which would probably be a good starting point for 
this renderer if we go with Mapnik and raster tiles.


[1] http://elrond.aperiodic.net/shields/
[2] https://bugs.launchpad.net/osm-shields/
[3] https://github.com/kennykb/osm-shields/
[4] https://github.com/gravitystorm/openstreetmap-carto/issues/596

--
m...@nguyen.cincinnati.oh.us
m...@openstreetmap.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

2020-09-24 Thread Minh Nguyen


Vào lúc 11:02 2020-09-23, stevea đã viết:

On Sep 23, 2020, at 10:51 AM, Brian Stromberg  wrote:

A short question of a lengthy response: What is the history behind that definition of 
'suburb'? Is it a result of the term being used that way in UK/Europe/elsewhere? Seems 
like an odd usage, since "suburbs" have had a very clear definition in the 
United States for decades now, and it has nothing to do with neighborhoods.


I believe it is UK-derived, as are many OSM "definitions" (usually / often 
clarified in wiki for that key).


If I'm not mistaken, the definition on the wiki seems to align more 
closely with the meaning of "suburb" in Australian English, in which 
it's understood to be anywhere within the city, even near the central 
business district. [1] place=suburb was originally proposed by an 
Australian mapper in 2006. [2] Also, around early 2008, Australia jumped 
from 7.8% to 29% of global place=suburb usage, which could have helped 
to reinforce that definition. [3]


The wiki says place=suburb is "in a place=town or place=city", but that 
doesn't necessarily say it has to lie within the administrative boundary 
that contains the place=town/city as a label. place=town/city is mapped 
as a POI, not as an area with distinct boundaries. But even so, it is 
pretty far from how Americans associate suburbs with distinct 
incorporated municipalities or unincorporated areas on the outskirts of 
the city.


[1] https://en.wiktionary.org/wiki/suburb#English
[2] https://wiki.openstreetmap.org/wiki/Special:Diff/55503
[3] https://ohsome.org/apps/dashboard/

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] While we're fixing things in iterations

2020-09-24 Thread Minh Nguyen


Vào lúc 10:45 2020-09-23, Paul Johnson đã viết:

Can we finally fix two other longstanding problems, then?

1. The wiki being incorrect about not counting bicycle lanes.  That's 
not reflective of how validators deal with lanes, how data consumers 
like Osmand or Magic Earth deal with lanes, or how ground truth works.  
The whole "but you can't fit a motor vehicle down it" argument is 
facile, that's what access:lanes=* and width:lanes=* is for.


I agree that width is a poor argument for the status quo, especially 
given the common practice (in California, anyways) of bike lanes that 
double as right turn lanes for cars.


For what it's worth, the lanes=* documentation has long included a 
passage recommending that data consumers treat lanes=* as a minimum 
value rather than a reliable exact lane count. Apparently some mappers 
only count through lanes but exclude turn lanes.


I'm pretty sure existing routers would have no problem with including 
bike lanes in lanes=*, as long as bicycle:lanes=* and vehicle:lanes=* 
are both present. So I think a reasonable migration path would be to use 
the bicycle:lanes=* and vehicle:lanes=* tags to explicitly mark the 
non-auto-centric approach you're advocating.


2. Tagging route information on ways.  It's about a decade too long at 
this point for ref=* on a way to be completely disconnected from the 
entity the tag applies to:  That's why route relations exist.  Biggest 
problem child on this at the moment:  OSM's own tilesets.  Let's drop 
rendering for ref=* on ways and just render the route relations already, 
this and multipolygons are why relations came to exist in the first place.


I'm as excited about route relations as anyone, especially because route 
relations are required for more nuanced route shield selection in 
renderers and routers. But for all the problems route relations solve, 
there are still some unresolved issues:


* Even once rendered maps display pictioral route shields [2], there 
will still be situations where plain text is more appropriate, just as 
on the ground. It isn't always obvious how to transform a particular 
network=* value into a human-readable ref prefix to display in prose or 
read aloud during turn-by-turn navigation. Signposted ref prefixes can 
be pretty idiosyncratic, like "CC" for network=US:NV:Clark. I'm slowly 
building up Wikidata's coverage of signposted road networks and linking 
it to OSM Wiki data items, to make it easier for data consumers to look 
up the human-readable ref prefix on demand [3] or export a lookup table 
like [4] to hard-code. Incidentally, I've also proposed a road name 
formatter property at Wikidata [5], so that data consumers can expand 
network=US:NV:Clark to "Clark County Route", but it hasn't gotten much 
traction yet.


* A way's ref=* key is an ordered list, whereas there's no explicit 
ordering of a way's membership in multiple route relations. (A relation 
explicitly contains its members but not the other way around.) A data 
consumer either has to hard-code some heuristics that may not always be 
accurate [3] or infer the order from the way refs, as OSRM does. [6] 
There's a parallel situation with route numbers associated with a bus 
stop. The route_ref=* key on the stop node makes the order explicit, 
since some agencies don't sort the routes numerically on signage.


* The destination:ref=* key uses the same prefixed syntax as way refs. 
No structured alternative has been formally proposed, but 
destination:network=* is common in Australia (where network=* is common 
on ways) and I've begun using destination:ref:wikidata=* in some parts 
of the U.S. I don't think it's too outlandish to imagine a future where 
navigation software uses destination:wikidata=* to detect street names 
that should be prefixed by "onto" instead of "toward" (instead of using 
destination:street=*, which takes some destinations out of order) and 
uses destination:ref:wikidata=* to choose the right shield to display 
and the correct ref prefix to read aloud.


[1] https://wiki.openstreetmap.org/wiki/Key:lanes#Description
[2] https://github.com/gravitystorm/openstreetmap-carto/issues/508
[3] 
https://wiki.openstreetmap.org/wiki/SPARQL_examples#Human-readable_route_refs

[4] https://tinyurl.com/yxk5ux8h
[5] 
https://www.wikidata.org/wiki/Wikidata:Property_proposal/road_name_formatter

[6] https://github.com/Project-OSRM/osrm-backend/pull/4524

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

2020-09-24 Thread Minh Nguyen


Vào lúc 21:47 2020-09-22, Paul Johnson đã viết:
On Tue, Sep 22, 2020 at 8:56 PM stevea 
> wrote:


If you MUST tag place=neighbourhood (note the u) see if you agree
with me that this tag makes most sense in a hierarchy where
place=suburb (and perhaps quarter, if applicable, is/are above) also
exist(s).  I'm not strictly saying I believe that
place=neighbourhood CANNOT exist without place=suburb, but it makes
me wrinkle my brow a bit at it not fitting as well as a
landuse=residential (multi)polygon might rather generically and
innocently (without any hierarchy required) fit in.


Landuse=residential fits better for the lots within a place, not as a 
substitute for it.


I've never gotten into mapping individual lots, but I agree that 
landuse=residential is a reasonable tag to use in conjunction with 
place=plot. [1] I don't think that needs to be mutually exclusive of 
mapping the surrounding subdivision as a named landuse=residential area.


[1] https://wiki.openstreetmap.org/wiki/Tag:place%3Dplot

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] place=neighborhood on subdivisions?

2020-09-24 Thread Minh Nguyen

Vào lúc 18:40 2020-09-22, Paul Johnson đã viết:

On Tue, Sep 22, 2020 at 8:36 PM Mike N 
> wrote:

On 9/22/2020 9:26 PM, Paul Johnson wrote:
 >         The extra hamlet nodes are import remainders that haven't
yet been
 >     converted to landuse areas.   The general landuse zones for
that area
 >     have been identified, but do not exactly correspond to the named
 >     subdivisions.   As I get a chance to survey, I divide the
landuse into
 >     subdivisions and convert the node to a named area for the
subdivision.
 >
 >
 > Please don't expand these as landuse, please expand them as
 > place=neighborhood instead.  Landuse polygons should be congruent
to the
 > actual land use.

That's a good point: the subdivisions often contain one or more landuse
basins, clusters of trees, etc.   I've been thinking of them as one big
blob, but it seem correct on a more micromap level to mark them as
place=, and identify the smaller landuse areas (which are sometimes all
residential).

Exactly.  My rule of thumb is if you're thinking about putting a name on 
it, and it's not a shopping center, apartment complex or similar large 
but contiguous landuse, then landuse=* probably isn't what your polygon 
should be.

It's common, intuitive, and IMO beneficial to map a planned, 
suburban-style residential development as a single named 
landuse=residential area. These developments have well-defined 
boundaries and are primarily residential in character. If there are some 
wooded lots in the subdivision, it's perfectly fine to map a 
natural=wood area inside of or partially overlapping the 
landuse=residential area, ideally without being connected to it. This 
approach is supported by longstanding documentation [1], old threads 
[2], and good support in both renderers [3] and search engines.

There have also been old discussions where folks have conflated the 
concept of landcover with landuse. [4] But I find this approach overly 
academic. Taking it to the logical extreme, landuse=residential would 
only be coincident to each house in a subdivision, given that the yards 
are non-dwellings.

I don't see the need for a fundamental distinction between planned 
residential developments consisting of multi-family apartments and those 
consisting of single-family houses, such that the former would be mapped 
as a coherent landuse area but the latter would be a shapeless place 
point. Where there's no such distinction, the landuse areas lend 
themselves to ab intuitive rendering that's good for navigating suburban 
sprawl. [5]

If a planned development truly is actually mixed-use, and not only in a 
garden-level micromapping sense, then something other than landuse=* 
would be reasonable, since a particular landuse doesn't characterize 
that development anyways. Named landuse=residential areas also don't 
tend to make as much sense in urban areas, older inner suburbs, and 
rural areas. But the areas in changeset 91255294 aren't mixed-use 
developments; they're residential areas in a suburban setting.

[1] https://wiki.openstreetmap.org/wiki/Special:Diff/1087300
[2] I previously wrote on this topic in 
 and 
it seemed like other respondents were taking the same approach.

[3] https://github.com/gravitystorm/openstreetmap-carto/issues/351
[4] 
https://lists.openstreetmap.org/pipermail/talk-gb/2017-January/019811.html

[5] https://osm.org/go/ZTVSa4OB

--
m...@nguyen.cincinnati.oh.us

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

[Talk-us] OpenStreetMap U.S.: Connect 2020 -- registration and call for proposals

2020-09-01 Thread Minh Nguyen

Please join the rest of the OpenStreetMap U.S. community for Connect 
2020 -- a free*, virtual event sharing cool ideas and celebrating our 
community from October 29 to 31. Registration is open:


https://www.openstreetmap.us/connect2020/

This isn't quite a State of the Map U.S. We're trying something new this 
year, and we can't pull it off without your help. Please consider 
proposing a session or volunteering as a facilitator. The deadline for 
session proposals is September 20. Here's the detailed call for proposals:


https://www.openstreetmap.us/2020/08/connect2020/

Looking forward to connecting with all of you!







* Free as in freeform tagging. Also free of charge.

--
m...@nguyen.cincinnati.oh.us
On behalf of the OpenStreetMap U.S.: Connect 2020 organizing committee


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-09-01 Thread Minh Nguyen


Vào lúc 06:17 2020-09-01, Matthew Woehlke đã viết:
On a related note: I use service=driveway (for lack of anything better) 
for access ways to parking lots that don't have parking spaces (hence, 
not service=parking_aisle). These are likely *not* public right-of-ways 
(the lots themselves are usually "private"), but they are also certainly 
not access=private.


The access roads that form the backbone of a parking lot layout 
shouldn't be tagged service=driveway. [1] You're right that there isn't 
a more appropriate, well-established service=* tag, since no one seems 
to know of a concise, intuitive term for these access roads. But there's 
also no requirement that every highway=service way have a service=* tag. 
(Shared driveways also commonly lack service=*, but there are at least 
some tagging ideas floating about.)


Routers that understand service=driveway treat it as the very bottommost 
rung in a hierarchy of road classifications, applying penalties similar 
to the penalties for parking aisles. These penalties generally ensure 
you'd never use a driveway as a shortcut between two non-driveways. But 
around a parking lot, they may lead to suboptimal routing to a loading 
dock or drop-off area, traversing ordinary parking aisles instead of 
these access roads that are likely to be wider and more traversible.


If we do someday come up with a good tag for the access roads you're 
describing, it'll be easier to identify and retag them if they lack a 
service=* tag than if they're tagged service=driveway. After all, 
service=driveway would be more appropriate for a drop-off area coming 
off a parking lot. In the meantime, it's rather nice that some renderers 
and editors give service roads deemphasize service=parking_aisle ways 
while leaving these bare highway=service ways a little more prominent by 
comparison.


So, no, service=driveway should *not* imply 
access=private. If anything, lacking other information, it should imply 
access=yes just like it does on any other way, and I suspect routing 
engines route accordingly.


This is my understanding as well. It's OK that a router generally treats 
driveways as accessible: most driveways are dead-ends, so a router would 
only lead a delivery driver down a driveway if they have a package to 
deliver to that house. (Clearly Amazon's intention is to know how to go 
down the driveway instead of stopping at the curbside mailbox.) On the 
other hand, if the driveway isn't a dead end, a penalty should prevent 
it from being used as a Waze-style shortcut around a more easily 
traversible public road.


This, BTW, is a large part of why we're having this conversation in the 
first place. The problem with overusing access=private is that we're 
effectively teaching routing engines to ignore that, which makes such 
tagging much less useful.


Exactly. As a mapper, I'd be concerned about a logistics company such as 
Amazon needing to route to the front door, so to speak, and therefore 
tossing out a convenient way to distinguish between two common kinds of 
driveways that can't be used in the same manner.


Vào lúc 12:56 2020-08-31, Kevin Broderick đã viết:
> Second, I'd like to point out that there *are* driveways in New England
> that are actually public right-of-ways.
> https://www.openstreetmap.org/way/19685143
>  is one such example; the
> southernmost portion of the way is arguably service=driveway, except
> that it is actually a public right-of-way that continues south,
> eventually connecting to Lincoln Gap Road. While they are certainly the
> exception and not the rule, the number of such setups in Vermont is
> non-trivial due to the ancient roads laws there. There are probably some
> similar cases in New Hampshire and possibly Maine, I believe, but I
> can't cite any off the top of my head (the documentation of unmaintained
> public-right-of-ways isn't as good as it is in Vermont, making things a
> bit more murky).

Penalties aren't absolute prohibitions, so if there's no other way to 
get to that public road, or if the alternative would take much, much 
longer, the router will hold its nose and use the driveway. But it can't 
do that if the road is marked as impassable via access=no or restricted 
via access=private.


It can be a bit unintuitive to think about routing penalties when 
mapping. During a navigation mapping workshop at State of the Map 2018 
in Milan, my colleague Kajari and I walked through a very basic 
application of a routing penalty to illustrate the concept. The workshop 
wasn't recorded, but the notes and slides are available at [2], with the 
explanation starting on slide 12.


[1] 
[2] 



--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-08-31 Thread Minh Nguyen


Vào lúc 07:00 2020-08-30, Greg Troxel đã viết:

What is the actual problem with other people's driveways being marked
access=private on the map?  yes, driving on is usually technically not
illegal, but unless you are going there because you were invited for
have a reason they'd approve of, it's basically not ok.


I expressed support for the proposed mechanical edit because the 
distinctions being debated in this thread didn't factor into the 
workflow that originally added these access=private tags. All the posted 
driveways I've mapped are now tagged identically to every other 
driveway. Lesson learned: I should map the posting distinction more 
explicitly in the future, such as using traffic_sign=*. But if I map an 
adjacent traffic_sign=* feature while leaving the way's access=* set to 
the same value as every other driveway, that still strikes me as a bit 
of a trap for data consumers. Access is too important to simply coin an 
ad-hoc tag for without having data consumers on board.



If you object to pink dots on driveways, I'd say that access=private is
what is expected so the renderer should be fixed to not show that and
show other access values.


The status quo ante had been that most driveways lacked an access tag. 
Unlike with highway=residential or whatnot, I don't think there was much 
of an end user expectation that driveways in general would indicate 
restricted access. I don't think people were likely to have stumbled 
upon these driveways just because they lacked a dotted pattern on a map.


Meanwhile, from a routing standpoint, these blanket access=private tags 
are problematic. For example, OSRM tries to snap an origin or 
destination waypoint to a roadway to avoid returning no route. [1] 
However, this snapping only takes the road topography into account and 
can unfortunately snap across barriers such as fences, ravines, and 
railroad tracks. Overuse of access=private exacerbates this problem by 
forcing the router to snap even greater distances to a public road. [2] 
Most property owners would prefer that you use their driveway as you 
leave their property instead of making a beeline dash for the nearest 
public road across their petunias.


I favor stripping the access tags from the Amazon-tagged driveways (not 
all driveways) and starting over. Going forward, we can document the 
reasons for a driveway's access tag on a case by case basis by mapping 
things like gates and no trespassing signs.



A further issue we haven't talk about:

  How much detail is ok on residential property, from a privacy
  viewpoint?  Is mapping of "no trespassing signs" going too far?

We show structures, and we show driveways.  These don't feel invasive
given imagery.  They are very useful for navigation, particularly with
long driveways.   We don't map much else.

To me, marking individual driveways about whether they have a no
trespassing sign or not, is a bit much.  It feels a bit dangerous, in
terms of getting it wrong and expectations.  Yes, you can see them from
the road, but still.

I also don't think it's all that useful.  When you are going somewhere,
you need to pay attention, regardless of the map.  And you know why you
are going, and if you have some kind of permission, and we are not going
to automate that.


No trespassing signs seem more useful to map than front yard flagpoles 
and backyard swimming pools, but I map those already.


A couple scenarios to consider:

* An office building has a small parking lot and a sign at the driveway 
that says, "Private property -- Enter driveway by appointment only". [3] 
To me, this driveway would be a natural case for access=private. One 
could argue that it's customers who would be making the appointments, 
thus access=customers on both the driveway and parking lot, but that 
would be indistinguishable from the great many strip mall parking lots 
with "Customer Parking Only" signs that we tag as access=customers. As 
far as I know, no router uses the accessibility of a parking lot to 
decide whether the driveway that leads to it is also accessible.


* A homeowner is the victim of a county GIS database that erroneously 
extended their narrow driveway up a hill to connect to a large 
subdivision. Apparently large vehicles have attempted to use the 
driveway as a shortcut, only to have trouble backing out. Before the 
owner installed a gate out of desperation, they tried posting a no 
trespassing sign. They also tried repeatedly to edit OpenStreetMap, 
going as far as to delete their driveway, thinking it would influence 
drivers. [4] I think it's safe to say that any owner who posts a no 
trespassing sign would appreciate OSM respecting that sign. Granted, it 
would be less clear-cut if the sign bears a facetious message. (There 
are many examples in Google Image Search.)


[1] 
https://blog.mapbox.com/robust-navigation-with-smart-nearest-neighbor-search-dbc1f6218be8

[2] https://f.zz.de/posts/201910152010.access_private_on_driveways/
[3]

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-08-22 Thread Minh Nguyen


Vào lúc 11:55 2020-08-22, Volker Schmidt đã viết:



On Sat, 22 Aug 2020 at 19:31, > 
wrote:

I've
even encountered signs that threaten people who attempt to use their
driveway as a U-turn.


This seems to be the rule in England, UK. When I took my driving license 
many years back (1978) there, I remember that the driving instructor 
reminded me explicitly that that a U-turn backing the car into a 
driveway would mean my failing the test (I am from Germany where that is 
the preferred approach as it's safer than the the 3-point-turn which 
they tought me in England).
So there are places in the world where the driveways are implicitly 
"private" without any additional sign.


I was referring to signs that threaten that the owner will come out and 
pull a gun out on you if you back into the driveway. Fortunately, these 
signs are relatively rare in the U.S. But they are quite different than 
the usual rule against backing into a driveway that would fail a driving 
test, hence my preference for making this distinction in the database.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Potential Mechanical Edit to remove access=private from Amazon Logistics driveways in NH

2020-08-22 Thread Minh Nguyen


Vào lúc 12:01 2020-08-16, Alex Weech đã viết:

Hello all,
I'm planning a mechanical edit to remove the access=private tag that 
Amazon Logistics mappers added in New Hampshire. They originally added 
the tag without using street-level imagery to look for no trespassing 
signs, and they made so, so many mistakes. The group has finally yielded 
to the community feedback to stop adding the tag, and I want to quickly 
remove as many of the instances as possible. I believe it is worthwhile 
to remove the tag because it is important to distinguish between houses 
that accept visitors and those that do not, and currently access=private 
is the best way to indicate it, but it is diluted by all of the Amazon 
Logistics driveways. Ihave written up my proposal here 
. 
It's pretty much copy-paste from the project with the same goals for 
neighboring Maine, and that one has been well received, so I am hoping 
this one is well received as well. (I'd be in favor of a nationwide 
greenlighting of such projects, but since that hasn't happened yet I'm 
doing my due diligence contacting the community ).

Sincerely,
Alex (aweech)


I'm glad to see efforts toward distinguishing between posted and 
unposted driveways. I've encountered plenty of no trespassing signs on 
driveways over the years, some of them more menacing than others. I've 
even encountered signs that threaten people who attempt to use their 
driveway as a U-turn. So I'd imagine this distinction would be 
beneficial to any logistics company as well.


The proposal says it'll be limited to features edited by Amazon 
Logistics users, which is a good idea. Since there may have been 
turnover on the team since the first driveways were mapped, ideally 
you'd include former team members too. Unfortunately, 
 doesn't list 
former team members, but you could comb through the page's revision 
history if you wanted to be extra thorough.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Underground railways, indoor mapping, and overlapping features

2020-05-15 Thread Minh Nguyen


Vào lúc 10:28 2020-05-05, Michael Reichert đã viết:

Using the same nodes (like mapping to adjacent landuse polygons) breaks
routing because routing engines would allow trains to switch between the
levels. Using duplicated nodes at the same location is likely to trigger
quality assurance services and therefore mappers trying to "repair" it
by merging them. Using two identical geometries in straight sections
with nodes at different locations, will likely provoke the same as
duplicated nodes.


Just as a double-decker bridge requires layer tags on each deck, so 
would a double-decker subway tunnel, whether the ways are coincident or 
offset by some arbitrarily small amount. Adding layer tags, as suggested 
in [1], would likely suppress any validator warnings about coincident 
ways. But it's true that mappers could still be confused by coincident 
ways if editors don’t provide intuitive ways to navigate among them.



Regarding option 2: GraphHopper assembles its routing graph by relying
on the node IDs in OSM. It would not suffer from using this option but I
doubt that it is safe for the future. If OSM adopts to drop its 64 bit
node IDs in favour of the location (32 bit latitude + 32 bit longitude),
such cases will cause difficulties.


This is an intriguing notion I had not come across before. Has it ever 
been seriously considered? It seems to me that distinguishing nodes only 
by their coordinates would be tantamount to merging all coincident nodes 
everywhere, which we probably would never allow as part of a mechanical 
edit, much less a history-less database schema update. (For one thing, 
everyone who dislikes joining borders to roadways would be appalled to 
see just about every CDP boundary consistently joined that way.)


[1] https://lists.openstreetmap.org/pipermail/talk-us/2020-May/020015.html

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Geocoding for Individual States.

2019-09-19 Thread Minh Nguyen


On 2019-09-15 09:50, David Ankin wrote:

Hello all,

I was hoping to hear what worked for other folks who were trying to get 
a local nominatim instance installed for house number level geocoding in 
the US (or, in my case, a particular state). I setup 3.3 nominatim by 
checking out from the branch, and downloading PA excerpt from planet.osm 
from geofabrik, and used import-full.style.


The end result for me was that i could look up streets, but not house 
numbers. some house numbers were present, but most houses were missing. 
I am trying to import TIGER data next, to see if that works. But it 
really should be in the regular planet file, in theory, right? without 
having to rely on an out-of-band data source.


TIGER roads and boundaries have been systematically imported into OSM, 
but TIGER addresses (house numbers) have not. To the extent OSM contains 
any addresses in Pennsylvania, they were either entered manually or 
imported separately (possibly from TIGER but much more likely from 
another government source).


Local mapping communities across the U.S. are working on imports that 
will eventually improve address coverage. In the meantime, I've heard 
that the main Nominatim instance does pull in address ranges from TIGER 
as a fallback. You might also take a look at pulling in data from 
OpenAddresses .


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Mapping rail trails

2019-07-11 Thread Minh Nguyen via Talk-us


On 2019-07-11 17:27, Greg Troxel wrote:

Thanks for the nice summary.  I have one minor issue to raise a question
about:

stevea  writes:


As for rail trails, very nice work, Richard!  Rail trails are usually
classified as local (lcn) if they are for cyclists, although some are
sponsored at a state-level: these are properly tagged rcn (regional
generally means "state-level" in the USA).  I don't know this for sure
(Minh?) but I might imagine that the C Canal Trail over and above
the USBR 50 relation might be properly tagged rcn instead of lcn.
Such decisions are best determined with more-local consensus by
Contributors who are familiar with the local / state statutes which
define the route.  The Bicycle_Networks wiki describe (MUTCD-standard)
signage for NUMBERED routes which disambiguate the network-level tag
that should be used.  For routes which happen to be signed
on-the-ground as non-governmental (non-MUTCD-standard signage), please
consider these on a case-by-case basis, starting (as Richard did) at
the local (lcn) level.  If network=rcn is actually a better value,
this is likely to emerge with strong consensus at a more-local (state)
level within OSM.


The notion of state sponsorship is interesting, and there is the aspect
of a state bicycle route number, akin to a state numbered highway.  I
can certainly see that being rcn.  Then there is the aspect that in MA,
most things called "rail trails" end up getting built with state funds,
and built to state construction standards, both avoiding the towns
having to say and making the resulting trail much more costly (but nicer
in some ways).  These trails tend to have names, like "Nashua River Rail
Trail", "Assabet River Rail Trail", "Bruce Freeman Rail Trail", but they
don't have a "MA Bicycle 29" designation, or if so nobody knows that.

Most of them go over fairly short distances; the Nashua River one is
about 12 miles and is in the towns of Ayer, Groton, Pepperell, MA and a
bit in Nashua, NH.  To me, that feels local in scope rather than
statewide, so I'd want to see it as lcn.  The fact that it was funded
with state rather than local money doesn't seem important.  (Actually,
state money pays for local roads in complicated scheme.)

Now, if the Central Mass Rail Trail were somehow complete in a Cambridge
to Northhampton sort of way, or even half of that, it's obviously rcn,
regardless of who organizes it.

This gets fuzzy.  Perhaps, in a US-centric northest-centric way, it
feels like rcn is 100 km.

I'm not sure this ended up being useful.  I think I more or less agree
with where I think you ended up, saying that other than federal and
state numbered routes, all routes are lcn, unless there is really clear
local consensus that they are very important and of state-level scope,
in which case they can be promoted to rcn.


I think this speaks to the utility of the cycle_network [1] and operator 
tags. The network=lcn/rcn/ncn/icn tagging scheme may've sufficed in the 
early days in the UK, but increasingly more nuance is needed on both 
sides of the pond.


As with the network tag on bus routes, what's important for both network 
and cycle_network is that the route is intended to form part of a 
coherent *network* (almost like a brand, but not quite). A given route's 
actual length, connectivity, build quality, or ownership on its own is 
perhaps less important, but consistent signage or ownership is how an 
organization might establish a set of routes as a network.


Long ago, Ohio's transportation department set up a state system of 
lettered bicycle routes along rural roads, which no practically no one 
knows about. But local bike advocacy groups also coordinated on a system 
of numbered routes over state- and county-maintained trails.


Over time, Dayton-area counties took up the task of signposting the 
unofficial numeric routes with the same kind of signage as the official 
statewide system. Then adjacent counties up and down the state followed 
suit, to the point that the numbered routes are the state system for all 
intents and purposes. A few years ago, all the routes in the state were 
renumbered, something that has happened many times to state road route 
networks. [2] But IIRC it was carried out by trail managers and 
coordinated by regional planning commissions rather than the state.


The numeric network includes some spur routes that are shorter than many 
city-maintained local routes but bear state route signage, such as route 
3E. [3] The alphabetic and numeric routes alike are tagged with the same 
cycle_network=US:OH, though the operator tag can be used to distinguish 
if necessary. It's all a bit chaotic, but hey, that's reality.


[1] https://wiki.openstreetmap.org/wiki/Key:cycle_network
[2] 
https://en.wikipedia.org/wiki/Category:Highway_renumbering_in_the_United_States

[3] https://www.openstreetmap.org/way/128492582

--
m...@nguyen.cincinnati.oh.us


___
Talk-us mailing list

Re: [OSM-talk] Bot edits on the OSM wiki

2019-02-24 Thread Minh Nguyen


On 2019-02-24 11:18, Christoph Hormann wrote:


Yesterday was the first time (that i am ware of at least) a bot has
edited an OSM wiki page on my watchlist - with today and yesterday
combined 17 edits of tag and key pages spamming my watchlist feed.


I'm not sure if it's on by default, but 
 has a "hide 
bots" option toward the top, also accessible from 
. 
If you enable the option, the bots can't bother you unless you look at 
an individual page's edit history.


If you prefer to receive your watchlist notifications by e-mail, you can 
go to 
 
and uncheck "Email me also for minor edits of pages and files" (which is 
unchecked by default). The bot edits in question were all marked as 
minor edits, since they had little or no effect on the rendered wiki 
pages. It's probably a good idea to uncheck this option anyways; I'm 
sure I'm not the only human editor guilty of spotting my numerous typos 
only after posting a comment. :-)



I know that to some this likely seems a fairly radical attitude - the
popularity of platforms like facebook and twitter where algorithms
interfere with human communication extensively is testimony to the fact
that a lot of people don't have the same concern.  I am aware of this
but my position none the less remains as described.


Far from the opaque algorithms found on social media sites, this bot is 
merely performing a regular expression-based find-and-replace, much as 
one would do in JOSM. There would have to be a very good reason for a 
more sophisticated bot to run on the OSM wiki. Hopefully the wiki never 
becomes the target of such vandalism and spam that the likes of 
Wikipedia's ClueBot would be required.


But maybe a bot that replaces American English with British English? 
April Fool's isn't that far away. :-P



Possible solutions to the problem would IMO be:

[...]
* create a bot free fork of the OSM wiki and maintain the original OSM
wiki as a zone where bots are allowed.


So far it looks like most of this bot's edits have been confined to the 
data items namespace, which makes sense -- bot edits are far less 
error-prone in that namespace than when dealing with MediaWiki syntax. 
At some point, the infoboxes in the Tag: and Key: namespaces will be 
able to get all their structured data from the data items, which will 
largely eliminate the need for this bot to touch the tag description pages.


On a historical note, TTTBot [1] used to be quite active in the main 
namespace. Its job was to keep certain tables synchronized with the 
infoboxes on software description pages. The bot went dead at some 
point, so the wiki wound up with increasingly outdated information about 
things like version numbers and prices. [2][3] The system was always 
quite fragile, and MediaWiki's template syntax is intimidating even to 
programmers, so I'm glad we're moving structured data to data items 
instead of relying on carefully handcrafted template calls.


[1] https://wiki.openstreetmap.org/wiki/User:TTTBot
[2] https://wiki.openstreetmap.org/wiki/Comparison_of_Android_applications
[3] https://wiki.openstreetmap.org/wiki/Comparison_of_iOS_applications

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] The San Jose / Santa Clara border

2019-01-28 Thread Minh Nguyen


On 2019-01-28 12:40, OSM Volunteer stevea wrote:

(Lengthy reply alert)
Hi Minh:

Thanks for your (always thorough and well-researched) pointers and history — though I don't recall 
"impressing LAFCO" upon you, I did mention it in the context of admin_level, so, OK, 
whatever!  Good for Santa Clara LAFCO for publishing municipal boundaries into the PD.  I am again 
thankful we live in a state with excellent public data in the PD along with our "sunshine 
laws."

I like that you made Seven Trees an admin_level=10 for reasons you did, even as you've 
described other SJ neighborhoods as "amorphous" (exactly the right word, imo!)  
I wouldn't have noticed had you not sent me links [1].

"Urban islands as a LAFCO high priority to streamline" is something I've never heard of before.  Notwithstanding the 
letter LAFCO sent City of San José nearly eight years ago [3], I believe it is the City of San José itself which "serves as 
the authority on" its own municipal boundary.  LAFCO might have something to say (keeping accurate maps / GIS data, for 
example) about all cities in Santa Clara County, but I don't think anyone contends that LAFCO doesn't define municipal 
boundaries, the cities themselves do.  Indeed, LAFCO's letter says it can "encourage" annexations (of islands) and 
waive its fees (to incentivize a "streamlined process" for islands 150 acres or less) but it cannot force a city to do 
so, whether this is a "high priority" for the LAFCO or not.

Using link [4] and blending with the instant topic (which I volunteered to remedy), I examined the five pages of City of Santa Clara.  The first four 
(pages 45-48) are "islands" which share a boundary with City of San José (the fifth is an island solely inside of the City of Santa Clara). 
 None of these involve the area around the airport / Westfield Valley Fair, which was Andy Townsend's "area of concern," prompting me to 
answer that I'd take a look.  (SC05, page 48, is pretty close, but is north of the airport and involves a creek edge near Trimble and Orchard).  
Those four "islands" probably could be used to (rather crudely) "hand draw modify" the Santa Clara City Limit boundary in OSM 
(relation 2221647) but it isn't clear to me how what these maps define as Urban Service Boundary is or isn't the actual city limit boundary for Santa 
Clara.  As I think about it, the identification of these four islands (the fifth might become an "inner" member of that relation) in this 
document COULD be used to exclude these islands from the City Limit, but I'm not sure that is accurate (it likely is, I'm simply not sure).  So while 
these resources might qualify as "interesting," I don't find them wholly relevant to what I volunteered to do "near the airport."

However, links [5] and especially [6] yield dense, recent, tasty data.  Having used 
ArcGIS layers before like this (largely while mapping to fix TIGER rail), I can set a 
basemap of OSM while viewing these data.  Doing so allows me to find where there are some 
relatively minor differences, so I elected to fix these, "manually" using JOSM.

These (minor) changes were along the "grass edge" NW of the 101-Trimble interchange, westerly to the UP Coast 
Subdivision rail bridge crossing 101, southerly to just north of Central Expressway (not south, a significant change 
making OSM's representation of CE W of Trimble/De La Cruz to the rail bridge now in Santa Clara, not San José).  This 
continues easterly across Trimble into the airport, as far as Taxiway Y, includes better-traced (though likely not 
perfectly accurate) rectangular and triangular areas of northern portions of runways and taxiways, south along De La 
Cruz and excludes Memorial Cross Park (in San José, not Santa Clara).  The barrier=fence had to be node-by-node unglued 
from the city limit (but kept glued to the parking lot) to be better characterized as "along Martin Avenue" 
(and so was), SE on Martin Avenue (with some "jogs") to a bit further SE on Aviation Avenue, southerly (with 
"jogs") to Campbell Avenue near Stephen Schott Stadium.

 From there, the boundary needed to be moved easterly by about 10 meters, so it 
was, past Sherwood and along Portola Avenue.  Adjustments were made to better 
align with The Alameda, past Morse and Idaho and to I-880, where a 90-degree 
westerly boundary continues to Newhall and Monroe, where as it follows the 
southern boundary of Santa Clara Mission Cemetery, it is correct (enough for 
now).

The ways I changed have IDs 166659029 and 97341711 (recently reverted by Andy Townsend), 
part of the Santa Clara (city) municipal boundary relation.  I believe this is moderately 
better, which is "moderately better."

SteveA


Thanks for making these improvements! I've added an item to our local 
to-do lists for refining the rest of the city boundary as needed:


https://github.com/codeforsanjose/OSM-SouthBay/issues/19
https://wiki.openstreetmap.org/wiki/Special:Diff/1782398

--
m...@nguyen.cincinnati.oh.us

Re: [Talk-us] The San Jose / Santa Clara border

2019-01-28 Thread Minh Nguyen


On 2019-01-26 17:13, OSM Volunteer stevea wrote:

While I don't know quite who to call, exactly, if somebody wants to "release to me" ODbL-compatible 
data which need to be harmonized with what are now in OSM, I'll volunteer to be the "nexus of citizen 
entry" to assure they find their way into our wonderful map.  Send me a pointer to the data, assure me 
they are ODbL-OK and I'll "merge" these into OSM.


Any help maintaining San José’s sprawling, unwieldy city limits would be 
most welcome. A few years ago, I incorporated the Seven Trees 
annexations into San José [1] but didn't go much further to correct the 
crude, outdated data we imported from TIGER.


Thankfully, over the years, Steve has impressed upon me the importance 
of Santa Clara County's Local Agency Formation Commission (LAFCO), which 
serves as the authority on municipal boundaries in the county and 
conveniently releases all its work into the public domain, by virtue of 
being a state agency. The commission's Island Annexation Program page 
[2] links to a memorandum from May 2011 [3] and an atlas from 2015 [4] 
that include detailed maps of the remaining islands.


The county planning department handles GIS for the LAFCO. They have an 
ArcGIS application and layer indicating all the city and town limits in 
the county. [5][6] The planning department is also subject to state 
sunshine laws regarding the public domain.


[1] https://www.openstreetmap.org/changeset/32278082 and 
https://www.openstreetmap.org/changeset/32402544
[2] 
https://www.santaclaralafco.org/specialdistricts/island-annexation-program
[3] 
https://www.santaclaralafco.org/file/IslandAnnexations/Item10A_SanJose.pdf
[4] 
https://www.sccgov.org/sites/dpd/DocsForms/Documents/UrbanIslands_2015_Atlas.pdf
[5] 
https://sccplanning.maps.arcgis.com/home/item.html?id=35968e7124f04807bd1ed70b31fab4fd
[6] 
https://services2.arcgis.com/tcv2cMrq63AgvbHF/ArcGIS/rest/services/PlanningOfficeDataService2/FeatureServer/2


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Forest Routes

2018-11-28 Thread Minh Nguyen


On 2018-11-28 06:49, Martijn van Exel wrote:

On Wed, 28 Nov 2018 02:07:45 -0800
Minh Nguyen  wrote:


On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:

When I map these roads I include the FS number (just the number)
as a ref, since that is how they are signposted in the field.


I think the ref tag on the ways should have a prefix and not just
consist of a bare number. Otherwise, it's just as ambiguous for
data consumers as the (123) refs all over New Jersey, since the
U.S. doesn't have a highway tag that corresponds one-for-one with
forest routes.


(I hit send too soon.) Lots of shields show only the number and no
prefix, such as the U.S. Route shield, but we still use the "US"
prefix anyways.

Data consumers really should be using route relations instead of ref
tags on ways whenever possible. Some ambiguity is unavoidable on way
refs, which IMO should reflect what's on plain-text signage or in
publications. If one thinks of the way refs as a compatibility shim,
then "FS" doesn't seem unreasonable as a prefix.


I think you are right. It would be good if we can arrive at a common
prefix and document it on the wiki. 'FS' makes sense. Perhaps even a new
page dedicated to roads that are maintained directly by federal agencies
(NPS, USDA, others?) would make sense. I'd be happy to help set it up.


One page already documented an "NFH" prefix on ways and 
network=US:NFSR: on relations. [1] I think I added that entry to 
the table after seeing it on some forest routes in California. [2] But 
I've changed it to an "FS" prefix since so many more ways are tagged 
with that prefix. [3]


[1] https://wiki.openstreetmap.org/wiki/United_States_roads_tagging/Routes
[2] http://overpass-turbo.eu/s/E5V
[3] http://overpass-turbo.eu/s/E5W
--
m...@nguyen.cincinnati.oh.us



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

Re: [Talk-us] Forest Routes

2018-11-28 Thread Minh Nguyen


On 2018-11-28 01:57, Minh Nguyen wrote:

On 2018-11-20 08:57, Martijn van Exel wrote:
When I map these roads I include the FS number (just the number) as a 
ref, since that is how they are signposted in the field. 


I think the ref tag on the ways should have a prefix and not just 
consist of a bare number. Otherwise, it's just as ambiguous for data 
consumers as the (123) refs all over New Jersey, since the U.S. doesn't 
have a highway tag that corresponds one-for-one with forest routes.


(I hit send too soon.) Lots of shields show only the number and no 
prefix, such as the U.S. Route shield, but we still use the "US" prefix 
anyways.


Data consumers really should be using route relations instead of ref 
tags on ways whenever possible. Some ambiguity is unavoidable on way 
refs, which IMO should reflect what's on plain-text signage or in 
publications. If one thinks of the way refs as a compatibility shim, 
then "FS" doesn't seem unreasonable as a prefix.

--
m...@nguyen.cincinnati.oh.us



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

[Talk-us] Population during mandatory evacuations

2018-11-12 Thread Minh Nguyen


(Crossposted to the talk-us and tagging lists.)

Due to the ongoing Camp Fire in Northern California [1], the place POI 
for the town of Paradise got tagged with population=0 before the change 
was reverted. Following some discussion about this changeset in OSMUS 
Slack [2], I started a discussion on the wiki about preferring more 
stable population figures over supposition about temporary 
circumstances. [3]


[1] 
[2] 
[3] 



--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Possible roundabouts?

2018-09-30 Thread Minh Nguyen


On 2018-09-06 23:27, Marian Poara wrote:

40.5234202, -111.8762446


Despite its size, the standard roundabout rules normally apply on these 
decorative or traffic calming circles -- there simply isn't enough room 
for a driver inside the circle to yield to a driver entering the circle. 
So junction=roundabout is still justified.


This roundabout is small enough that OSRM classifies it as a "roundabout 
turn", but only if the circular way is tagged junction=roundabout. 
Otherwise, you'd get confusing guidance like "Turn right, then turn right".



35.8497728, -86.4547473


This is definitely a roundabout, to be tagged junction=roundabout. Bing 
imagery shows a yield sign at each of the four approaches. Even without 
street-level imagery, you can see pedestrian islands in the middle of 
all four approaches, a hallmark of modern roundabouts in the U.S.



42.6811136, -73.6987507


This could either be considered a roundabout (junction=roundabout) or a 
turning loop that happens to have two driveways sprouting out from it. 
Either way, given the width of the loop, the loop is one-way.


Incidentally, it's kind of awful that a four-lane road would abruptly 
end in a one-lane turning circle without any signage at all.



40.22109, -76.874981


This is ambiguous. Based on the road width alone, you wouldn't be able 
to tell that the circular road is even one-way. But in Mapbox imagery, 
you can clearly see from the wear on the pavement that drivers are 
treating it like a one-way road, only turning right onto it from each of 
the three approaches. As long as it's a one-way road, it would most 
likely be a junction=roundabout as well.


And if we have OSC or Mapillary street level 
images and it is confirmed that they don’t have any roundabout sign? In 
many residential areas (but not only), there isn’t any one way sign 
inside the small “roundabouts” and it seems that both directions are used.


In residential areas, you'll often find cases where the rules are 
considered obvious to drivers and the speed limit isn't high enough to 
warrant the additional cost of regulatory signage. But that shouldn't 
change how we use tags like junction=roundabout that significantly 
affect guidance instructions.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Proposition for changing the common name tag

2018-08-20 Thread Minh Nguyen

On 2018-08-16 09:51, Daniel Koć wrote:

Hi,

I wanted to let you know about proposed change in tagging the name of 
USA and I seek for the feedback about it - see the proposition here:

https://forum.openstreetmap.org/viewtopic.php?id=63384 

There are arguments to be made for either name, but `name=United States` 
`official_name=United States of America` seems like a perfectly 
common-sense way to tag it.

I had always assumed it was tagged `name=United States of America` 
because of the vastness and blankness of this country in the 
openstreetmap-carto style at zoom level 3 in Web Mercator projection. 
(Canada needs a longer name, clearly.) But that would be mapping for the 
renderer, so by all means shorten it.

Some of the `name:*` tags on the U.S. relation seem to have taken after 
`name` by unnecessarily including the equivalent of "of America". For 
example, `name:es=Estados Unidos de América` and `name:fr=États-Unis 
d'Amérique`. By contrast, there are few `official_name:*` tags on the 
U.S. relation. These tags might need to be reviewed -- perhaps checked 
against Wikipedia article titles -- to ensure that they too follow 
common practice in the respective languages.

On 2018-08-16 10:33, Jack Burke wrote:
> I am opposed to this suggestion, because there are two countries called
> "United States" in North America: the United States of America, and the
> United States of Mexico.

To be pedantic, the official name in Spanish is "Estados Unidos 
Mexicanos", rather than "Estados Unidos de México". So the official 
English name is "United Mexican States", not "United States of Mexico".

Even if Venezuela hadn't changed its official name from "United States 
of Venezuela" (Estados Unidos de Venezuela), I'd still stick to "United 
States" for the U.S., because it wouldn't cause any confusion between 
the two countries. It would be very different if someone were to propose 
`name=America`, reasoning that it's the most common name.

--
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Cardinal directions on highways & foreign languages

2018-03-13 Thread Minh Nguyen


On 2018-02-27 19:22, Angela Morley wrote:
I've come across an issue with the current implementation of cardinal 
directions in roles of relations. In certain areas of the world, roles 
are being used to determine the cardinal direction of a way in 
accordance with the AASHTO requirements, however those locales change 
the official name of the cardinal direction to the name of the direction 
in their local languages on road signage. Examples include highways in 
Puerto Rico and Quebec.


Should the tags north, south, east, and west be assigned in these 
locations according to the official language used on the road signs for 
those locations (precedent exists like this with Key:name), or should 
they remain English worldwide, regardless of country?


Given that these values are lowercase, they're best thought of as 
machine-readable values rather than freeform, human-readable values. So 
they should remain in English, like any other formal tag value, 
regardless of the sign's language. Taginfo shows that this has been the 
case so far in OSM:


 (tags on 
unidirectional child route relations)
 (roles on 
bidirectional route relations)


This problem has come up in a bug report I was filing with OSRM where 
they are currently just spitting out values like $north directly into 
the end user instructions because they don't know what the best way to 
handle the problem is yet. I had asked for it to be rendered as North, 
however the question of internationalization came up, and was so valid 
and pressing I thought it prudent to start a conversation about the 
topic. ( If you're curious, the original bug report: 
https://github.com/Project-OSRM/osrm-backend/issues/4918 
)


The OSRM library currently leaves it up to client code to replace the 
token with something more presentable. For example, the Mapbox 
Directions API currently replaces these $north tokens with English 
cardinal directions. It's a known issue that the API doesn't use French 
and Spanish cardinal directions in Québec and Puerto Rico, respectively, 
even though the rest of the instructions can be localized.




(Incidentally, this stretch of roadway is a concurrency of US 29 North, 
US 460 East, and US 501 South.)


Note that the behavior described above applies only to cardinal 
directions inserted based on route relations. However, most of the time, 
when you encounter a numbered route in OSRM's guidance instructions, 
it's due to a human-readable cardinal direction in the destination:ref 
tag, which is customarily written in the local language. So in Québec, 
it's currently possible for OSRM-based navigation software to announce 
an on-ramp onto "A-5 Nord" and then announce a merge onto "A-5 North".


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-15 Thread Minh Nguyen


On 15/10/2017 05:39, Michael Reichert wrote:

And even if detecting disambiguation pages in Wikipedia would miss too
much of them, you could use Wikidata to check if the Wikipedia page the
Wikidata item points to is a disambiguation page according to Wikidata?

While wroting the paragraph above, I wondered how the status of a
Wikipedia page a Wikidata item links to is maintained. Is there a bot
updating them every hour in Wikidata? If there is no such bot (or it is
not running every minute or hour), there is no need for wikidata=* tags
in OSM to find wikipedia=* tags pointing to disambiguation pages because
you could get the status of a Wikipedia page by parsing the Wikipedia
page itself.


When a Wikidata item is modified to link to a Wikipedia article (or 
Wikivoyage article etc.), the Wikipedia article automatically links back 
to the Wikidata item. This is a software feature made possible because 
Wikipedia and Wikidata are colocated in the same database cluster. No 
bots are involved; this is unlike the process by which interwiki links 
used to be maintained before Wikidata was introduced.


When a Wikipedia article is renamed, it does temporarily get detached 
from the Wikidata item because the task of updating the Wikidata item 
falls to a process that runs asynchronously on a job queue. It isn't 
possible for OpenStreetMap, as an external site, to automatically update 
its wikipedia tags via the same mechanism. However, in principle, one 
could write a bot that consumes Wikipedia's or Wikidata's recent changes 
feed, looking for features to update. I'm not personally proposing to 
run such a bot, to be clear. And one of the benefits of wikidata tags is 
that such a bot would decrease in necessity over time, since Wikidata 
QIDs are more stable.


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] Could we just pause any wikidata edits for a month or two?

2017-10-11 Thread Minh Nguyen


Great questions. I've attempted to answer a few of them below:

On 03/10/2017 09:56, Christoph Hormann wrote:

* To what extent has there been information transferred systematically
from Wikidata and Wikipedia to OSM based on wikidata ID references
(like adding names in different languages).  As others have explained
this would be legally problematic and it would be important to know how
common this is.


I agree that there are questions about OSM's acceptance of labels and 
statements copied from Wikidata, though I would've expected this 
phenomenon to be at least as common with Wikipedia long before the 
introduction of the wikidata tag.


Years ago, there was a campaign to add as many translations of country 
names as possible, using Wikipedia as the primary source. [1] A map 
renderer that uses these translations would logically want translations 
or transliterations for as many cities as possible, but my impression is 
that the OSM community would frown on such a massive expansion in city 
name transliterations. Instead, we can point data consumers to Wikidata 
as a source for this data.



* How stable is the identity of what can be found under a certain
Wikidata ID.  As mentioned there are cases where Wikidata aggregates
several concepts under one ID (like an administrative unit and a
populated place in case of cities/towns).  Would it be possible that
this changes?  If yes, would the original ID be re-purposed or would it
cease to exist?


To the extent that an administrative unit and populated place are 
considered separate entities, as they are for some kinds of places, 
Wikidata ideally maintains separate entities for each. The reality is 
less clear-cut, since much of Wikidata's original data on geographic and 
political entities comes from Wikipedia, which generally doesn't make 
such distinctions at the article title level. The Wikidata project aims 
to eventually create separate entities for every concept that Wikipedia 
has traditionally conflated inside the same article. Thus Wikidata 
maintains a separate entity for each Pokémon species, whereas the 
English Wikipedia combines them all into a few list articles. [2][3]


If an administrative unit or populated place (or both) ceases to exist, 
the QID remains valid, but a statement or qualifier is added to indicate 
"former" status, much like OSM's lifecycle tags (disused etc.). An 
entity may be redirected under some circumstances. For example, if the 
Wikidata community discovers that two entities are duplicates, referring 
to exactly the same concept, an editor will manually blank one in favor 
of the other, and a bot will create a redirect automatically. [4]


Many of the duplicate entities were created as a result of incorrect 
linking between Wikipedia article translations at the time Wikipedia 
article titles were being imported into Wikidata. If someone had 
translated the article "Pumpkin" from English to Pennsylvania German but 
neglected to link the English article to the Pennsylvania German one, 
Wikidata might've wound up with two entities, one linking to many 
languages including English, the other linking to only Pennsylvania 
German. Most likely the latter entity would end up redirecting to the 
former.


The English Wikipedia sees a couple dozen geographical articles renamed 
each day. [5] This is a rough estimate based on articles tagged with 
geographical coordinates. I don't know how many of these articles are 
the target of wikipedia tags in OSM -- I think that would require Yuri's 
SPARQL tool.


But the important thing to note is that a redirect on Wikipedia may not 
remain a redirect for long: editors may decide to repurpose the redirect 
page for a disambiguation page or perhaps an article on a subtlely 
different topic. If that happens, an OSM data consumer would have to 
trawl through article history to determine which article each wikipedia 
tag really meant to refer to. By comparison, since integers are cheap, 
Wikidata entities don't tend to get repurposed the way Wikipedia article 
titles do, so even a stale QID can be traced to relevant data pretty easily.



* What is the qualification of Wikidata for having its IDs in OSM (both
for wikidata=* and X:wikidata=*)?  Is there a particular objective
criterion that qualifies it?  Would there be other external IDs that
would also qualify under these criteria?  Is there a limit in the
number of different external IDs OSM is going to accept?


There are at least several other kinds of IDs that have been added in 
large numbers in the past. Off the top of my head, there are the various 
ref schemes used in conjunction with the heritage tag, GNIS feature IDs 
associated with an import of POIs in the U.S., and of course regulatory 
IDs such as ICAO/IATA.


Far from opening the floodgates to external IDs, Wikidata gives us the 
ability to limit external ID tagging. Consider that Wikidata lists seven 
different external identifiers for Hamilton County, Ohio, United

Re: [Talk-us] I 85 Express Lane (Atlanta, Georgia)

2017-09-24 Thread Minh Nguyen


On 22/09/2017 09:46, Jack Burke wrote:

My questions are:

* Should this lane be drawn as a separate way?  Legally, you cannot 
enter or exit the lane except at the designated sections, so drawing it 
separately makes things simpler for routers.  If it's drawn separately, 
a pair of motorway_link roads would need to be added at several places 
(the dashed-stripe sections).  The Lanes wiki page[4] seems to say that 
it should be drawn separately:  "If one or more lanes of the road are 
restricted to high-occupancy vehicles (typically vehicles with 2+ 
occupants, although this varies by jurisdiction). Most useful if 
entrance/egress is permitted at any point along the route; if entering 
or exiting the HOV lane(s) is only permitted at certain locations, 
modeling the HOV lane(s) as separate ways is preferable."  (Even though 
that says HOV, the same reasoning appears relevant for toll.)  Does 
everyone concur with this construction?


I might be inclined to map the lane as a separate way, but only because 
I don't know of any routers that currently recognize the change:lanes 
tag. [1] Either way, it makes sense to treat HOV and toll lanes similarly.


[1] https://wiki.openstreetmap.org/wiki/Key:change

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Uploading sidewalks in San Jose, California, US

2017-09-20 Thread Minh Nguyen


On 19/09/2017 23:44, OSM Volunteer stevea wrote:

Vivek Bansal <3viv...@gmail.com> writes:

We are using the San Jose data which has an ODbL compliant license (and any 
government data in California has the same).


I'm following the San José discussion and don't wish to get too technically legal:  I am not an attorney, though I have paid attention to the legal 
situation with state (of California) produced geo data and how our state "Open Data/Open Records" laws plus two fairly recent California 
Supreme Court decisions make state-published data roughly if not essentially equivalent to public domain.  These legal circumstances taken together 
with OSM's ODBL result in "be free to use the data, OSM, they are ODbL compliant."  It isn't exactly correct to use the word 
"license" in how California publishes geo data.  It IS correct that such data are "ODBL compliant."  It isn't a license that 
grants this, it is case law or stare decisis (Latin for "let the decision stand") which confirm such data published by the state comply 
with both statutory law (California Public Records Act, CPRA) and California's state constitution.  The bottom line is "the data are ODbL 
compliant" though it isn't via "license."


Yes, we're aware of County of Santa Clara v. California First Amendment 
Coalition as it relates to the CPRA. The wiki page describing the import 
[1] currently states the source data's _copyright status_ as being in 
the public domain, steering clear of the term "license". Hopefully 
that'll be clear enough for the purposes of this import project.



From an OSM perspective, I suppose it can be said we are fortunate to have as 
much state (of California) published geo data available to us as we do; I 
certainly am grateful for these circumstances!


Well said -- as someone who also maps in states with more restrictive 
copyright laws, it's been refreshing to be able to say "public domain", 
end of story.


[1] 
https://wiki.openstreetmap.org/wiki/Santa_Clara_County,_California/San_Jose_Sidewalk_Import


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

[Talk-us] talk-us-sfbay

2017-08-30 Thread Minh Nguyen

There's a new talk-us-sfbay mailing list for discussing issues specific 
to the San Francisco Bay Area and Northern California in general:


https://lists.openstreetmap.org/listinfo/talk-us-sfbay/

You're welcome to join regardless of where you live or map, but be 
forewarned that you may have to put up with hyperlocal discussions at 
times. ;-)


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] South Bay community meetup, Sept. 23 in San Jose

2017-08-30 Thread Minh Nguyen

We're (re)starting an OpenStreetMap community in the South Bay, starting 
with a meetup in San Jose next month. Code for San Jose is sponsoring 
the event as part of the National Day of Civic Hacking.


Please RSVP and invite anyone you know who might be interested in OSM. 
Here are the details:


Saturday, September 23, 2017
10:00 AM to 5:00 PM

The Tech Museum Design Challenge Learning Institute
145 West San Carlos Street, San Jose, CA
https://www.openstreetmap.org/way/499736149

More information:
https://www.meetup.com/Code-for-San-Jose/events/242474711/

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pittsburgh neighborhood boundaries mapped with admin_level 9?

2017-08-27 Thread Minh Nguyen


On 25/08/2017 12:18, OSM Volunteer stevea wrote:

The point of admin_level is that each member in the hierarchy is a distinct "government" offering 
specific government services by the consent of the governed.  (By several-years-ago OSM consensus, 
special-purpose districts like parks, schools, COGs or MPOs don't get tagged with admin_level).  I very much 
like the way Minh Nguyen describes "Municipal Subdivisions" (below Municipalities or cities/towns) 
in WikiProject_United States/Boundaries:  "Where these subdivisions serve as a system of general-purpose 
units of government with well-defined boundaries, they are tagged boundary=administrative 
admin_level=10."  SOME cities (we agree, and virtually all of them relatively large) truly do have two 
such levels, such as New Orleans which has wards AND neighborhoods, both well-established.  Good we have 9!

In short, larger cities MIGHT have truly administrative neighborhoods, which it 
is emerging in the USA should be tagged admin_level=10.  For cities with two 
administrative subdivisions below cities (like New Orleans), we have and should 
tag both 9 and 10, obviously the lower/lowest gets 10.  In smaller cities, 
especially suburbs, consider mapping (sometimes homeowner association–managed) 
residential subdivisions with landuse=residential ways (often closed polygons), 
omitting admin_level altogether.  Admin_level tagging (especially below 8) 
continues to become better-defined in the USA, and I am pleased to see us 
continue to discuss it well right here.


I'd like to remind the list that the "well-established" New Orleans 
neighborhoods that Steve refers to conflates two concepts. Indeed, New 
Orleans does have well-established neighborhood names, many with 
boundaries defined well enough for inclusion in OSM. There's also a set 
of neighborhood boundaries used for planning purposes by the City 
Planning Commission. [1] The latter are inspired by the traditional 
neighborhoods and boundaries, in exactly the same way that 
census-designated places are inspired by traditional neighborhoods.


Just a couple examples from my own experience:

I was born in what the planning commission apparently calls "Read 
Boulevard East". You would be hard-pressed to find any such designation 
on the ground, and a local will give you a weird look if you refer to 
it. I suppose some New Orleanians do refer to "the Read Boulevard area", 
just as you would refer to the area around any major thoroughfare. But 
in common usage, there aren't precise boundaries for that area and no 
one divides it between east and west.


What you will find on the ground in that area are prominent neighborhood 
entrance signs in the neutral ground of major arterial streets. (These 
signs are posted all over Greater New Orleans, including on the Westbank.)


Eastover: https://goo.gl/maps/pAYqEVc2qn62
Fauberg: https://goo.gl/maps/2XPwuyXXbmy
Idlewood: https://goo.gl/maps/ZfwaroyHDmt
Lake Bullard: https://goo.gl/maps/nM6kHoBZ8tB2
Lake Forest Estates: https://goo.gl/maps/1gafzH6k3TP2
McKendall Estates: https://goo.gl/maps/HmENbSJWxZF2

I've mapped some of these residential neighborhoods as 
landuse=residential areas. When it comes to the less historic parts of 
New Orleans, at least, I think that approach is far more appropriate 
than mapping administrative boundaries based on the planning 
commission's neighborhood boundaries.


[1] https://en.wikipedia.org/wiki/Neighborhoods_in_New_Orleans


SteveA
California
(a big fan of "let's get admin_level as correct as we can in the USA")



From: Peter Dobratz <pe...@dobratz.us>
To: Albert Pundt <roadsgu...@gmail.com>
Cc: "talk-us@openstreetmap.org" <talk-us@openstreetmap.org>
Sent: Thursday, 27 July 2017, 18:29
Subject: Re: [Talk-us] Pittsburgh neighborhood boundaries mapped with admin 
level 9?

(Appologies as I was in the middle of writing my reply when inadvertantly 
hitting send.  Here's the whole message)

Boundaries below admin_level=8 are still being discussed.  There was some 
discussion on this list as well as the OSM wiki

https://wiki.openstreetmap. org/wiki/Talk:United_States_ 
admin_level#Nine_state_ improvement

Having lived in Pittsburgh, I remember that the neighborhood boundaries are 
well defined and many of the street signs have the neighborhood names printed 
across the top of them (epecially on more major roads with bigger signs).

If you were to divide up Pittsburgh into smaller administrative units, how 
would you do it?

Pittsburgh resides within Allegheny County.  Allegheny County is divided into 
Wards and districts, some of which could be used to divide up Pittsburgh:
http://apps.alleghenycounty.us/website/MuniPgh.asp

Pittsburgh city council is made up of 9 people who each represent a council 
district of the city.  It looks like each council district covers a group of 
neighborhoods (that might lend itself to making

Re: [Talk-us] Redacting 75, 000 street names contributed by user chdr

2017-08-27 Thread Minh Nguyen


On 27/08/2017 06:49, Frederik Ramm wrote:

Here's a list of way IDs affected, with country and state:

http://www.remote.org/frederik/tmp/chdr.details


In case it helps, I dumped this CSV into a spreadsheet and sorted it by 
country and region:




This spreadsheet is currently open for anyone to edit or comment on.

I was primarily interested in two U.S. states, so I dumped the way IDs 
for those states into an Overpass query to get an idea of which part of 
the state would be most affected. The resulting query has a URL too long 
to share, but here's a template you can follow:




Here's how you'd narrow down the results to a particular county:



Some other tips that may be helpful for anyone trying to hand-verify 
these ways:


* Level0 has a box where you can enter a list of way IDs and get their 
tags: 

* Similarly, in iD, type w1234 into the search bar to jump to way 1234.



I hand-reviewed the 63 affected ways in Ohio and 37 in Indiana. Each of 
chdr's edits can easily be explained as one or more of:


1. Expanding preexisting, TIGER-imported abbreviations in name
2. Copying preexisting, TIGER-imported name_1 or name_2 tags to name
3. Copying name tags from nearby streets whose names were imported from 
TIGER


Virtually all the instances of #1 could be filtered out by running the 
preexisting name through the TIGER expansion bot code.


None of the occurrences of #2 matches Google Maps.

Of the occurrences of #3, only one way matches Google Maps. I think that 
was a coincidence, but in any case, both chdr's edit and Google Maps 
were wrong, so I corrected the name.


See the spreadsheet for details on each way in these two states, and 
feel free to perform a similar review for other areas.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Differences with USA admin_level tagging

2017-07-18 Thread Minh Nguyen


On 11/07/2017 11:46, Kerry Irons wrote:

If all of you want to have some fun with jurisdictional boundaries, take a look 
at College Corner, OH/IN.  It is a village purposefully straddling the OH/IN 
state lines with the main street being the state line.  It has two zip codes, 
is in three counties (two in OH, one in IN) and school district issues to 
match.  It puts paid to a lot of ideas we all have about jurisdictional 
hierarchies and boundaries.  Delmar in Delaware/Maryland has similar, though 
not quite as complicated issues.  I'm sure there are other examples


In terms of administration, West College Corner, Indiana, and College 
Corner, Ohio, are two distinct municipalities incorporated under the 
laws of their respective states, even though they form a single 
community. There's a West College Corner welcome sign as you cross into 
Indiana on U.S. 27. [1]


There are other "twinned" cities along the Ohio-Indiana border -- 
namely, Union City and Harrison (with West Harrison) -- but this is the 
only pair that shares a school district (in practice, if not on paper). [2]


[1] https://goo.gl/maps/R91qvcRj16m
[2] 
https://en.wikipedia.org/wiki/Union_County–College_Corner_Joint_School_District


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Best practice in Singpost Editing

2017-07-17 Thread Minh Nguyen


On 17/07/2017 02:13, Horea Meleg wrote:

Hello all,

Me and my Telenav colleagues are editing Signposts in Detroit area. We 
were wondering which would be the complete information in this case, 
when a secondary(primary) road and a motorway_link intersect - should a 
motorway_junction tag be added?


42.482377, -83.259498


I assume you're referring to 
. This node should not be 
tagged highway=motorway_junction, because the motorway_link in this case 
is an on-ramp (motorway entrance). highway=motorway_junction is only 
used at the beginning of an off-ramp (exit) -- that is, a link way that 
leads away from the motorway.


However, it is a good idea to add destination and destination:ref tags 
based on any signage you see near the beginning of this ramp. Navigation 
software needs these tags to be used with on-ramps and off-ramps alike.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Differences with USA admin_level tagging

2017-07-09 Thread Minh Nguyen

On 08/07/2017 12:32, OSM Volunteer stevea wrote:

Kind of long and complex ahead; apologies in advance for the length.

I've been documenting our
https://wiki.openstreetmap.org/wiki/United_States_admin_level wiki over much of
the last year with careful research on how US states and territories carve
themselves up into administrative subdivisions. My thrust has been how states
actually do this via their state constitutions, state legislation, real-world
practice and in some cases on-the-ground signage (e.g. city limit or township
boundary signs). Research indicates minor differences in the way that the US
Census bureau does something quite similar, and as noted in that wiki, OSM
largely aligns, but there are minor exceptions (e.g. census boundaries in
Alaska may be valuable enough to keep, but let's not call them administrative
boundaries, they are not, but it's OK if the Census Bureau does so if we note
that minor difference and tag in a way we discuss and document).

Whether those results (that wiki and its necessarily complex table and Notes) are fortunate or
unfortunate, this prompted another OSM mapper (Minh Nguyen, he has kindly given me implicit
permission to name him and explicit permission to cite his recent WikiProject addition) to create
"his" https://wiki.openstreetmap.org/wiki/WikiProject_United_States/Boundaries wiki.
Minh's thrust there has been to carefully document what admin_level tags OSM actually DOES HAVE.
Even if those tags are "incorrect" in some legal sense, he documents what actually IS in
the map. OK, fine: that is a noble goal and he has largely achieved it with this wiki in short
order.

Without going through the sausage-making details of the flurry of our recent dialog (in wiki, talk-pages and private
email exchanges), I am taking Minh up on his offer to "propose a change on the mailing list. Rally the OSM
community behind your cause. You can even hold up the WikiProject United States/Boundaries page as a testament to how
incorrect the map is right now." (I quote Minh exactly there). By doing so, I hope to generate more light than
heat, essentially harmonizing both of our efforts and as a result, significantly improving our map. Perhaps along the
way, we hopefully better clarify what we mean by consensus: what "the People" say via law and practice and
what "we actually do in OSM as we put data into our map." These are not and should not be fundamentally
disharmonious, but the distinction seems to have created some friction I'd like to "solve."

Thank you for starting this discussion, Steve. I hope looping in the
community will get us past the impasse that occurred in private e-mail.
Whatever the outcome, I hope it'll result in a more accurate wiki. After
all, the wiki works best when its pages closely reflect the state of the
map, tagging proposals are clearly marked as such, and retagging
proposals come with a gameplan. (The wiki has a reputation of being a
blue-sky wishlist among some software developers, but I'd like to change
that.)

Just to avoid misunderstanding: the quotes are around "his" because I
don't own the "WikiProject United States/Boundaries" page, I merely
wrote the first draft. It and "United States admin level" are two
different wiki pages with different goals, but anyone can contribute
towards those goals.

Briefly (re-)stated, Minh characterizes this dichotomy as "prescriptive vs. descriptive."
In other words, Minh and I both claim the US_admin_level wiki prescribes how we SHOULD tag
admin_level in the USA and the US/Boundaries wiki describes how OSM now DOES map them. Our dialog
has allowed me to identify specific differences, what appear to be deficiencies in our map,
actually. These are limited to nine US states (eight with deficiencies, a ninth with what appears
to be a deficiency and perhaps an "off-by-one" error). I now list these issues.

Here are what exist in state constitutions/statutes/the real world, map well
onto OSM's admin_level scheme, yet do not exist in OSM's data:

Rhode Island 7/Town, 9/Village: all are marked as 8/City when perhaps some are
7/Town or 9/Village
Massachusetts 7/Town: all are marked as 8/City when perhaps some are 7/Town
Maine 6/Unorganized territory and 6/(unincorporated) Plantation
Vermont 8/Village: all are marked as 8/City when perhaps there are 9/Villages
in some 8/Cities
Pennsylvania 7/Township, 7/Borough are missing throughout, 8/Town subordinates
to Borough, 8/Village and 8/Hamlet both subordinate to 7/Township
Connecticut 6/Region (not County), or both? Harmonize these
Minnesota 7/Township, 7/Town (it appears simply that none have been entered)
Illinois 7/Township, 7/Precinct?

New Hampshire, 8/Town: shouldn't these be 7/Town (as inTownship)? Are there
7/Organized Locations?

I want to call attention to three additional regions, beyon

Re: [Talk-us] Need advice on a project i've taken on

2017-06-11 Thread Minh Nguyen


On 11/06/2017 16:19, Hans De Kryger wrote:


On Sun, Jun 11, 2017 at 1:38 PM, Shawn K. Quinn > wrote:


What exactly is the rationale behind removing the zip code data?


The usefulness is nonexistent 


In the past, I've used these tags to sanity-check addr:postcode tags on 
nearby POIs. I'm aware that ZIP codes are more complex than meets the 
eye [1], although the left/right modeling used in the TIGER import is at 
least consistent with ZIPs-as-routes. It was handy, but there are other 
ways to sanity-check addr:postcode tags anyhow.


[1] https://github.com/iandees/wtf-zipcodes

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] .... finding areas that are underserved

2016-11-18 Thread Minh Nguyen


On 2016-11-12 14:44, Markus Fischer wrote:

Hi,

I am new to this and the area where I live is very well mapped (probably
due to high density of tech workers). Where do I go to start mapping
areas that are less well mapped (me aimlessly poking at this does not
sound like a good approach)?


The entire state of West Virginia -- no exaggeration. The original data 
imported from TIGER is badly misaligned throughout this state and rarely 
resembles the road network at all. Making matters worse, many public 
roads wind through hollows that even in the best aerial imagery are 
obscured by the surrounding mountains' shadows. Fortunately, newer TIGER 
data (available as an overlay in iD) is very good and makes it possible 
to clean up the mess.


While you're there, West Virginia's hilltop mining roads and power lines 
are much easier to trace from aerial imagery. I personally find mapping 
these features to be a good break from the stress of untangling TIGER roads.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Rail rendering support in our wiki?

2016-10-25 Thread Minh Nguyen


On 2016-10-24 17:31, OSM Volunteer stevea wrote:

As I also make USA rail contributions, is there any way that our wiki might allow similar 
"layer=rail" syntax to display OpenRailwayMap (.org), for example to display an 
appropriate rendering at the top of our California/Railroads wiki page?


The  tag comes from the Simple Image MediaWiki extension. [1] 
You can specify layer="transport" to get the same rail- and bus-focused 
style as the Transport layer on osm.org. (Incidentally, layer="cycle" 
also works.)


The extension's source code is on GitHub, if anyone is interested in 
improving it. [2] However, at this point, it sure would be nice to be 
able to use the Kartographer extension's slippy maps instead. [3][4]


[1] https://wiki.openstreetmap.org/wiki/Simple_image_MediaWiki_Extension
[2] https://github.com/Firefishy/SimpleMap
[3] https://www.mediawiki.org/wiki/Extension:Kartographer
[4] https://trac.openstreetmap.org/ticket/5431

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another state route shield renderer and tutorial

2016-07-27 Thread Minh Nguyen

As I mentioned in the diary post, it doesn't handle any of those cases. To be 
sure, there is a regular expression behind the scenes to ensure that Texas Loop 
highways for instance aren't given the us-state shield value. On the other 
hand, there isn't any logic to sort out true edge cases like Arkansas Highway 
43.

I still believe combining that regular expression with the spatial query is a 
step up from the common practice of using only a regular expression, and in 
optimistic that, if nothing else, this demonstration will spur others to keep 
working toward true route relation support.

Minh Nguyễn
Sent from my autocorrect-ennobled device

> On Jul 27, 2016, at 11:43, Paul Johnson <ba...@ursamundi.org> wrote:
> 
> OK, but how does it handle literal edge cases?  Such as WA 433 in Oregon, OK 
> 20 in Arkansas, or AR 43 in Oklahoma?  Or not-so-edge cases such as Texas' 
> infamous multitude of state highway networks, or the two state highway 
> systems in Oklahoma, Kansas and Missouri?
> 
>> On Wed, Jul 27, 2016 at 2:12 AM, Minh Nguyen <m...@nguyen.cincinnati.oh.us> 
>> wrote:
>> A couple days ago, I posted a diary entry about rendering state-specific 
>> highway shields using Mapbox tools. It's a topic of special interest to the 
>> U.S. community, so I figured I'd give the talk-us list a heads-up since not 
>> everyone reads the diaries regularly:
>> 
>> <http://www.openstreetmap.org/user/Minh%20Nguyen/diary/39123>
>> 
>> The diary entry begins with a summary of the arguments for pictographic 
>> shield rendering and the challenges facing renderers that attempt to 
>> differentiate between each state's design. I also argued against using 
>> regular expressions to select state route shields.
>> 
>> I developed a demonstration vector renderer, called Interstate, that 
>> differentiates between the Ohio, Kentucky, and Indiana state route shields, 
>> despite ambiguous `ref=SR 123` tagging in both Ohio and Indiana:
>> 
>> <http://nguyen.cincinnati.oh.us/minh/osm/interstate/>
>> 
>> Though Interstate is only a proof of concept design-wise, it runs on 
>> production servers and mainstream software. The second half of the diary 
>> entry walks you through the steps to create your own, prettier version of 
>> Interstate using free Mapbox tools.
>> 
>> (Full disclosure: I work at Mapbox. But my motivation for posting the 
>> tutorial is to nudge the community away from relying on regular expressions 
>> to select shields and towards eventually using route relations for that 
>> purpose.)
>> 
>> For now, I continue to point people to 
>> <http://elrond.aperiodic.net/shields/> when I want to show them what route 
>> relations are good for, but Interstate is another option when the issue of 
>> way `ref` formats comes up.
>> 
>> -- 
>> m...@nguyen.cincinnati.oh.us
>> 
>> 
>> ___
>> Talk-us mailing list
>> Talk-us@openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/talk-us
> 
___
Talk-us mailing list
Talk-us@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-us

[Talk-us] Another state route shield renderer and tutorial

2016-07-27 Thread Minh Nguyen

A couple days ago, I posted a diary entry about rendering state-specific 
highway shields using Mapbox tools. It's a topic of special interest to 
the U.S. community, so I figured I'd give the talk-us list a heads-up 
since not everyone reads the diaries regularly:




The diary entry begins with a summary of the arguments for pictographic 
shield rendering and the challenges facing renderers that attempt to 
differentiate between each state's design. I also argued against using 
regular expressions to select state route shields.


I developed a demonstration vector renderer, called Interstate, that 
differentiates between the Ohio, Kentucky, and Indiana state route 
shields, despite ambiguous `ref=SR 123` tagging in both Ohio and Indiana:




Though Interstate is only a proof of concept design-wise, it runs on 
production servers and mainstream software. The second half of the diary 
entry walks you through the steps to create your own, prettier version 
of Interstate using free Mapbox tools.


(Full disclosure: I work at Mapbox. But my motivation for posting the 
tutorial is to nudge the community away from relying on regular 
expressions to select shields and towards eventually using route 
relations for that purpose.)


For now, I continue to point people to 
 when I want to show them what 
route relations are good for, but Interstate is another option when the 
issue of way `ref` formats comes up.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Common names of highways do not match road signs.

2016-07-11 Thread Minh Nguyen

Kevin Morgan  writes:

> 
> 
> Here is an idea. An additional tag is added called signage. The tag use
the following format  name;ref;text. Each item is added to the tag if the
information is in clued on road signs. The tag has the following sub tags
color, icon, description, direction and text. The text sub tag is used to
add additional text that is not a part of the name or ref. For example the
city a road way leads to often include on a road sign. Description is for
descriptive information that needs to be interpreted by a person rather map
generation software. Direction is north,south, east,west. 

There is a separate tagging scheme for destination and directional
information. [1] Many major highways have been tagged this way. Hopefully
OSM-based navigation software would begin to make use of these tags, because
relying solely on names and refs on ways would lead to a lot of missed
turns, regardless of the criteria for using the `name` tag.

[1] http://wiki.openstreetmap.org/wiki/Exit_Info

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

Re: [Talk-us] Common names of highways do not match road signs.

2016-07-08 Thread Minh Nguyen

Paul Johnson  writes:

> 
> On Thu, Jul 7, 2016 at 9:32 PM, Kevin Morgan
 wrote:It is confusing
to use open street maps in my area(Central Ohio) for
> driving directions since the "common names" of high ways do not match
> road signs. The common names are used by open map chest for road names.
> For example when turning on to State Route 315 with OpenMapChest loaded
> on my GPS I am directed to turn on to Olentangy Freeway. However the
> tiger name on open street maps is State route 315. Would it make more
> sense to configure driving maps to use tiger names for driving
> directions,  change commons names to include the state route number or
> interstate number, or add state route number/ interstate number as a
> different tag?
> 
> 
> ref=* isn't name=*, don't tag for the renderer.  I'd go with the official
name for name=*.  If you're inclined to do something like, name=State Route
315, you really want ref=OH 315.

You mean `ref=SR 315` and "don't tag for the router". ;-)

The established tagging conventions are designed so that any software that
needs to say something more sophisticated based on the route designation
would parse `network=US:OH` and `ref=315` from the associated route relation
and expand it into "State Route 315". You can find out more about tagging
Ohio route relations on the wiki. [1] The TIGER name Kevin refers to is a
vestige of an import; it isn't customary to tag this way when mapping by hand.

Ohio's DOT makes a point of avoiding names for any Interstate or state route
on signage, in favor of listing control cities. This is different than, say,
Kentucky, which tends to place the highway name next to the route marker on
overhead guide signage.

But Ohio highways still often have official names which are still known
locally, even if they aren't signposted. One example in the Cincinnati area
is the freeway portion of SR 562. The official name is "Norwood Lateral
Expressway", and Cincinnatians universally refer to it as the "Norwood
Lateral", to the point that pretty much no one knows what "SR 562" refers
to. It's clear that `official_name=Norwood Lateral Expressway` and
`loc_name=Norwood Lateral` would be appropriate. `unsigned_name=Norwood
Lateral` is another option.

(Incidentally, a nearby highway was exempted from ODOT's policy after being
renamed for Ronald Reagan. So the signs do include the road name. [2])

If you take the position that `name` should reflect signage, perhaps because
finding signage is more verifiable than asking someone at the nearby gas
station, then `name=Norwood Lateral` would clearly be inappropriate. (A part
of the world that doesn't signpost this way must look rather bare on the
map.) On the other hand, if your reasoning is that `name` should be whatever
name is most useful to someone attempting to use OSM for navigation, then
"Norwood Lateral" isn't entirely useless for that purpose. (You'll never
hear "562" on the traffic report.)

[1] http://wiki.openstreetmap.org/wiki/Ohio/Route_relations
[2] https://en.wikipedia.org/wiki/Ronald_Reagan_Cross_County_Highway

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

Re: [Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

2016-07-05 Thread Minh Nguyen


On 2016-07-05 10:08, Peter Dobratz wrote:

After arriving at a local drugstore chain with a prescription in hand,
walking past the shampoo aisle, only to find that the pharmacy counter
is closed for the day, I've been updating tagging of drugstores and
pharmacies as described here.

For example, there is a Walgreens:

http://www.openstreetmap.org/way/266495943

The building outline has shop=chemist.

Inside the building, there are 2 Nodes, one for the pharmacy and one for
a clinic:

amenity=pharmacy
dispensing=yes
drive_through=yes
http://www.openstreetmap.org/node/4064469934

amenity=doctors
http://www.openstreetmap.org/node/4064469933

In this case, all of these entities have different opening hours.  Other
contact info like phone and website may be different as well.


This is the approach that's been proposed informally, and iD's change 
would be a part of it. But I don't see how this practice becomes 
commonplace with the shop=chemist preset being labeled "Drugstore" and 
no other UI changes. Where's the reminder to also map the pharmacy 
counter or clinic if the store has one?


There's certainly something to be said for micromapping a drugstore as a 
collection of counters with different opening hours, just as one might 
micromap a supermarket with its florist and bakery, or a department 
store with its café and photography studio. At the same time, the 
pharmacy counter is the defining characteristic of an American 
drugstore. That's why the largest U.S. chain signs each of its stores 
with the name "CVS Pharmacy" (except for the handful that lack pharmacy 
counters). A renderer or search engine that conflates a drugstore with 
its pharmacy counter isn't doing as much a disservice as one that omits 
the pharmacy counter because the mapper didn't know to add one.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

2016-07-05 Thread Minh Nguyen


On 2016-07-05 08:45, Minh Nguyen wrote:

This change to iD came about due to a discussion in the Name Suggestion
Index project, which is the component in iD that suggests tags when you
fill in a commonly used name. [2] I happened to notice the change
because it caused Transifex to prompt me to update iD's Vietnamese
localization. To my knowledge, there has been no discussion on the
mailing lists or formal proposal on the wiki, though the iD maintainer
intends to edit the wiki to match iD's interpretation. iD is the only
software that has made this change.


Sorry, I got a little ahead of myself there. iD's maintainer assures me 
he won't be the one to edit the wiki. :-)


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] shop=chemist as "Drugstore" for Walgreens, CVS, Rite Aid, etc.

2016-07-05 Thread Minh Nguyen

Recently, iD was changed so that shop=chemist is labeled as "Drugstore" 
for American English users (and continues to be labeled "Chemist" for 
British English users). [1] An American mapping a Walgreens, CVS, or 
Rite Aid who searches for "drugs" will see the following choices, in order:


* Drugstore (shop=chemist, marked with a shopping cart icon)
* Pharmacy (amenity=pharmacy, marked with a pill bottle)

Meanwhile, searching for "pharmacy" -- a synonym of "drugstore" in 
American English -- produces only the amenity=pharmacy preset.


The rationale is that amenity=pharmacy should be used only for pharmacy 
counters (which can be found at both drugstores and inside 
supermarkets), while shop=chemist should be used for full-service 
drugstores that *may* contain pharmacy counters. Currently, this is at 
odds with the wiki and longstanding practice, which stipulates that a 
shop=chemist *may not* fill prescriptions.


This change to iD came about due to a discussion in the Name Suggestion 
Index project, which is the component in iD that suggests tags when you 
fill in a commonly used name. [2] I happened to notice the change 
because it caused Transifex to prompt me to update iD's Vietnamese 
localization. To my knowledge, there has been no discussion on the 
mailing lists or formal proposal on the wiki, though the iD maintainer 
intends to edit the wiki to match iD's interpretation. iD is the only 
software that has made this change.


On the one hand, I've come around to liking the proposal, because it 
makes it easier for data consumers to distinguish between pharmacy 
counters and full-fledged drugstores. On the other hand, I think it's 
problematic because an American mapping a Walgreens or CVS could 
potentially tag a "drugstore" and be unaware that they'd need to 
separately map the pharmacy counter in order to indicate that 
prescriptions may be filled on-site.


Currently, amenity=pharmacy is far and away more common than 
shop=chemist in the U.S. as a way to tag drugstores. Certainly anyone 
retagging amenity=pharmacy to shop=chemist would be careful to add an 
additional amenity=pharmacy POI where the pharmacy counter would be. 
(For a typical Walgreens or CVS, it'd be next to the drive-through 
canopy.) However, I have little faith that the average iD user would 
know to do the same, since the word "drugstore", like "pharmacy", 
implies the sale of prescription drugs.


I've hashed out many of these points in [3], but I think the discussion 
needs to involve the wider OSM community now. There's little chance of 
data consumers and other editors updating their logic if the change is 
only discussed in the iD project.


[1] https://github.com/openstreetmap/iD/issues/3201
[2] https://github.com/osmlab/name-suggestion-index/issues/30
[3] https://github.com/openstreetmap/iD/issues/3213

--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-17 Thread Minh Nguyen

(Sorry, I sent from the wrong address, so this message got stuck in moderation.)

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> 
> Sorry that it took me a while to reply, I was out of office and just came
back now.
> 
> 
> Il giorno 10 giu 2016, alle ore 21:07, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> 
> 
> 
> is this your interpretation or is it explicitly defined like this? I'm
> astonished that these 2 concepts are supposedly structured vertically and
not horizontally in wikidata 
> 
> 
> <https://www.wikidata.org/wiki/Q486972> is defined in Wikidata as a
subsetof <https://www.wikidata.org/wiki/Q56061>. I agree that this is a
suboptimalrelationship – anyone can edit
> 
> 
> 
> it's not a big problem to have errors in the relations as long as
everybody can agree that it's an error and should be corrected. But the fact
that this wrong relation still sits in there and doesn't actually get
corrected is a bit troubling, particularly as this is IMHO a major bug which
has influence on all settlements that are in wikidata.
> 
> 
> Another issue I believe to have found in this item looking at
https://www.wikidata.org/wiki/Q486972 :the first words, (I believe it is
meant to be the definition, although it does not explicitly say so,) are
"densely populated geographic location
> 
> 
> populated place
> settlement
> human community
> inhabited place"
> 
> Now when you think about a ghost town, it clearly is a human settlement,
but this definition falls short in covering it. I would prefer, rather than
a collection of related terms (human community, inhabited place etc), a
complete sentence that defines the term, e.g. "a human settlement is a place
where a community of humans lives or lived and decided in the past to settle
and create dwellings." (surely could be improved, just an example).
> 
> There are lots of unanswered questions in wikidata, and probably, by
judging from the current state of the data, not enough editors to manage to
look through all of it.
> Another issue that comes to mind: what about contradictions between an
article and a wikidata object? How is the relationship between the articles
and wikidata? Apparently, you can only associate on article to one item, so
this suggests a strong relationsship, but clearly there are articles in many
languages, and there will be lots of contradictions between those languages
(because there are lots of articles, and because nearly noone cross checks
different languages). IMHO it would have been a better idea to have a less
strong relationship, something like "this article has information about this
item" (and hence allow multiple articles to be associated with an object)
rather than what it seems conceptually  to be thought of now (the articles
and this wikidata object deal with the same thing, are the same thing, here
in article form and here as mathematical relations).For me these are just
more indications that we should not base automatic edits on this source at
the moment. 

You raise a number of important points, but I think these concerns should be
posed on Wikidata's village pump or mailing list, where they can be more
effectively addressed. The Wikidata community has more answers that I would
individually.

I disagree that these considerations make the iD feature less correct given
that the wikidata tag is already widely used.

In fact, many of these same questions could be asked of Wikipedia. If the
mapper is tagging a ghost town POI with a Wikipedia article, can we be sure
at a technical level that the article's contents or categorization matches
OSM's semantics? Regardless, if the tagged feature is tagged as a ghost town
in OSM, the fact that it is tagged as a non-former human settlement in
Wikidata merely means the Wikidata item needs to be retagged as a ghost
town. I see no problem with the semantics in
<https://www.wikidata.org/wiki/Q74047>.

When an English-speaking mapper tags `wikipedia=en:China`, what's to say
`wikipedia=fr:Chine` has the same semantics? It's two hops away from the
English article, rather than the one hop to Wikidata. Yet most tools and
users assume that one is equivalent to the other when tagged on an object.
Otherwise, we'd have to maintain a litany of redundant `wikipedia:xy` tags
on every place POI and basically try to replicate Wikidata's interwiki
function for any Wikipedia tag to be broadly useful.

It wasn't so long ago that most Wikipedias' articles named "Crimea" referred
to the political entity as well as or instead of the peninsula. If, back
then, the administrative boundary in OSM had been tagged with
`wikipedia=en:Crimea` and mappers subsequently forgot about that tag, it
would've suddenly become illogical as soon as Wikipedia editors decided to
move the "Crimea" article somewhere else and replace it with what was
previously ti

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-10 Thread Minh Nguyen

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> > Il giorno 10 giu 2016, alle ore 01:58, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> > 
> > 
> > * “Administrative territorial entity” is the superset of “human
> > settlements”. This superset has 2,225,880 items. [2] You’d see these items
> > on place POIs and boundary=administrative boundary relations.
> > 
> > * “Human-geographic territorial entity” is the superset of “administrative
> > territorial entity” that also includes cultural and purely political
> > boundaries. That superset is less than 1% larger (2,245,631)
> 
> is this your interpretation or is it explicitly defined like this? I'm
astonished that these 2 concepts are
> supposedly structured vertically and not horizontally in wikidata 

<https://www.wikidata.org/wiki/Q486972> is defined in Wikidata as a subset
of <https://www.wikidata.org/wiki/Q56061>. I agree that this is a suboptimal
relationship – anyone can edit, I suppose – but it shouldn’t affect the
quality of the `wikidata` tags that iD comes up with.

> > . [3] Something
> > that’s a human-geographic territorial entity but not an administrative
> > territorial entity probably shouldn’t be mapped in OSM in the first place.
> 
> I dissent, OSM is about humans observing their environment and mapping it.
There's no requirement for
> administrative independence. Administrative territorial entities on the
other hand are set up
> following different logics and rules, sometimes differing from the actual
social-geographic reality.

I should’ve been clearer in my wording. The distinction between an
“administrative territorial entity” and any other “human-geographic
territorial entity” in Wikidata is based not on administrative independence
but rather on whether the area within the territory is administered
differently than the area outside of the territory.

An example of a non-administative territorial entity would be a “statistical
territorial entity” <https://www.wikidata.org/wiki/Q15042037>, such as a
Census-Designated Place in the United States
<https://www.wikidata.org/wiki/Q498162>. I guess I can’t speak to mapping
practices in every country. But in perrennial discussions on talk-us, the
consensus has been to phase out or retag the TIGER-imported administrative
boundaries for CDPs, on the grounds that the boundaries are a statistical
fiction that can’t be observed in any way on the ground. I see no daylight
between Wikidata and OSM when it comes to the difference between
administrative and non-administrative boundaries, even if the terminology
differs somewhat.

Also, I personally expect that this iD feature will wind up affecting
landmarks and non-place POIs more than boundary relations.

> > 
> > Rather than searching Wikidata, iD essentially only follows the explicit
> > link from the user-specified Wikipedia article to its Wikidata item. The
> > presence of this link indicates that Wikipedians currently consider the item
> > to be synonymous.
> 
> the presence of the link does not indicate that they're seen as
synonymous, but that it might be useful to
> look at it, and that there is some connection between the two, but that's
not the same as synonymous 

I think it’s more than that: I think we can agree that the English Wikipedia
article “United States” and the French Wikipedia article “États-Unis”
discuss the same concept (ignoring any content-level differences). In order
for the two articles to link to each other in the “In other languages”
section, they have to share exactly one Wikidata item in common. This is
enforced at a technical level for all Wikipedia languages. (This is
Wikidata’s most important feature: serving as a replacement for the old
“interwiki links” system.)

Increasingly, Wikipedias are relying on Wikidata to supply information for
infoboxes and other elements. For example, the municipality infoboxes on
some Wikipedias automatically display the “population” property of the
Wikidata item linked to the article. It would make no sense for a city
article to state a population based on a “useful to look at” relationship.

-- 
Minh Nguyen <m...@nguyen.cincinnati.oh.us>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-09 Thread Minh Nguyen

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> > Il giorno 09 giu 2016, alle ore 02:23, Minh Nguyen 
nguyen.cincinnati.oh.us> ha scritto:
> > 
> > If I understand correctly, you’re referring to a situation where, for
> > instance, Wikipedia editors have opted to discuss both an “administrative
> > territorial entity” and its government in the same article, whereas Wikidata
> > editors have decided to separate the concepts into two different items
> 
> at least the former is very common for cities I believe (didn't conduct a
scientific study about it though),
> I'm not so sure how common the latter is, my impression when I last looked
was that many of the socio
> geographic entities are still missing in wikidata (so rather than using 2
distinct objects there is one
> which corresponds to a part of the article), their editors seem to have a
preference for political
> administrative entities.

I’m not sure whether we’re talking about the same concepts, so here are some
data points about the kinds of Wikidata items that iD might end up
associating with place POIs or boundary relations (among the many kinds of
features that can be tagged with `wikipedia` and `wikidata`):

* Currently, Wikidata has 1,775,365 items tagged as “human settlements”. [1]
You’d expect to see these items tagged on place POIs, including cities and
villages but also places that don’t have boundaries (like unincorporated
places).

* “Administrative territorial entity” is the superset of “human
settlements”. This superset has 2,225,880 items. [2] You’d see these items
on place POIs and boundary=administrative boundary relations.

* “Human-geographic territorial entity” is the superset of “administrative
territorial entity” that also includes cultural and purely political
boundaries. That superset is less than 1% larger (2,245,631). [3] Something
that’s a human-geographic territorial entity but not an administrative
territorial entity probably shouldn’t be mapped in OSM in the first place.

Rather than searching Wikidata, iD essentially only follows the explicit
link from the user-specified Wikipedia article to its Wikidata item. The
presence of this link indicates that Wikipedians currently consider the item
to be synonymous. To get a better sense of how widespread these iD-generated
tags would be, the queries above could be filtered to those items that have
sitelinks. Unfortunately, that particular query times out on the Wikidata
Query Service. (It’s a great service, but like overpass turbo, it has its
limits.)

> > Wikipedia tends to be proactive about creating separate articles when
> > there’s a notable distinction between the various meanings of a name, but
> > Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
> > between the various meanings of China on the English Wikipedia and the
> > various Wikidata items for those meanings. `wikipedia=en:China` maps to
> > <https://www.wikidata.org/wiki/Q148>, which is for the People's Republic. If
> > the mapper had a different definition of China in mind, both the `wikipedia`
> > and `wikidata` tags would reflect that.
> 
> clearly the china article in wp/en has a much broader scope than the
linked Wikidata item people's republic
> of china. The latter starts looking at things from 1949, Wikipedia "China"
some thousand years earlier.

The Wikipedia article provides historical context, including historical
borders, as any encyclopedia article on this topic should. By contrast, the
Wikidata item is more focused on the present, much the way an OSM boundary
relation should reflect the present. (The historical boundaries go in
OpenHistoricalMap, after all.) Both Wikipedia and Wikidata have entries for
other definitions of China. [4] To me, this suggests that the Wikidata item
more naturally fits an OSM feature than the Wikipedia article does.

[1] http://tinyurl.com/h9p4qb7
[2] http://tinyurl.com/zvrft74
[3] http://tinyurl.com/zuzcvly
[4] https://en.wikipedia.org/wiki/China_(disambiguation) and the Wikidata
items linked to the articles linked from that page

-- 
Minh Nguyen <m...@nguyen.cincinnati.oh.us>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] iD news: v1.9.6 released

2016-06-08 Thread Minh Nguyen

Martin Koppenhoefer  gmail.com> writes:

> 
> 
> sent from a phone
> 
> Il giorno 08 giu 2016, alle ore 18:44, Michael Reichert 
gmx.net> ha scritto:
> 
> >> Am 08.06.2016 um 17:59 schrieb Bryan Housel:
> >> - When setting Wikipedia field value, also set corresponding Wikidata
tag (worked on by Minh Nguyễn)
> > 
> > Isn't this a kind of mechanical edit which should be discussed on this
> > mailing list *beforehand*?
> 
> I also see this critical, if I understood correctly what it means, as the
relationship between Wikipedia
> articles and wikidata items is not 1:1. Yes, the initial wikidata set has
been created from Wikipedia
> articles, but looking at a topic very important to osm, places and
administrative entities, you'll find
> that Wikipedia articles often cover both, a place and the administrative
entity for/of this place, but
> wikidata objects often do not cover both. Adding a wp link to a place
object (typically node) in osm can be
> correct while at the same time adding the wikidata object that corresponds
to the wp article would not be
> (because it refers to the administrative entity)

If I understand correctly, you’re referring to a situation where, for
instance, Wikipedia editors have opted to discuss both an “administrative
territorial entity” and its government in the same article, whereas Wikidata
editors have decided to separate the concepts into two different items, yet
one of the Wikidata items still links to the unified Wikipedia article. Can
you think of an item that would be problematic in this way? How often would
this situation come up on newly tagged features?

In practice, Wikidata gives the various Wikipedia editions a strong
incentive to agree on the scope of an item, because a Wikidata item can only
link to one Wikipedia article per language and a Wikipedia article can only
link to one Wikidata item.

Wikipedia tends to be proactive about creating separate articles when
there’s a notable distinction between the various meanings of a name, but
Wikidata follows suit almost as a rule. So there is a 1:1 correspondence
between the various meanings of China on the English Wikipedia and the
various Wikidata items for those meanings. `wikipedia=en:China` maps to
<https://www.wikidata.org/wiki/Q148>, which is for the People's Republic. If
the mapper had a different definition of China in mind, both the `wikipedia`
and `wikidata` tags would reflect that.

In another example, the English Wikipedia article
<https://en.wikipedia.org/wiki/Arkansas_Highway_980> has one section for
each highway numbered 980 in the U.S. state of Arkansas. This article is
linked to one Wikidata item: <https://www.wikidata.org/wiki/Q2431651>. If
another Wikipedia edition wanted to inflate its article count by creating a
separate stub article for each of these highways, none of these stub
articles could be linked to Q2431651. If you were to tag
`wikipedia=en:Arkansas Highway 980`, iD would add `wikidata=Q2431651`. But
if you were to tag `wikipedia=es:Carretera Arkansas 980 (condado de Van
Buren)`, iD would add no `wikidata` tag.

It would be far more problematic if iD were to automatically edit Wikidata,
adding the edited OSM node’s ID to the item’s statements, since a) OSM IDs
are even more unstable than Wikipedia article titles, and b) OSM can
represent even a single place with multiple features (for example, a
boundary relation and a place POI with role=label, or a 3D building relation
with a building area with role=outline). Fortunately, there are no plans to
do automatically edit Wikidata from within iD.

Finally, I think this feature (and hopefully similar features in other
editors) would help us ensure that, if a real mechanical edit to introduce
Wikidata tags [1] ever gets approved, it would be a smaller, one-time affair
instead of a larger, recurring task.

[1] http://wiki.openstreetmap.org/wiki/Mechanical_Edits/wikidata and
previous threads on this list

-- 
Minh Nguyen <m...@nguyen.cincinnati.oh.us>
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [Talk-us] Proposal: Sunset ref=* on ways in, favor of relations

2015-11-13 Thread Minh Nguyen


On 2015-11-13 02:42, Paul Johnson wrote:

On Sun, Nov 8, 2015 at 8:04 PM, Paul Norman
> wrote:

On 11/7/2015 10:18 AM, Kevin Kenny wrote:

I find lately that it needs a patched Mapnik, because Mapnik
(sensibly)
went to a read-only database connection, and one of Phil's stored
procedures modifies the database the first time that a shield
cluster
is requested. One of these times I'll fix it.

I'm a little disappointed that none of the 'standard' renderers
picked this up.


Phil's demo was an excellent proof of concept of pictorial shields
from route relations, but isn't something that can be reasonably
incorporated into a stylesheet as-is.
https://github.com/gravitystorm/openstreetmap-carto/issues/596 is
the OpenStreetMap Carto issue for shields from relations,
https://github.com/gravitystorm/openstreetmap-carto/issues/508 is
the one for pictorial shields.


There's been a lot of productive talk thus far about potentially moving
this forward, but I'm curious if it makes any difference if we preserve
the existing legends for ref right now, but start rendering the route
relations for the existing style legends where available and just skip
shields until a viable read-only method is developed on the back
burner.  Or is the problem not necessarily depending on shield legends
but something more central?


I'm not very familiar with the toolchain involved here, but this is what 
I gather after racking my brain on the issue for some time:


osm-carto and lots of other styles rely on osm2pgsql to import OSM data 
into a Postgres database. There's already rudimentary support in 
osm2pgsql for generating geometries based on route relations. 
Specifically, it reads in each cycling or walking route and turns it 
into a linestring that coincides with the member ways.


This is fine for OpenCycleMap, which represents routes as translucent, 
badged overlays on roads and trails. But that won't necessarily work for 
road shields. You have to somehow conflate shields on ways with shields 
on the overlaid route. My impression is that that could be expensive, 
though I haven't looked deeply into it. So you'd have to ignore all refs 
on all ways, which could be a nonstarter in parts of the world that have 
yet to see the relation light.


So this osm2pgsql issue asks for a way to apply the relation's tags on 
the member ways:


https://github.com/openstreetmap/osm2pgsql/issues/230

It's a great idea, but it depends on keeping all potential route member 
ways in memory until the relations are all done processing. Or issuing 
lots and lots of UPDATEs. Either way, it sounds expensive, but I really 
hope I'm wrong.


At a higher level, this openstreetmap-carto ticket covers the overall 
enhancement:


https://github.com/gravitystorm/openstreetmap-carto/issues/596

The question then becomes: what sort of shield do you display? Obviously 
switching to pictoral shields is a large undertaking in itself, due to 
the amount of artwork required. But if we instead stick to the textual 
badges for now, we have some additional complications: in the U.S., a 
badge with just a number is horribly ambiguous. Out in Logan County, 
Ohio, there's a state route, county route, and township route all with 
the same number, and two of them intersect.


http://www.openstreetmap.org/relation/184351
http://www.openstreetmap.org/relation/2599900
http://www.openstreetmap.org/relation/2605494

So we need alphabetic prefixes on badges. Unfortunately, it isn't 
straightforward to map `network` values to familiar alphabetic prefixes:


network=US:I  => I ###
network=US:US:Business=> US ### Business
network=US:CA => CA ###
network=US:OH => SR ###
network=US:TX:Beltway => Beltway #
network=US:KY:Parkway `short_name`?
network=US:NY:Onondaga=> CR ###
network=US:OH:MED:Harrisville => T-###

Then there's the issue of concurrencies, where the relations aren't in 
any particular order. You'd need rules for prioritizing one network over 
another in badges or shields. The best heuristic I've come up with is to 
sort by the number of colons, but that doesn't work in Europe (where 
they don't use the same format) or even for some of the examples above.


So in short, it's complicated, and that conclusion comes from someone 
who's both enamored with route shields and very naïve. But no one said 
it was easy. :-)


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] open question about boundaries sharing nodes with ways or nodes

2015-10-14 Thread Minh Nguyen

Mike Thompson  gmail.com> writes:

> 
> Sometimes, such as in the case of the boundary between the US states of
Ohio and Kentucky, it is the low water mark on one bank[1] (in this case the
court held that it was the low water mark of the north bank of the Ohio
River in 1792, not the present low water mark of the north bank, and
therefore the boundary and the river should not share geometry in this case).

I've been guilty of mistakenly joining state boundaries to the Ohio River's
thalweg in the past, and by now I've had to correct those boundaries on
several occasions. It's unfortunate that few mappers are aware of these
complexities. The full situation is spelled out in a wiki page:

http://wiki.openstreetmap.org/wiki/Ohio_River

If any other natural features tend to attract misinformed edits, I suggest
writing up a similar page so you can easily point mappers to it in changeset
comments etc.

Ironically, I was recently involved in a minor car collision onboard a ferry
crossing this river. The police officer who responded had to call around to
verify that he had jurisdiction. Perhaps if his department had distributed
OSM-based maps, we could've been on our way a bit sooner. ;-)

-- 
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Self Storage Places

2015-10-04 Thread Minh Nguyen


On 2015-10-04 00:59, Paul Johnson wrote:

One could argue for industrial since we're talking about rental
warehouse space.  Is there a shop or (ugh) amenity for this?


I've never been quite sure how to tag self storage facilities. Taginfo 
[1] shows significant usage of the following tags, each of which I've 
probably tried out at some point:


amenity=self_storage
amenity=storage
building=self_storage
building=storage
building:use=storage
landuse=self_storage
landuse=storage
man_made=storage
shop=self_storage
shop=storage
shop=storage_rental
shop=storage_units

So yeah, some consensus would be great...

[1] http://taginfo.openstreetmap.org/search?q=storage#values

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

2015-10-03 Thread Minh Nguyen


On 2015-10-03 07:45, Mike Thompson wrote:


By removing access=private you would be removing a valuable piece of
information. Maybe the community can come up with a better tag, but we
should not just delete the "private" tag.


How do people here feel about using access=destination on driveways that 
aren't posted? It more or less captures "who is allowed", if not "who 
owns the road". The tag is designed for streets posted with "no through 
traffic" signs, but that's pretty much what's been described in this thread.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

2015-10-03 Thread Minh Nguyen


On 2015-10-03 16:58, Greg Troxel wrote:


What's wrong with the private tag?  Is the only objection that it shows
up pink on the map?  That's a clue that the rendering is wrong, not the
tag.


I was asking more out of curiosity. Personally, I'm fine with the way 
access=private driveways are rendered, and tagging driveways off 
cul-de-sacs as access=private matches how I tag the parking lots of 
apartment complexes and corporate headquarters.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Should driveways be on OSM?

2015-10-01 Thread Minh Nguyen


On 2015-09-30 08:34, Greg Morgan wrote:

On Mon, Sep 28, 2015 at 8:48 AM, Toby Murray  wrote:

I run into this as well. If I don't see anything close to the way on
imagery I definitely have very little problem deleting them.

I also question the access=private tagging although not because of the
rendering. I mean technically it is correct I suppose but if you are
trying to route to an address at the end of a long driveway, the
router should tell you to go down the driveway. Tagging it as



If this really is true, then perhaps you should file a bug report.  If
I accurately map a residential gated community with access=private,
show the gates, then wouldn't that be more valuable to set what
expectations are required to get into the area.
http://www.openstreetmap.org/way/16842943#map=18/33.78757/-111.98892


Toby is suggesting that service=driveway should imply access=destination 
unless otherwise specified. The wiki is full of statements that one tag 
implies another tag. For example, highway=motorway_link implies 
surface=paved. [1]


But you do have a point: a router could route over access=private and 
access=destination if there's no other possible route, yet avoid 
access=private otherwise (to avoid riding roughshod over a private drive 
that happens to make a good shortcut). The user interface would have to 
make clear that the route includes a private drive, similar to the toll 
road warnings that some routers give.


[1] http://wiki.openstreetmap.org/wiki/Tag:highway=motorway_link


Who are these data consumers that you speak of?  If they are
freeloaders, I could careless about them.  One of shifts that I have
noticed over the years is that we appear to no longer care about what
mappers do or how we improve the ecosystem for mappers but I hear all
about data consumers.  The data consumers need to adapt to OSM and not
the other way around.


Data consumers are part of the OSM ecosystem; we don't map in a vacuum. 
All the renderers and routers available from the osm.org front page are 
data consumers, after all. For better or worse, renderers and routers 
already "adapt to OSM" by normalizing diverse tagging styles and 
preprocessing away common errors. (A highly opinionated data consumer 
would fail to support a good chunk of the dataset.) That's not to say 
the current crop of routers is unimpeachable, but I don't think they 
should be viewed in an adversarial light.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] what happened to Sacramento?

2015-09-29 Thread Minh Nguyen

Jack Burke  writes:

> 
> You're not crazy. Just using the regular OSM website interface, I can find
the city node, and the county boundary, but not a city boundary. AFAICT, it
isn't a consolidated city-County, so it should exist. 

Looks like the original TIGER boundary way got deleted back in 2010, and I
can't find any traces of ways that superseded it:

http://www.openstreetmap.org/changeset/4084221

As a first step, I undeleted that way using Potlatch 1:

http://www.openstreetmap.org/way/33135846

Now it needs to be turned into a relation and integrated with the adjacent
boundary ways.

-- 
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Should driveways be on OSM?

2015-09-28 Thread Minh Nguyen

Nate Wessel  writes:

> 
> 
> I delete plenty of TIGER driveways myself (mostly in the midwest,
> *highfive*!), but I wouldn't say that the accurate ones should be
> removed. If they can be identified as private driveways, they could
> more easily just not be rendered on a map with no loss of accurate
> data for people who might find that sort of thing useful. My general
> approach has been to leave the truly accurate ones untouched, but to
> delete anything who's deletion leaves the map more accurate. I just
> don't feel inclined to redraw them.
> I should specify, this is my (personal) policy only for untouched
> TIGER imports.

*Highfive!*

I'd only add that, while I've never found it a priority to map most
driveways, I do try to map every shared driveway I encounter. (I look for at
least two houses attached to the same driveway.) Shared driveways are the
rural/suburban functional equivalent to urban alleys, and some subdivisions
are chock full of them. I'd want routers to be able to direct their users a
bit beyond the mailbox in those cases. To me, shared driveways are less
tedious to map and more important for routing than aisles in parking lots.

-- 
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Should driveways be on OSM?

2015-09-28 Thread Minh Nguyen

Marc Gemis  writes:

> 
> 
> They can be mapped, especially the long ones and tagged as
highway=service, service=driveway, and typically access=private.I don't care
for the appearance of the map, it's more important to connect houses that
are further away from the main road via the proper driveway to allow
navigation to the front door.
> They have been mapped in several places around the world, also in places
where there was no Tiger import.

The Standard style omits service=driveway until z16, whereas ordinary
highway=service shows up at z13. At z16, you're close enough to see any
other micromapping that might take place around the house, like fences and
backyard swimming pools. :-)

-- 
m...@nguyen.cincinnati.oh.us

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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

2015-09-21 Thread Minh Nguyen


On 2015-09-17 15:56, Toby Murray wrote:

I went through and upgraded all roads marked as "Minor collectors" and
"Major collectors" from residential to tertiary. The result can best
be seen at zoom level 12:
http://www.openstreetmap.org/relation/1070359#map=12/39.4386/-96.7724


This area looks pretty reasonable to me, except for some disconnected 
tertiaries in Fancy Creek State Park. [1]



There are a few places where I diverged from the map a bit. For
example the city of Riley has no collectors marked on the KDOT map but
I still bumped the main road through it to highway=tertiary. There
were a couple of places where I didn't really think an upgrade to
tertiary was warranted but at the time I just went with it anyway.


In cases like this, I would probably go with my own intuition. In places 
I've mapped, the DOT is less concerned about making a hierarchical map 
than about allocating funding based on the official route network. But 
it sounds like KDOT is really good about classifying based on the same 
criteria as us mappers, in which case HFCS makes for a great secondary 
source.


[1] http://www.openstreetmap.org/way/295768204

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

2015-09-08 Thread Minh Nguyen


On 2015-09-06 01:24, Toby Murray wrote:

This user has also upgraded a lot of unpaved county roads in eastern
Kansas to secondary because of HFCS which also strikes me as wrong.
You can clearly see where he has done this at zoom level 9 [6].


When I started mapping in San Jose, CA, after years of mapping in 
Cincinnati, I encountered similar problems with highway classifications. 
There were `highway=secondary` ways that, in reality, are tree-lined 
residential roads with 25 mph speed limits, Child at Play signs, and 
unsignalized crosswalks. Presumably that's because they're designated 
"major collectors" in HFCS. Residents along those streets would probably 
disagree.


Parts of downtown San Francisco and downtown Houston consist entirely of 
`highway=primary` ways with a few `highway=service`s sprinkled in. That 
kind of classification doesn't seem incredibly useful for routing, and 
it makes it more difficult to establish a visual hierarchy when styling 
a map.


In the Cincinnati area, we reserved `secondary` for good cross-town 
roads, for consistency with `secondary` state routes in rural areas. We 
demoted a grand boulevard (Central Pky., an HFCS "principal arterial" 
that's part of three U.S. routes) from `primary` to `secondary`, because 
a nearby Interstate has long obsoleted it for cross-town travel.


As I recently argued in a diary entry [1], high road classifications, 
along with umbrella landuse areas, mean that potential contributors 
won't see a blank slate where they probably should (since there may be 
little other than streets). Can we tone down these cities a bit? I think 
it would help the project.


I've come to the same conclusion as NE2 [2] that we should classify 
roads "from scratch" on a case-by-case basis and only consider systems 
like HFCS as a hint, just as we treated the TIGER import's 
classifications as a starting point. We have enough information before 
us, including aerial imagery and the overall road topology, to 
contradict HFCS when necessary.


[1] 
[2] 

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Another road classification disagreement (this time with HFCS in Kansas)

2015-09-06 Thread Minh Nguyen

On 2015-09-06 09:49, 
richiekenned...@gmail.com wrote:

As to Mr. Fairhurst’s comment regarding routing, I’ll remind you it is
frowned upon to tag for a routing engine.


There is often confusion about the "don't tag for the x" rule. We must 
not tag *misleadingly* for a *specific* x. We absolutely should consider 
the needs of all x's in existence. [1]


[1] http://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] TIGER tracing layer updated to 2015 release

2015-08-25 Thread Minh Nguyen


On 2015-08-25 20:48, Greg Morgan wrote:

I clicked on the link you provided and received:
{message:Not Found}


Hi Greg, this URL template isn't meant to be opened directly. You can 
paste it into an editor's custom layer URL field; the editor will fill 
in the {x}, {y}, and {z} variables for each tile on screen.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Rendering of tracks

2015-08-25 Thread Minh Nguyen


On 2015-08-25 19:07, Mark Bradley wrote:

I noticed that tracks (leisure - track) are still being rendered as
polygons instead of linear features, despite this having been reported
as a bug on Github.


Hi Mark, I'm not sure if the openstreetmap-carto developers read this 
mailing list. I believe you're referring to this GitHub issue:


https://github.com/gravitystorm/openstreetmap-carto/issues/574

When it comes to software like the openstreetmap-carto stylesheet, an 
issue gains more traction when someone steps forward with proposed 
source changes in a pull request. For this particular issue, it sounds 
like the developers are waiting for community consensus about how 
leisure=track should be mapped. Here's some recent discussion:


https://wiki.openstreetmap.org/wiki/Talk:Tag:leisure%3Dtrack

It may also be helpful to start a thread on the tagging@ list, if there 
isn't already one.


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] The Proposed Great Colour Shift

2015-08-22 Thread Minh Nguyen


On 2015-08-21 03:13, Colin Smale wrote:

While we are at it, what about specific symbols for train/metro stations
per operator? That is also a great landmark for map users.


I'd love to see that in the Transportation map. The difference with 
highway shields is that the Standard style is already badging highways, 
but in a format that seems foreign to people in the U.S.


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] The Proposed Great Colour Shift

2015-08-20 Thread Minh Nguyen

Paul Johnson baloo at ursamundi.org writes:

 Along these lines, the standard style as it isn't too far off from what
Americans expect out of a motorist-oriented roadmap (though mapgeeks might
see it as a bit German by comparison to our maps).  Surface streets tend
to be all the same color (usually purple or red) with the thickness of the
lines tending to be rather thin, increasing in thickness up to primary or
sometimes trunk, with motorways tending to be purple with red borders.  Toll
roads are always green, there's never ways that are green that are not
toll.  This style of rendering is almost certainly heavily influenced by
Rand McNally, given it's ubiquity for casual use maps, which traditionally
has favored as described above in a somewhat simplified, stylized form (such
as rather than each ramp mapped out in detail, an entire, possibly almost
absurdly complex junction, is simplified to a single white square
representing a motorway junction).  Rand McNally was, for quite a long time,
the official cartography provider for the American Automobile Association,
which probably helped propel this style as an expectation.  Thomas Guide
(still usually preferred by professional local drivers even when equipped
with a GPS in the US, as a single metro gets published as a lay-flat atlas
hundreds or thousands of pages long with detailed annotation, sometimes down
to building suite level, at a scale roughly equal to z20 and handy for that
last thousand feet navigation) tends to use the same form, but rather than
simplifying junctions, often goes the map porn route by mapping out
everything to scale without simplification.

A few additional observations from having used a variety of print atlases by
Rand McNally, DeLorme, and municipal suppliers:

 - Controlled-access highways (that is, motorways with dual carriageways)
are commonly colored red, amber, purple, or blue. The specific color doesn't
matter so much, just as long as it isn't green (which is reserved for toll
roads, as Paul points out). Motorways are drawn as 2-3 parallel strokes,
imitating the dual carriageways.

 - Limited-access roads (think trunk or primary) are given a single thick
stroke, colored black, except for U.S. routes, which are usually red. All
other roads are given a single, thin stroke. In the West, prominent unpaved
roads might be dashed. There usually aren't any other classifications.

 - Streets in general are very thin because each street label is placed
above the street, not on it. However, I have a few municipal maps that do
place the label inside much wider roads, giving the map a more casual feel,
less like a schematic.

 - Full motorway junctions are simplified into white squares or diamonds,
while partial junctions are half that: a thin rectangle. At higher zoom
levels, a complex junction such as a cloverleaf is drawn in full, but the
space inside it is filled in the same color as the motorway.

 - Shields are either reproduced in colors that match the signage, or
they're colored to match the road. So a map might end up with white-on-blue
Interstate shields, red-on-white U.S. route shields, and black-on-white
state route shields.

I would consider the proposed style to be closer to what a U.S. visitor
would expect than the current UK-influenced style.

-- 
m...@nguyen.cincinnati.oh.us
___
talk mailing list
talk@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk

Re: [OSM-talk] The Proposed Great Colour Shift

2015-08-20 Thread Minh Nguyen

Lester Caine lester at lsces.co.uk writes:

 Just what is the convention in the US, Russia or China?

Regarding the U.S., Paul and I describe the conventions here in detail:

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

But the short version is: real highway shields. Their absence is striking to
Americans, far more than the highway colors (which aren't as uniform in U.S.
print cartography as they are in the U.K.). There are plenty of technical
issues to work out, in any case:

https://github.com/gravitystorm/openstreetmap-carto/issues/508

-- 
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Survey Township Sections

2015-08-02 Thread Minh Nguyen


On 2015-08-02 06:43, Jerry Clough - OSM wrote:


A quick question: Are there any guidelines for tagging of public land
survey township sections?
I found a clear description of mapping civil townships for Ohio on the
wiki: http://wiki.openstreetmap.org/wiki/Ohio/Boundaries/Townships, but
have failed to find anything on survey townships and their sections.


Civil townships are being mapped because they correspond to actual 
governmental structures that have definite boundaries. Survey townships 
themselves don't have governments, so there's less of a case for putting 
them in OSM, especially where the boundary between one section and 
another is unclear from aerial imagery or on-the-ground observation.


In any case, if you map survey townships and sections, avoid using the 
boundary=administrative tag. Something like boundary=survey would be 
more appropriate.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Naming Ramps

2015-07-31 Thread Minh Nguyen


On 2015-07-30 13:51, Paul Norman wrote:

On 7/30/2015 7:15 AM, Brett Lord-Castillo wrote:

Related to this, I also wanted to look for some ideas on how to
generate names for the unnamed ramps in an OSM extract.

Most ramps in parts of the US I've traveled don't have name. What they
do have is destinations, which indicate the information on the signs.


Incidentally, the Ohio Department of Transportation does post a blue 
sign on every highway ramp, bearing a heavily abbreviated (devowelized, 
actually) name of the ramp, for example:


Ramp
E 275
 To
N 75

or:

  Ramp
  E 275
   To
Lvldmdra

In cases where the ramp belongs to multiplexed routes, you may see 
multiple ramp name signs side by side: http://www.roadfan.com/3bluemrk.JPG


These signs are specifically intended to help motorists pinpoint their 
location when calling for help. (If emergency responders look for the 
wrong ramp in a given junction, they might end up wasting precious 
minutes trying to circle back.)


I've been hesitant to put these names in the `name` tag because they 
clutter up ordinary use cases like map display and navigation. I'm 
inclined to use `official_name` here and expand all abbreviations (per 
OSM convention).


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Pequot Terrace

2015-07-13 Thread Minh Nguyen

Clifford Snow clifford@... writes:

 
 I'm vacationing near Nisswa, MN. In the city of Nisswa, there is a hamlet
node for Pequot Terrace just a short distance from the City of Nisswa node.
As far as I can discover, there is no Pequot Terrace
here. http://www.openstreetmap.org/node/151467331
 Since I don't live in Minnesota, I'd like to hear from some locals if it
is ok to delete the node. It was imported from GNIS in 2007 with a
modification a year later to add the county. 

Apparently it’s a retirement community:

http://pequotterrace.com/

The GNIS import brought in lots of mobile home parks, housing projects, and
retirement communities as hamlets. If you can figure out where in Nisswa
that community is located, a landuse=residential area might be in order.

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

Re: [Talk-us] cycle.travel US bike routing, and unreviewed rural TIGER

2015-06-14 Thread Minh Nguyen


On 2015-06-13 17:08, Harald Kliems wrote:

Very nice, Richard! One quick comment: I might not be the only who
doesn't always change the tiger:reviewed tag when fixing TIGER-imported
roads. I don't know if that's technically feasible, but maybe it would
be better to check if a way has been modified since import, independent
of the tiger:reviewed tag. I guess you could assign those a slightly
lower priority than the ones that have tiger:reviewed=yes.


You aren't alone. I stopped bothering with tiger:reviewed tags back in 
the Potlatch 1 days. It just isn't a well-designed tag:


- not very discoverable to mappers who weren't around in 2008
- not automatic enough
- doesn't say whether the names, classification, or geometry was 
reviewed, or whether the review covered the entire way


I think we generally treat tiger:* tags as cruft these days. (I 
sometimes use tiger:name_* in cleaning up erroneously merged ways or 
ways lossily unduplicated along county lines, but that's about it.)


On the other hand, ways without tiger:reviewed tags are more likely to 
have been entered by hand or rigorously reviewed, so it does make sense 
to reward such ways. But I think it'd be unfortunate to totally discount 
tiger:reviewed=no ways.


FWIW, I also leave a lot of usable paved roads as highway=residential in 
rural areas, but there are plenty of considerations that vary from 
region to region (even within a state).



On Sat, Jun 13, 2015 at 1:38 PM Richard Fairhurst
rich...@systemed.net
mailto:rich...@systemed.net wrote:

Hi all,

At State of the Map US last weekend I was really pleased to unveil
bicycle routing for the US (and Canada) at my site, cycle.travel
http://cycle.travel.

The planner, at http://cycle.travel/map , will plan a bike route for you
between any two points - whether in the same city or on opposite sides
of the continent. It's all based on OSM data but also takes account of
elevation and other factors.

I dogfooded it with a three-day ride around New York state after
SOTM-US, and it found me some lovely quiet roads in and around the
Catskills. I hope it'll be equally useful for the other two-wheelers
amongst us. There's still a lot I want to add (as detailed at
http://cycle.travel/news/new_cycle_travel_directions_for_the_us_and_canada)
but I hope you enjoy it.

Plug aside, there's a couple of things might be relevant to US mappers.


First of all, I'm aiming high with this - the aim isn't just to make the
best OSM-powered bike router of the US, but the best bike router full
stop for commuters, leisure cyclists and tourers. (I leave the
athletes to Strava!)

Here in Britain, experience over the years has been that good bike
routing and good bike cartography - historically via CycleStreets and
OpenCycleMap - are a really effective way of driving contributions to
OSM. So if you know cyclists who aren't yet contributing to OSM, maybe
throw this at them - and if it doesn't find the route they'd recommend,
maybe there's some unmapped infrastructure they could be persuaded
to add!


Second, the routing and cartography both heavily distrust unreviewed
TIGER.

In other words, it won't route over a rural road tagged as
 highway=residential
 tiger:reviewed=no

Any road with tiger:reviewed removed or altered, any road in urban
areas, and any road with highway=unclassified or greater is assumed to
be a usable paved road. (There are a few additional bits of logic but
that's the general principle.)

Unreviewed rural residentials are shown on the map (high zoom levels) as
a faint grey dashed line, explained in the key as Unsurveyed road.

I've been finding this a really useful way of locating unreviewed TIGER
and fixing it... it's actually quite addictive. :) Looking for roads
which cross rivers, or with long sweeping curves, is an easy way of
identifying quick wins. My modus operandi is to retag 2+-lane roads with
painted centrelines as tertiary, smaller paved roads as unclassified,
and just to take the tiger:reviewed tag off paved residential roads.
Anything unpaved gets a surface tag and/or highway=track.

I can't promise minutely updates I'm afraid - the routing/map update
process takes two full days to run so it'll be more monthly than
minutely. But I hope you find it as useful as I do. You'll see there's a
tiny little pen icon at the bottom right of http://cycle.travel/map
which takes you to edit the current location in OSM.


Finally, many thanks to everyone who's tested it so far, particularly
Steve All - your feedback was and continues to be enormously useful.

cheers
Richard

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

Re: [Talk-us] a plea to armchair mappers

2015-06-14 Thread Minh Nguyen


On 2015-06-11 06:42, Richard Welty wrote:

please, please when doing the armchair mapping thing, be aware
that aerial imagery may be several years out of date.

yesterday i discovered that a highway reconfiguration i'd mapped
in Rensselaer, NY had been realigned with the out-of-date bing
aerial imagery. i was able to locate my GPX tracks and put it back,
but i still had to revisit the site to re-verify some connecting roads.

i had even put a README tag on the roads warning that the
imagery was out of date, but the armchair mapper didn't bother
to, you know, read the README.


With both outdated imagery and the Ohio River [1], I've had better luck 
placing redundant `note` tags on every way that such a mapper would be 
inclined to delete. iD shows `note` in a big box in the sidebar. It's a 
bit harder to miss than a (heretofore) ad-hoc tag that would be 
relegated to the All Tags section. Potlatch 2 doesn't support anything 
like it, unfortunately.


If it gets really bad, you could try spelling out DO NOT ERASE in 
aerialway=contrail ways. :-P


[1] http://wiki.openstreetmap.org/wiki/Ohio_River

--
m...@nguyen.cincinnati.oh.us


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

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

2015-06-06 Thread Minh Nguyen

Phil phil at trigpoint.me.uk writes:

 Transliteration is something that can be done at application level, and a
traveller would have learned the basics. You still need to be able to check
the street names against.what is on the sign.
 Then why not have a single transliteration?  A single cryllic to latin
transliteration will serve all languages using the latin alphabet, do we
need separate Russian,  Ukrainian,  Serbo Croat tags when they are identical?

Transliteration is from one script to another, but many languages may share
the same script, each with its own alphabet. Thus there are almost always
multiple valid transliterations.

It gets worse, especially when transliterating to or from non-European scripts:

https://www.openstreetmap.org/user/Minh%20Nguyen/diary/35163

If you need to wayfind with OSM data, the unqualified `name` tag is your
friend: as the primary name of a feature, it stands the greatest chance of
appearing on signage.

In any case, we shouldn't limit our imagination to travelers carrying OSM
field maps or GPS units while roaming the English countryside. That use case
certainly calls for consistency with signposts, but not at the expense of
other use cases, such as OSM-based world maps, geography textbooks, board
games, etc.


___
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 Minh Nguyen


On 2015-05-31 14:19, moltonel 3x Combo wrote:

On 30/05/2015, Martin Koppenhoefer dieterdre...@gmail.com wrote:

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.


`unsigned_ref` is used almost exclusively in the U.S. [1] for certain 
kinds of route numbers that are of relatively little use to the general 
public. For example, the state legislature or highway department may 
have assigned a road or bridge a number for accounting purposes. In many 
cases, the numbers are signposted, but only in fine print on signage or 
on small signs out of view to most motorists.


This tag was most recently discussed on talk-us back in January 
regarding Pennsylvania's quadrant route system. [2]


Here's a real world example of `unsigned_ref`:

https://www.flickr.com/photos/dougtone/4176740362/

What you see in this photo is typical signage for Pennsylvania State 
Route 443 (ref=PA 443); below it is mile marker 210. At the top of that 
mile marker, in infinitesimal print, is the quadrant route designation 
SR 3009 (thus unsigned_ref=SR 3009). Most likely, the bridge itself 
has a reference number carved into either end (unsigned_ref again, I guess).


Some other states and counties handle things very differently, avoiding 
signposting legislative route or bridge numbers at all. But I'd be 
surprised if someone has actually bothered to import such numbers in 
large quantity.


It was important to avoid putting these numbers in `ref` because 
renderers and routers alike would immediately present them as ordinary 
route numbers and probably give laypeople a lot of confusion. (It'd be 
as if someone had set `name=Londres` for London.) Other than that, the 
choice of unsigned was just a matter of convenience and plainly a 
misnomer. Something like `ref:penndot` may've been more appropriate in 
examples like the one above.


[1] http://taginfo.openstreetmap.org/keys/unsigned_ref#map
[2] 
https://lists.openstreetmap.org/pipermail/talk-us/2015-January/014157.html


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Facts about the world

2015-04-04 Thread Minh Nguyen


On 2015-04-03 22:25, Russ Nelson wrote:

Greg Morgan writes:
   * In my case, TIGER isn't all the that bad.

In some NY counties, TIGER is very good. In other places it is like
Stevie Wonder was in charge of quality control. What I've heard is
that the maps they were digitizing off were of MUCH lower resolution
than we have available now.


I wonder if it was even about the resolution in some counties. It's as 
if the data was traced off a cartogram, or maybe reconstructed from a 
table of intersections.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

2015-04-04 Thread Minh Nguyen


On 2015-04-04 05:23, Serge Wroclawski wrote:

On Sat, Apr 4, 2015 at 12:31 AM, Russ Nelson nel...@crynwr.com wrote:

Brad Neuhauser writes:
If you want to know how serious abandonfans are, I've see people go
looking in farmer's fields with a metal detector looking for spikes,
and dig down 12 to find one. I've seen people go into a farmer's field
looking for chunks of coal that fell off coal trains. I've knocked on
people's doors to ask them if they know anything about the railroad in
their backyard.


That shows an incredible level of dedication, but in OSM we generally
don't require specialized equipment to contribute, including
validation.


The evidence of dismantled railroads is out there, and it should be in
OSM to help people find it.


What would you do about someone who was cleverly adding tracks that
didn't exist?

Imagine if there was a vandal who was clever. We'll call this vandal
User V. User V decides to have a bit of fun and makes dismantled
railroad ways.

How do you propose we, as a community, handle User V? My normal way of
handling such a matter, in or out of a DWG context, would be to go to
the place and see if I see what they see. But my understanding from
your mail (and you can correct me if I'm wrong) is that I personally
have the expertise to make that determination?

Who does? What makes one mapper more qualified than another mapper?
This question gets to the heart of this project, which is that we
don't make people take tests to map in OSM. This is such a generalist
project that anyone can contribute. Now you're saying that, in
essence, some features can only be evaluated by certain users.

I don't think that's really what you mean, but that's what I'm hearing.

Let me reframe the question. Instead of Yes they should be in OSM or
No they shouldn't be in OSM, here's the new question:

If a user deleted an object that a layperson can't see in OSM, what do
you think the process be for evaluating that edit should be?


I appreciate your emphasis on verification. The community necessarily 
puts in a lot of effort into data integrity, but we don't really promote 
the more manual side of QA. As OSM grows in profile, our defenses 
against vandalism will increasingly be tested. Personally, I don't find 
ground verification to be nearly as fun as mapping, but if someone's 
going to volunteer to do that work, we shouldn't throw needless 
obstacles in their way.


We should assume that verifiers are every bit as diverse as the OSM 
community at large, rather than a lowest common denominator group of 
laypeople. I'd be much better at verifying administrative boundaries 
than mountain biking trails. You shouldn't trust me to make good calls 
on mtb:scale= values, but don't stop a skilled cyclist from using that 
important tag and another skilled cyclist from verifying it.


On the other hand, mappers who feel the need to rely on detective work 
should document that work, for example by adding a note= tag or 
accompanying that railway=abandoned with some additional clues. If it 
really comes down to spikes you've dug out of the ground, an OSM diary 
post with photos can go a long way. We all love a good story!


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Facts about the world

2015-04-04 Thread Minh Nguyen


On 2015-04-02 17:41, stevea wrote:

Simon Poole writes:

Up to now OSM has drawn the line in such a way that stuff that is
signposted and is observable on the ground is fair game (with some
exceptions, I believe the GR issue is still unsolved).


Yes, all of that is fair game.  Though I don't know what the GR issue
is, and ask you to please clarify.


If you are using
a collection of facts, be it a list, a map, a file on a computer or
whatever, we have to now always taken the, fairly high ground, position
that you either need explicit permission (by agreement, licence or
similar) or that the use of the source is clearly not subject to
copyright any longer. Forgetting about other rights, regulations etc
that may exist for the purpose of this discussion.


When a collection of facts about the world are data published by a
government (around here, those are our employees), ESPECIALLY if/as one
is in a jurisdiction where geo data published by us (via the government)
are explicitly prohibited to be encumbered by copyright or onerous
Terms -- as I do -- then use of those data flowing into OSM should be
absolutely uncontroversial.  As the explicit example I used in the
instant case, road/rail crossing data published by our PUC that became
reverse-engineered names of subdivisions sufficient to tag
nastily-tagged TIGER data (just plain wrong, but better than nothing and
an OK starting place) so they are more correct is a perfectly valid use
of such data.  I believe anybody in any of the 49 other states can do
this, but I am not as familiar with their Public Records Acts (or/stare
decisis/) as I am California's.  Nor am I an attorney.  But I can read
and make these determinations.  In fact, I believe any reasonably
intelligent adult can do so.  If we can't, it is incumbent upon OSM to
help us do better.  Erring on the side of high ground safety might be
a good place to plant an initial flag, but if it's location is wrong and
we need to move it to a more accurate place, we must do so.


Not every state's public records law is as generous as California's. For 
instance, the Ohio Attorney General's office publishes an annual 
Sunshine Laws Manual [1] that interprets the sunshine law as providing a 
right for public inspection and authorized copying of public records, 
but not necessarily a right to create and distribute unauthorized 
derivative works. Assuming that position is correct, we can't 
automatically treat a PUCO publication as a potential import source. 
Unfortunately, Ohio is no exception. That said, I'm nobody's idea of an 
IP lawyer and I'd love to be proven wrong in this instance.


Moreover, I think Simon and Frederik are arguing from the perspective 
that compliance with U.S. copyright law is necessary but insufficient 
for OSM. To European contributors, concerns over copyright are 
compounded by concerns over moral rights and database rights, hence the 
requirement for explicit permission. I'm uncomfortable with the notion 
of imposing European legal restrictions on American imports, but this 
discussion is more about what *should* be included than what *may* be 
included. A Wikipedia administrator would swiftly delete a perfectly 
copyright-free article about your backyard swing set for being 
unencyclopedic; likewise, the OSM community can decide that 
large-scale inclusion of certain outside sources would take the project 
too far from its founding mission.


OSM started out with the do-it-yourself, clean room approach of 
on-the-ground surveying. It offers the strongest guarantee of legal 
compliance and appropriateness for OSM -- no legal analysis required. 
All of us certainly hold such efforts in the highest esteem, but I do 
see an argument for letting contributors be resourceful in other ways, 
to *carefully and judiciously* incorporate other sources, as long as 
they do their best to document their work.


[1] http://www.ohioattorneygeneral.gov/YellowBook

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

2015-04-01 Thread Minh Nguyen


On 2015-03-31 23:12, Bryce Nesbitt wrote:

For background, in the USA there is an intermediate step to
abandonment.  A corridor can be railbanked,
meaning the easements don't expire.  It's not an active railway, but
it can be returned to rail service
via an administrative procedure.  And in fact, that's happened.
Usually however these become trails,
a process that can take decades.


I'd imagine that most railbanked rights of way would be mapped with 
railway=disused (inactive tracks, possibly overgrown) or 
railway=abandoned (no tracks but an embankment, greenway, or clearing 
still present), as opposed to something like railway=razed. [1] The 
tags' definitions acknowledge physical characteristics rather than 
ownership. I don't think we need a tag about railbanking specifically, 
although a note tag may be helpful as a reminder to future mappers. The 
nice thing about railway=abandoned is that it can be combined with 
highway=cycleway once a rail trail is built on the old grade.


[1] http://wiki.openstreetmap.org/wiki/Demolished_Railway

--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

2015-03-31 Thread Minh Nguyen


On 2015-03-31 00:36, Frederik Ramm wrote:

Hi,

On 03/31/2015 08:04 AM, Natfoot wrote:

There is so many situations where to his naked eye on the ground he may
not be able to see it.  To a person like myself I can still find the
signs on the earth of where the railroad once was.


Then map the signs that *are*, but not the railroad which - as you
correctly say - once *was*.


For many rights of way, the main remaining feature is a greenway cutting 
across farmland -- something you can easily armchair map, even. 
Personally, I'd rather map that ROW as a railway=abandoned way than as a 
natural=wood area, just as I avoid mapping roads as areas. On the 
ground, meanwhile, you'd tend to find no trespassing signs on railbanked 
ROWs, no?


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] Moving historic railroad ways from OSM to OpenHistoricalMap

2015-03-30 Thread Minh Nguyen


On 2015-03-29 05:00, Mark Bradley wrote:

Hello list.  I have been communicating with a mapper who says he has
been deleting abandoned railroads (the ones where the infrastructure is
totally removed).  As the premise of OSM is to only map
ground-verifiable features (other than certain boundaries), I didn't
want to argue with him, but I don't want to see this information lost
either.  I said I would look into transferring those ways to
OpenHistoricalMap.  Yesterday he sent me a message, saying he's
identified two more abandoned railroads and he's giving me the
opportunity to act on them before they get deleted.  Can I export these
ways from OSM and then import them into OHM?  Or is there a better way
or some other solution?


Just wanted to point out that there's still a place in OSM for mapping 
railroad rights-of-way where the tracks have been pulled out but the ROW 
is still reserved and discernible. The Standard style no longer renders 
railway=abandoned, but it can still be a useful navigational landmark.


In any case, I've CC'd the OpenHistoricalMap list, where all the experts 
hang out these days.


--
m...@nguyen.cincinnati.oh.us


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

Re: [OSM-talk] New features in iD - looking for feedback and beta testers..

2015-03-29 Thread Minh Nguyen


On 2015-03-27 14:55, Dave F. wrote:

Until there's a logical, common sense way to select, split, continue 
unstitch ways that meet at intersections, I'm sticking with P2.


As a power user, I found these operations a lot less frustrating after 
discovering that selecting a way, holding down Shift, and selecting the 
intersecting node limits the split, disconnection, or extension to just 
that way.



And why the delete key isn't utilized is beyond me. Leaving out basic
functionality doesn't make iD easier to use.


Press Ctrl+Del or Ctrl+Backspace to delete the selected feature. The 
modifier key was added [1] in response to complaints that iD was making 
it too easy to delete stuff. [2]


FWIW, the wiki has a full list of shortcuts. [3]

[1] 
https://github.com/openstreetmap/iD/commit/b52eb9ce72653b538d025ca93f9264690d0bd398

[2] https://github.com/openstreetmap/iD/issues/1698
[3] http://wiki.openstreetmap.org/wiki/ID/Shortcuts

--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

2015-03-27 Thread Minh Nguyen


On 2015-03-25 09:54, Bryce Nesbitt wrote:

There are many defacto boundaries created by roads, hedges, powerlines,
ridges or bodies of water.

I argue the most appropriate boundary in OSM is indeed the defacto
boundary.  If people are using, paving, weeding
and farming the boundary, that's the one we can map.

The legal boundary is not something OSM can adjudicate.  Finding that
boundary is a complex process involving survey points, land
descriptions, and often handwritten records stored in dark basements.
It also hardy ever matters, at least to a mapper or map reader.


That may be true when it comes to private property, but the de jure 
boundary of a given village, county, etc. matters to many members of the 
general public, all of whom could wind up reading our map. To the extent 
that a given place has a de facto boundary -- which I take to mean a 
boundary not *administered* by a government -- we shouldn't map it as an 
*administrative* boundary, and we should avoid mapping overly subjective 
data in fine detail anyways.


I would imagine that administrative boundaries like city limits are a 
matter of public record. Granted, the public record isn't necessarily 
free or online, and the city may well store it in a dark basement. But 
where we can ascertain the legal definition of a city limit while 
respecting our copyright policies, we provide a valuable service by 
turning that prose into free geodata correlated with other features like 
roads. TIGER gets us most of the way there for city limits but not for a 
major city's political subdivisions.


--
m...@nguyen.cincinnati.oh.us


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

[Talk-us] Re: Boundaries and verifiability (was Re: Retagging hamlets in the US)

2015-03-27 Thread Minh Nguyen


On 2015-03-25 08:12, Martijn van Exel wrote:

On Wed, Mar 25, 2015 at 3:00 AM, Minh Nguyen wrote:

On 2015-03-24 13:57, Martijn van Exel wrote:

More importantly though, there is an authoritative source for
official administrative boundaries that can be easily accessed by
anyone: TIGER[1]


You mean the way TIGER is an authoritative source for road
centerlines? TIGER's boundaries vary in quality just as its roads
and railroads do. I've taken quite a few imported municipal
boundaries, lined them up with road easements or hedges between
farms _when that is obviously the intent_, and deleted extra nodes.
These borders become far more accurate and precise in OSM than in
commercial maps, which regurgitate TIGER boundaries verbatim.


The most authoritative source for most U.S. land borders, going all
the way down to the parcel level, is a legal prose definition in
conjunction with any number of monuments on the ground. Both metes
and bounds and the Public Land Survey System rely on monumentation.
A monument may be a major road or as obscure as a small iron pin
embedded in that road, but even that pin is verifiable if not
particularly armchair-mappable.


If you're lucky, you can find an Ohio city limit's legal definition
in county commissioners' minutes when an annexation is proposed. The
most authoritative data representation is the county GIS database,
which anyone can easily access -- for a fee. After paying the county
for that database, you might well forget about OSM, because it's
also the authoritative source for road centerlines and names.


That is actually not what I meant, but I could have been more precise. I
guess this turns into a discussion of what 'authoritative' actually
means. This is different things to different people. As OSM becomes
better, increasingly folks will start looking at us for
authoritativeness, which would make sense because everything is
(supposed to be) verified on the ground. Because administrative
boundaries have legal implications, the authoritative source will need
to be someplace outside of OSM. It may actually hurt OSM down the line
if we include information that suggests authoritativeness we cannot
provide.


OK, thanks for clarifying. One risky use of administrative boundary data 
at the local level would be for tax purposes. Obviously we don't want 
people relying on OSM to decide whom to pay taxes to. That's why we have 
a disclaimer. [1] It should get more prominence. Wikipedia's legal and 
medical disclaimers are two hops away from every article, but ours is 
two hops from the wiki's main page only. At least consumer-focused 
redistributors of OSM data tend to have more accessible disclaimers.


[1] http://wiki.osm.org/wiki/Disclaimer


Sure, but vernacular and official neighborhood objects would then need
to be represented differently so folks can tell them apart and know what
they are dealing with.


I agree entirely, and I think OSM is already set up for these 
distinctions. If you see a boundary=administrative admin_level=10 
relation on the map, you'd expect it to be an official (aka 
administrative) boundary, not a vernacular one. If you see a 
place=neighborhood POI with the name tag, you'd expect both definitions 
to be roughly equivalent. A purely vernacular neighborhood would be a 
POI probably tagged with loc_name instead of name.


--
m...@nguyen.cincinnati.oh.us


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

Re: [Talk-us] user damages administrative boundaries around Rapid City

2015-03-26 Thread Minh Nguyen

arch_arch@... arch_arch@... writes:

 I've detected a user who damages administrative boundaries around Rapid
City. I've tried to contact the
 user but I got no reaction. I've told the mapper that iD editor is
inappropriate, as it has no built in
 validator but he didn't stop the edits.
 
 I want to ask someone from the US to take care of the case and to involve
the Data Working Group if necessary.
 
 This boundary got deleted: http://www.openstreetmap.org/relation/194816
 invalid geometry: http://www.openstreetmap.org/relation/195005
 invalid geometry: http://www.openstreetmap.org/relation/194808
 deleted relation: http://www.openstreetmap.org/relation/194807

It's clear that the user simply meant to remove the CDP boundaries (194816
and 194807), an action that many of us on this list (but maybe not all)
would approve of. [1] Unfortunately, the user removed the CDP boundaries by
deleting all the ways that belong to the CDP's relation, roping in members
of neighboring non-CDP boundary relations.

The good news is that Richard Fairhurst patched iD to prevent errors like
this in the future. [2] The bad news is that the fix didn't make it into
1.7.0, the version currently on osm.org. So in the meantime we'll have to
rely on user education.

Echoing Greg's comments, even experienced mappers sometimes hop into iD or
Potlatch to make quick edits. These editors may not be as mature as JOSM
when it comes to relations, but it isn't necessary to dismiss them out of
hand. When it comes to educating new mappers about data entry errors, I've
found them to be more receptive to messages like please be careful; here's
what to watch out for.

Thanks for bringing up this topic. It's an opportunity to remind mappers new
and old to review their changesets before saving. iD's save panel lists
changes along with validator warnings for some common errors. [3] If iD's
validator is missing a check you consider useful, I'm sure the developers
would appreciate a bug report. [4]

[1] For example, see this thread:
https://lists.openstreetmap.org/pipermail/talk-us/2015-January/014075.html
[2] https://github.com/openstreetmap/iD/pull/2526
[3] https://github.com/openstreetmap/iD/blob/master/js/id/validate.js
[4] https://github.com/openstreetmap/iD/issues


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

1 2 3 >

1 - 100 of 221 matches

Mail list logo