[Tagging] [Voting] Feature proposal - tagging solar panel trackers

[Clay Smalley]

Voting has started for the solar tracker tagging scheme.

Please cast your vote here:
https://wiki.openstreetmap.org/wiki/Proposal:Solar_Panel_Trackers

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

[Tagging] [RFC] Feature proposal - tagging solar panel trackers

[Clay Smalley]

Following discussion on the forum [1], I’ve developed a tagging proposal to
indicate the existence and type of solar tracker on solar panels and
thermal collectors.

Since I started last month at Global Energy Monitor, I’ve single-handedly
added thousands of instances of solar:tracking=* and have become the
majority user of it. There was no documentation of this tag at the time,
and the de facto tagging scheme had two redundant values describing the
same thing. As mapping coverage of this feature grows, it will need a
clearly defined set of tag values.

See the wiki page here, and discuss on the talk page:
https://wiki.openstreetmap.org/wiki/Proposal:Solar_Panel_Trackers

[1]
https://community.openstreetmap.org/t/tag-for-solar-panel-tracking-fixed-single-axis-or-dual-axis/100869
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [Voting] Level crossing train horn usage

[Clay Smalley]

Voting has started on the proposal to introduce the key crossing:whistle=*.

Please vote on the wiki page
https://wiki.openstreetmap.org/wiki/Proposal:Level_crossing_train_horn_usage

(posted here by request of UrbanUnPlanner in
https://community.openstreetmap.org/t/voting-feature-proposal-level-crossing-train-horn-usage-quiet-zones-whistle-bans/100171
)
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

[Tagging] [RFC] Feature Proposal - Level crossing train horn usage (quiet zones, whistle bans)

[Clay Smalley]

Cross-posted from the forum [1]:

This proposal consists of a tag on railway crossing nodes to denote that
> train-horn (whistle) operation at said crossing is different from national
> law/standard (US quiet zones/Canadian whistle bans, wayside horn
> operations, or places on a rail network where trains need to use their
> horns despite such not normally being required). See Proposed
> features/Level crossing train horn usage [2] for the details, and please
> discuss this proposal on its Wiki Talk page.
>

[1]
https://community.openstreetmap.org/t/rfc-feature-proposal-level-crossing-train-horn-usage-quiet-zones-whistle-bans/97053
[2]
https://wiki.openstreetmap.org/wiki/Proposed_features/Level_crossing_train_horn_usage
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Inclined elevators

[Clay Smalley]

On Fri, Dec 4, 2020, 6:30 PM Guillaume Chauvat  wrote:

> Sorry for spamming.
>
> I also think it's fine if the Montmarte funicular is tagged as a
> funicular. But I'm asking because of things that are clearly elevators,
> like this one:
> https://www.alamy.com/stock-photo-tekniska-hgskolan-metro-station-stermalm-district-stockholm-sweden-41948022.html
> . It goes on a path parallel to the escalators, not vertically (I have been
> inside). To me it looks very wrong to call this a funicular. But maybe
> others disagree...
>

I guess I missed the beginning of the discussion. I agree with you that
this particular inclined elevator doesn't really resemble a funicular and
shouldn't be tagged as such. If it's indoors or operates on demand by a
button press, tagging it as an elevator in some way would be more
appropriate (though I'm still unclear on the best way to do so).

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

Re: [Tagging] Inclined elevators

[Clay Smalley]

On Fri, Dec 4, 2020, 5:00 PM Joseph Eisenberg 
wrote:

> The wiki page text says that a railway=funicular is "A funicular, also
> known as an inclined plane or cliff railway, is a cable railway in which a
> cable attached to a pair of tram-like vehicles on rails moves them up and
> down a steep slope, the ascending and descending vehicles counterbalancing
> each other.”
>
> However, the description in the infobox (which is much more commonly seen
> in places like taginfo and iD) is only “Cable driven inclined railway” -
> and this could include many types of "inclined elevators” which mostly run
> on rails too. So mappers might be using railway=funicular for inclined
> elevators already.
>

Indeed they are. For example, here's the Montmartre Funicular in Paris,
which was historically a true funicular but is now technically a pair of
inclined elevators: https://www.openstreetmap.org/way/29403578

The distinction between a funicular and an inclined elevator is to me a
technical one. Many inclined elevators, like the previous example, are
named as funiculars, and passengers may not even notice that they are on
one or the other - for all they know, they're just on a vehicle going up
and down steeply sloped rails.

I'm in favor of tagging inclined elevators as funiculars whenever they may
resemble one. Perhaps an additional tag like
railway:funicular=inclined_elevator could be invented for those interested
in the technical details on how the steep-slope-railway-thing works.

-Clay

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

Re: [Tagging] Extremely long Amtrak route relations / coastline v. water

[Clay Smalley]

On Sun, Nov 22, 2020 at 11:12 AM Dave F via Tagging <
tagging@openstreetmap.org> wrote:

> On 22/11/2020 11:24, Richard Fairhurst wrote:
>
>
> I sincerely hope "I'm in favor of fixing" translates as "I'm planning to
> fix", though I fear I may be disappointed.
>
> More broadly, we need to nip this "oh just fix the tools" stuff in the
> bud. (etc)
>
>
> Likewise we need to stop software developers from expecting contributors
> to add data purely because they can't be bothered/not competent enough to
> write a few lines of code. (OSM-carto demanding boundaries on ways &
> numerous routers expecting multiple foodways to criss-cross pedestrian
> areas, are just two examples)
>
> Contributing to the database (also *volunteers*) are expected to map to a
> certain standard. There shouldn't be a reason to expect develops not to do
> the same.
>

If it's so easy, why don't you write the "few lines of code" necessary to
fix this issue?


> Desiring relations to list in their entirety is *not* a "0.1% case".
> Splitting them into 'super relations' should not be the desired, final
> solution.
>

Amtrak routes, like many other public transit routes, are already split
into super-relations (see [1], [2]). This is a non-issue. I've already
decided to split up long-distance Amtrak routes into more manageable
chunks, especially since I'm the one who takes on most of the work of
managing them. My original question was *how* to split them up, not
*whether* to split them. I'm not convinced that attempts to persuade me not
to do so are helpful in any way, so I'm going to consider them off-topic
and ignore them.

-Clay

[1] https://wiki.openstreetmap.org/wiki/Relation:route_master

[2] https://wiki.openstreetmap.org/wiki/Amtrak
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Unverfied Edits, Reverting Tags

[Clay Smalley]

On Mon, Oct 12, 2020, 10:31 AM Hartmut Holzgraefe <
hartmut.holzgra...@gmail.com> wrote:

> On 2020-10-12 15:51, 80hnhtv4agou--- via Tagging wrote:
> > DWG and the foundation, are not in the verification and editing
> > business, so who is ?, under penalty of banning.
>
>
> context?
>

He got banned for being a dick:
https://www.openstreetmap.org/user_blocks/3979

He's probably just complaining that I'm reverting his edits for a second
time. It's getting old.

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

Re: [Tagging] [Talk-transit] [OSM-talk] Call for verification (Was: Re: VANDALISM !)

[Clay Smalley]

Everyone knows who you're talking about at this point, and nobody cares.
Use the remaining day or so of your temporary ban to work on some hobbies
outside of OpenStreetMap.

And be careful about who you say isn't local. I'm moving to Northern
Indiana next week and I'll certainly get the chance to survey many of the
estimated stop positions I remotely mapped. I hope to see you around as we
continue working on the same things.

On Sat, Aug 22, 2020, 12:21 PM 80hnhtv4agou--- via Talk-transit <
talk-tran...@openstreetmap.org> wrote:

> it was one person in CA adding 400 unverified tags to rail service in
> chicago.
>
> one just 818 m, away from my home.
>
>
> SATURDAY, August 22, 2020 12:32 PM -05:00 from Martin Koppenhoefer <
> dieterdre...@gmail.com >:
>
> sent from a phone
>
> > On 22. Aug 2020, at 10:15, pangoSE  wrote:
> >
> > Here is yet another example of bad data in our database:
>
> fix it ;-)
>
> Of course OpenStreetMap contains errors, just like any other source, and
> probably more, given that most contributors are laymen and have very few
> experience (few total edits, often just 1).
>
> On the other hand, we may be very fast when something changes, very
> flexible in emergencies (think Haiti), and have interesting niche data that
> commercial and public data providers don’t care for.
>
> It all depends on the local community in the end. If you have reached a
> critical mass to have locals everywhere, it will work great and bugs will
> wash out. Otherwise the data might get stale just like any other data. Also
> using the data is essential to find the problems, for example the 212 story
> garage is likely fixed now ;-)
>
> I tend to agree with Steve A.
>
> Cheers Martin
> ___
> talk mailing list
> t...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk
>
>
>
>
>
>
>
>
>
>
> ___
> Talk-transit mailing list
> talk-tran...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] [Talk-us] VANDALISM !

[Clay Smalley]

For those who aren't following, the DWG recently decided on a two-day ban
for the person who posted this, for the exact behavior they're exhibiting
right now: https://www.openstreetmap.org/user_blocks/3850

jdd 3, please take a break. You have better things to do.

I look forward to when you demonstrate the ability to communicate
collaboratively.

Best,
Clay

On Fri, Aug 21, 2020 at 6:08 PM 80hnhtv4agou--- via Talk-us <
talk...@openstreetmap.org> wrote:

> FYI;
> https://wiki.openstreetmap.org/wiki/Vandalism
>
> Purposeful removal or degradation of data that are known to be correct,
>
> Deliberate adding incorrect data;
>
> People who revert other people's work should expect to be able to
> demonstrate that the reversion was well reasoned and proportionate to the
> issue.
>
> Not There;
> Unverified  if someone puts in 400 +  unverified tags in one edit,
>
> If someone reverts, 400 + edits,  in one edit, done on good faith by
> others over the years to conform to there way of thinking,
>
> If someone deletes, 400 + edits,  in one edit, done on good faith by
> others over the years to conform to there way of thinking,
>
> If someone refuses to let others, edit because they have taken over
> that type edit, all bus stops in the same area,
> all train stations in the same area, all boundaries in the same area.
>
> Edits that do not conform to the subject wiki.
>
> if someone downloads data that will create one mulitipolygon, against all
> wikis
>
> Also there is no wiki on unverified edits.
>
>
> ___
> Talk-us mailing list
> talk...@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-us
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] We should stop using hyphens to denote address ranges

[Clay Smalley]

If you

On Tue, Aug 18, 2020 at 12:51 PM Colin Smale  wrote:

> On 2020-08-18 20:55, Clay Smalley wrote:
>
> On Tue, Aug 18, 2020 at 11:26 AM Colin Smale 
> wrote:
>
>> There are two use cases here: one is "what is the address of this
>> building (or whatever)" and the other is the reverse situation: "where can
>> I find number XXX". As long as we have tagging that is potentially
>> ambiguous we won't be able to cover both.
>> In the US I know of cases where an apartment number can follow the street
>> address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I
>> know of the suffix being used to indicate apartment number, or floor number
>> - e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other
>> characters are used for the floor/flat such as A/B/C or I/II/III - in these
>> cases it is unambiguous because it is non-numeric.
>>
>
> Can you point out some examples? I've never seen that syntax used in US
> addresses.
>
>
> If you mean the US example, some friends were living in Long Island City,
> Queens, NY, and their apartment address was something like 1100-157 50th
> Ave. The other examples are possibly typically European. Here in the
> Netherlands there are all kinds of notations in use for sub-units. The
> national addressing standard has a field for an alphanumeric "house number
> suffix" for this that people in IT know about, but the average Johan might
> not know what a "huisnummertoevoeging" is. Normally the full number,
> including the suffix, is written together with some kind of separator.
>

I think you misunderstand hyphenated addresses in Queens. The second part
of the hyphenation is not a flat/apartment number. As an example, the
Dunkin Donuts at the corner of 31st St and 36th Ave has an address of 31-02
36th Ave, with no apartment number. The US Postal Service considers this to
be equivalent to 3102 36th Ave, and will deliver mail to the same place
regardless of whether you include the hyphen, though the address written on
the entrance is hyphenated. Most building numbers in Queens have a hyphen
before the last two digits.

There are also areas where the whole neighbourhood has a single street
> name, and everybody has a very long house number; the initial digits of the
> house number indicate the specific road within the neighbourhood. Sometimes
> these house numbers are written as 123-45 to aid navigation.
>

Examples?

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

Re: [Tagging] We should stop using hyphens to denote address ranges

[Clay Smalley]

On Tue, Aug 18, 2020 at 11:26 AM Colin Smale  wrote:

> There are two use cases here: one is "what is the address of this building
> (or whatever)" and the other is the reverse situation: "where can I find
> number XXX". As long as we have tagging that is potentially ambiguous we
> won't be able to cover both.
>
> In the US I know of cases where an apartment number can follow the street
> address, i.e. 10-321 meaning Street Address 10, apartment 321. In Europe I
> know of the suffix being used to indicate apartment number, or floor number
> - e.g. 379-3 meaning Street Address 379, Floor/Flat 3. Sometimes other
> characters are used for the floor/flat such as A/B/C or I/II/III - in these
> cases it is unambiguous because it is non-numeric.
>

Can you point out some examples? I've never seen that syntax used in US
addresses.

On the other hand using the "1-5" notation to indicate a range is pretty
> well understood in the UK at least. What it is missing is the
> "interpolation" value (even, odd, all).
>
> So let us sort this mess out by defining:
> 1) that a hyphen indicates a range
> 2) sub-addresses like a floor or apartment number must not use the hyphen
> notation, but must be given in addr:unit
> 3) an address using the range syntax should indicate the interpolation
> scheme by means of addr:interpolation=*
>

This leaves the situation in Queens, NY unsolved, where hyphenated
addresses do not indicate ranges.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Clay Smalley]

You really need to stop calling people's edits "fake". It's disrespectful.
You're not in a position to determine whether my edits were estimation or
actually fictitious data.

It's an especially shitty thing to email me privately to lob personal
attacks at me after it becomes clear the community here doesn't share your
feelings.

Please do not email me or privately message me anymore. If you have
anything to say about me or my work from now on, you can say it in a public
forum.

-Clay

On Tue, Aug 11, 2020 at 3:32 PM <80hnhtv4a...@bk.ru> wrote:

> i have to reply,
> and yes i can fix the system that till has the signs.
> but even then the guy driving does not see it that way.
> the stops are fake because that is not the way the it works here thus a
> fake map.
>
>
> Tuesday, August 11, 2020 12:53 PM -05:00 from Clay Smalley <
> claysmal...@gmail.com>:
>
> What exactly is your point here? If nobody is responding to your
> complaints, perhaps they aren't worth responding to. Repeating the same
> complaints to the same group of people won't change that.
>
>
> Are you worried that incorrectly-mapped stop positions endanger people's
> safety?
>
> We've pointed out concrete steps you can take to improve these
> initially-mapped stop positions. If mapping stop positions accurately is
> important to you, why not take responsibility for improving them?
>
> -Clay
>
> On Tue, Aug 11, 2020 at 8:48 AM 80hnhtv4agou--- via Tagging <
> tagging@openstreetmap.org
> > wrote:
>
> this is missing my original talk.
> IN the chicago area we have 3 railway company’s operating the system, and
> one had signs left up from the old days
>
> which in watching the train come into that stations platform did not stop
> at the sign based on the number of cars + the
>
> diesel engines or engines. which could be 5, 6, 7, or 8 cars, we stop at 8
> here. 1 or 2 engines.
>
> i should say more here, 1.who is driving the train, 2.what co. does he
> work for, 3.how long is the train,
>
> 4.how long is the platform, 5 what is the time of day, am rush, pm rush,
> midday, evening. 6. out of all the cars what are
>
> being used, open, 7. weekend, or week day, 8.raining or snowing, 9.end of
> the line, 10.is the platform so short
>
> that only 2 cars will fit. 11.is the train pushing or pulling. (it does
> not work here you can not tag all 400 platforms the same.)
>
>
> Monday, August 10, 2020 10:51 PM -05:00 from Warin <61sundow...@gmail.com
> <http:///compose?To=61sundow...@gmail.com>>:
>
> On 11/8/20 1:11 pm, 80hnhtv4agou--- via Tagging wrote:
>
> the train or trains do not stop where he says they do,
>
> Do they stop at the platform? Yes.
> So stop positions maybe mapped.
>
> and i am talking about 400 +,
> unverified platforms. which is 200 + stations,
>
> Unverified? Verified by the existing signs? This maybe 'out of date' but
> still verifiable.
>
>
> How 'inaccurate' are the present stop positions?
> How precise is the mapped position required?
>
> Were there stop positions there before?
>
> Is it not better to have some indication rather than nothing?
>
>
> "They will stay there for ever" unless someone improves them.
>
>
> Monday, August 10, 2020 9:33 PM -05:00 from Warin <61sundow...@gmail.com>:
>
> On 11/8/20 9:25 am, 80hnhtv4agou--- via Tagging wrote:
>
> one of the points that i talked about, that no one has answered yet is
> what about someone not local
>
> who just puts 400 + unverified stops on platforms and there all wrong.
>
>
> If you find something wrong - correct it.
>
>
>
> If the things mapped are deceitful, malicious etc then report it to the
> DWG to prevent more of the same.
>
> If the things mapped are better than what was there before then I would
> call them improvements and thus beneficial, no point in being upset by it.
>
> Being local is not a requirement to map, get over it. Local knowledge is
> beneficial as it aids mapping things that have local characteristics - like
> where trains stop
>
>
>
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> 
> https://lists.openstreetmap.org/listinfo/tagging
>
>
>
>
>
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Clay Smalley]

What exactly is your point here? If nobody is responding to your
complaints, perhaps they aren't worth responding to. Repeating the same
complaints to the same group of people won't change that.

Are you worried that incorrectly-mapped stop positions endanger people's
safety?

We've pointed out concrete steps you can take to improve these
initially-mapped stop positions. If mapping stop positions accurately is
important to you, why not take responsibility for improving them?

-Clay

On Tue, Aug 11, 2020 at 8:48 AM 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

> this is missing my original talk.
> IN the chicago area we have 3 railway company’s operating the system, and
> one had signs left up from the old days
>
> which in watching the train come into that stations platform did not stop
> at the sign based on the number of cars + the
>
> diesel engines or engines. which could be 5, 6, 7, or 8 cars, we stop at 8
> here. 1 or 2 engines.
>
> i should say more here, 1.who is driving the train, 2.what co. does he
> work for, 3.how long is the train,
>
> 4.how long is the platform, 5 what is the time of day, am rush, pm rush,
> midday, evening. 6. out of all the cars what are
>
> being used, open, 7. weekend, or week day, 8.raining or snowing, 9.end of
> the line, 10.is the platform so short
>
> that only 2 cars will fit. 11.is the train pushing or pulling. (it does
> not work here you can not tag all 400 platforms the same.)
>
>
> Monday, August 10, 2020 10:51 PM -05:00 from Warin <61sundow...@gmail.com
> >:
>
> On 11/8/20 1:11 pm, 80hnhtv4agou--- via Tagging wrote:
>
> the train or trains do not stop where he says they do,
>
> Do they stop at the platform? Yes.
> So stop positions maybe mapped.
>
> and i am talking about 400 +,
> unverified platforms. which is 200 + stations,
>
> Unverified? Verified by the existing signs? This maybe 'out of date' but
> still verifiable.
>
>
> How 'inaccurate' are the present stop positions?
> How precise is the mapped position required?
>
> Were there stop positions there before?
>
> Is it not better to have some indication rather than nothing?
>
>
> "They will stay there for ever" unless someone improves them.
>
>
> Monday, August 10, 2020 9:33 PM -05:00 from Warin <61sundow...@gmail.com>:
>
> On 11/8/20 9:25 am, 80hnhtv4agou--- via Tagging wrote:
>
> one of the points that i talked about, that no one has answered yet is
> what about someone not local
>
> who just puts 400 + unverified stops on platforms and there all wrong.
>
>
> If you find something wrong - correct it.
>
>
>
> If the things mapped are deceitful, malicious etc then report it to the
> DWG to prevent more of the same.
>
> If the things mapped are better than what was there before then I would
> call them improvements and thus beneficial, no point in being upset by it.
>
> Being local is not a requirement to map, get over it. Local knowledge is
> beneficial as it aids mapping things that have local characteristics - like
> where trains stop
>
>
>
>
>
>
>
>
> ___
> Tagging mailing list
> Tagging@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Fwd: Re[2]: PTv2 public_transport=stop_position for stop positions that vary based on train length

[Clay Smalley]

On Mon, Aug 10, 2020 at 4:27 PM 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

> one of the points that i talked about, that no one has answered yet is
> what about someone not local
>
> who just puts 400 + unverified stops on platforms and there all wrong.
>

Again, is there a reason you're not referring to me by name? It's getting a
little on my nerves.

I'll answer your question, though. If you want to verify and reposition
them, go ahead. If you want to add more stop_position nodes to reflect
train lengths, please feel free. Otherwise, if they still bother you,
perhaps you can leave them alone and let others improve them.

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

Re: [Tagging] PTv2 public_transport=stop_position for stop positions that vary based on train length

[Clay Smalley]

On Sun, Aug 9, 2020 at 9:06 AM 80hnhtv4agou--- via Tagging <
tagging@openstreetmap.org> wrote:

> in the chicago area we have 3 railway company’s operating the system, and
> one had signs left up from the old days
>
> which in watching the train come into the stations platform did not stop
> at the sign based on the number of cars + the
>
> diesel engines or engines. which could be 5, 6, 7, or 8 cars, we stop at 8
> here. 1 or 2 engines.
>
> to that end a california editor tagged all 200+ stations with the stop tag
> that is 400 + unverified platforms.
>

You can refer to me by my name if you want :)

Part of my rationale for adding the stop_position nodes and stop_area
relations to all North American train stations was to prevent many of the
errors Alexey brought up. If the ptv2 elements of a station are completely
mapped, nobody is tempted to change stop_positions to stations, etc. Other
North American rail mappers seem to have appreciated my work doing this,
though I'm open to criticism.

i would say more but you people do not like that.
>

Say more, as long as your criticism is constructive.

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

Re: [Tagging] Ahkwesáhsne, a territory of the Kanien'kehá:ka Nation of the Haudenosaunee Confederacy Was:Should admin_level=1 tag be applied to EU?

[Clay Smalley]

Chiming in as another settler. I really wish we had more Natives active on
OSM contributing their cultural knowledge. What could we be doing different
in the future to welcome and engage them in our community?

On Sat, Aug 1, 2020 at 12:28 PM Kevin Kenny  wrote:

> Both the US and Canada consider the river to be the US-Canada boundary,
> and that the reservations are their separate dependencies. The Canadians
> recognize the Six Nations as domestic dependent nations, and they enjoy
> limited sovereignty on their own lands.
>

I think what you've said here hints at the answer. The US and Canada are UN
member states with international recognition, each with an autonomous
region under indigenous governance. The tribal governments themselves may
dispute this, which is fair. Perhaps one day they might have an
internationally recognized sovereign state with defined borders. But on the
ground as of 2020, there are no such states, only subnational autonomous
regions.

So I think the current tagging makes sense. Though I wonder if places like
these qualify as disputed territory. After all, the US and Canada have a
nation-to-nation relationship with each tribal government.
___
Tagging mailing list
Tagging@openstreetmap.org
https://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] network tag on route relations

[Clay Smalley]

On Sun, Jul 12, 2020 at 3:08 PM Peter Elderson  wrote:

> I still don't understand why you tag "US" while it's obviously a bunch of
> roads in the US. or Interstate when the road clearly crosses state lines. I
> think that"s more redundant than tagging "we classify this route as a
> regional route", even though it might cross two national borders in a few
> places and half the roads are outside our borders, and we don't know the
> current operator or provider.
>

Because they are two separate networks with roughly the same geographical
scope. How would you distinguish Interstate 30 from US Route 30, which are
hundreds of miles away from each other?

Some Interstate highways do not cross state lines themselves, but the idea
behind the name is that the network as a whole does. Regardless, that's
just the name for our national freeway network.

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

Re: [Tagging] Signal-controlled roundabouts

[Clay Smalley]

Coming from the US where any form of roundabout is rare, I would consider
any circular intersection a roundabout. Some have signals, some don't have
signals. I know that some people in the US distinguish between the two,
where a 'roundabout' has no signals and a 'traffic circle' does have
signals. Either way, it makes sense to me to tag it as a roundabout because:

1) it is a junction of multiple roads
2) all traffic must enter a circular roadway, and then get off at some point

Out of curiosity, what are others' criteria for a roundabout?


On Fri, Jun 13, 2014 at 8:54 AM, Fernando Trebien 
fernando.treb...@gmail.com wrote:

 Hello,

 I used to believe that, by definition, all roundabouts have free
 transit and right of way along the circle, and that anything that
 didn't display that property isn't a roundabout (just a circle). But
 reading the wiki once again, I'm a little in doubt. The wiki mentions
 that this is a roundabout, but I would previously have thought it
 wasn't because of the traffic lights within it:
 http://www.openstreetmap.org/#map=19/52.59689/-1.14146

 So why is it a roundabout? Is it because of the circular shape? Or
 could it be because it's impossible to infer that any of the entering
 ways have right of way, since they are all controlled by traffic
 lights?

 --
 Fernando Trebien
 +55 (51) 9962-5409

 Nullius in verba.

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

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

Re: [Tagging] natural=cloud

[Clay Smalley]

Sounds about right, but add layer=* tags where appropriate. Clouds go above
the land, so we have to make sure they render above everything (except
certain bridges and buildings). Might as well add layer=5 to all of them
for good measure.
On Apr 1, 2014 12:16 PM, Matthijs Melissen i...@matthijsmelissen.nl
wrote:

 On 1 April 2014 18:08, Pierre Knobel pierr...@gmail.com wrote:
  I just wanted to mention a new tag I created yesterday:
  http://wiki.openstreetmap.org/wiki/Tag:natural%3Dcloud

 I think this is tag a very good idea. Clouds are very noticeable
 features in the landscape. I just have some concerns about layering.
 How do we tag places where bridges and clouds cross, like in the
 following picture?
 http://www.fotopedia.com/items/flickr-1316696923/slideshow
 Do we add nodes on the place where the cloud crosses the bridge?

 -- Matthijs

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

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

Re: [Tagging] Mismatched Level of Detail in highways vs. other elements

[Clay Smalley]

I do some mapping in SF too. The Muni Metro lines weirded me out when I
first saw it, and I looked up the proper practice on the wiki as well as
looking for a few examples in Europe, and it seems that the best practice
is to just add railway tags and the proper relations to the street whenever
it runs along a street, and as a way by itself when it runs in its own
right-of-way (such as the J line's jog around a hill a little south of
Dolores Park).

I'd support mapping the Muni Metro lines the European/more common way, if
nobody else has any objections.
On Apr 7, 2013 1:38 PM, Martin Atkins m...@degeneration.co.uk wrote:


 Hi all,

 I do mapping in San Francisco, CA and I'm frustrated about the
 inconsistent levels of detail we typically use when mapping urban
 environments.

 For example, most highways are mapped in a network-oriented fashion with
 one string of ways representing both directions of traffic, often
 encapsulating other features like cycle lanes and sidewalks, and
 intersections simply represented by crossing the streets at a single common
 node.

 On the other hand, rail lines are most commonly mapped by their physical
 shape, so the rail ways come in pairs. The people who mapped the tram lines
 in San Francisco also mapped the curves of the rails at intersections,
 rather than having them meet at a single node as with the highways. This
 creates the following ridiculous effect in rendering:
 http://osm.org/go/TZHvFT5aF--

 Notice how the rails only just fit inside the rendered street on straight
 sections, and cut the street corner completely at the intersection.

 However, here's how it actually looks on the ground (looking across the
 intersection from east to west). Notice that the rails are completely
 contained within this 4-lane intersection (all four being normal traffic
 lanes with no physical separation except for the tram boarding platforms):
 http://oi45.tinypic.com/**w6qsgh.jpghttp://oi45.tinypic.com/w6qsgh.jpg

 (On the plus side, we're doing better than Google Maps, whose rendering
 makes it look like the rails on Church street are both off to the west side
 of the street! http://tinyurl.com/cedot4n )

 This problem shows up in various other contexts too: it's impossible to
 accurately tag a bench or bus stop on a sidewalk because the sidewalk
 doesn't exist as a separate construct. Fences or buildings directly abut
 the street end up rendering either over the street or set back from it
 because the true width of the street is not represented.

 For most normal street mapping and vehicle routing purposes it seems
 sufficient to just know simple landmark details that aid in orientation,
 e.g. that whether particular street contains a railway or it passes
 alongside a railway. Of course, more detail-oriented uses like 3D
 renderings it'd be more important to have the full physical street layout
 described, with separated lanes and proper physical relationships with
 surrounding objects.

 How have others resolved this fundamental conflict? More detailed streets,
 or less-detailed everything else?


 __**_
 Tagging mailing list
 Tagging@openstreetmap.org
 http://lists.openstreetmap.**org/listinfo/tagginghttp://lists.openstreetmap.org/listinfo/tagging

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

Re: [Tagging] SF Muni tram lines are layer=1?

[Clay Smalley]

On Mon, Dec 17, 2012 at 12:50 AM, Clay Smalley claysmal...@gmail.comwrote:

 I noticed the majority of the trackage of the San Francisco Muni lines are
 tagged as layer=1, while the streets along which they run have no layer tag
 (an implied layer=0).
 If the Muni lines are layer=1, it is my understanding that the Muni lines
 should be physically above the street.
 Since this is not the case and the lines run at street level, should I
 remove the layer tag on these specific tracks (to imply layer=0)?

Soo, it's okay for me to remove the layer tag on _these_ bits of track?
-- 
Clay
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] SF Muni tram lines are layer=1? and general tagging levels considerations

[Clay Smalley]

On Mon, Dec 17, 2012 at 11:40 AM, A.Pirard.Papou
a.pirard.pa...@gmail.comwrote:

  A level is an altitude.  A layer is a drawing opacity.  Although OSM does
 not tag for the renderer, it uses the tag *layer=**. It defines *layer*as the 
 relative position (is that altitude?). In fact, the only effect
 of assigning a layer is that upper layer objects hide lower layer ones
 (it's not a mind your step warning ;-))
 It's interesting to keep all the rails in the same layer to avoid splits
 and layer =+1 may be needed for them to show at some places. My reaction
 would be that the person having cared to explicitly set the level might
 have had something on his mind.

It's true that we don't tag for the renderer. My reasoning was that we have
a separate renderer for public transit.

 I have traced lengths of streams

- stream as a constant layer=-2 way, uninterrupted end to end (even if
they don't look so deep),
 - roads are at level 0
 - and bridges and culverts at level -1, in the manner mentioned above.

 I've never seen anything tagged like this before. As I've seen it, bridges
are nearly always layer=1 (or some positive number), and the general
consensus on the wiki agrees, so I'm going to keep tagging layers this way.

Also, with your way of tagging layers, how do you deal with a road bridge
that goes over another road?

-- 
Clay
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] SF Muni tram lines are layer=1?

[Clay Smalley]

On Mon, Dec 17, 2012 at 12:23 PM, Chris Hill o...@raggedred.net wrote:

 The layer tag is only a hint to renderers. If you remove the tag the road
 way may render over the rail way and hide it.

Yes, that's been my understanding. It's also been my understanding that we
have a separate renderer for public transit.
-- 
Clay
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

[Tagging] SF Muni tram lines are layer=1?

[Clay Smalley]

I noticed the majority of the trackage of the San Francisco Muni lines are
tagged as layer=1, while the streets along which they run have no layer tag
(an implied layer=0).
If the Muni lines are layer=1, it is my understanding that the Muni lines
should be physically above the street.
Since this is not the case and the lines run at street level, should I
remove the layer tag on these specific tracks (to imply layer=0)?

(Of course, some of these lines run through tunnels where they are tagged
layer=-1, and on bridges where they are tagged layer=1 correctly. The layer
tag on these bits of track would remain untouched.)

-- 
Clay
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging

Re: [Tagging] Proposal: expanded address tags for US

[Clay Smalley]

On Sun, Nov 18, 2012 at 3:20 PM, Tobias Knerr o...@tobias-knerr.de wrote:

 To me, the straightforward solution would be:

 addr:housenumber = 6345
 addr:street = W. Euclid Avenue (maybe without the abbreviation)

 To add to that, I would posit that the name including the direction and
suffix is indeed the full name. To me, West 3rd Street and East 3rd Street
are absolutely as distinct from each other as Elm Street and Oak Street.
___
Tagging mailing list
Tagging@openstreetmap.org
http://lists.openstreetmap.org/listinfo/tagging