1. Agreed, it's ridiculous that Tyler and Fishtrap should render the same - Fishtrap is not even remotely a hamlet. However, Fishtrap is a perfect example of what should be classed as an "isolated dwelling". It has its own freeway exit; it has a namesake lake, a namesake rec area, a railroad placename and associated siding, and by god it even has a few buildings. Back in the days of the phone book, Fishtrap even had its own white pages section in the Spokane directory. Granted, it was only two or three entries... so I acknowledge it's an edge case.
2. The OSM maxim "Don't map for the renderer" should be updated to "Don't map for the renderer, nor the geocoder". I have no strong opinions about any other geocoders, but Nominatim is a piece of poo. Its inability to perform a zipcode query on a placename, and return the correct USPS-defined placename for that zipcode is inexcusable. I can easily google that info, why can't a geocoder?
3. Well that has nothing to do with this. Misinformed armchair mappers will always screw things up - doesn't matter if a place is marked as a hamlet or locality.

All in all, I think we're on the same side here. I just believe in the hierarchical nature of place-naming: if you take the Babb siding west of Cheney and compare it to Fishtrap, I strongly believe those 2 are not at the same hierarchical level - Babb is nothing, and Fishtrap is a very tiny *something*.
But... I really don't want to get into an edit war, so I'm willing to downgrade Fishtrap to a locality if you feel that strongly about it.

Agreed that most of these "hamlets" are not, but if there are industrial or commercial buildings still present, it's more appropriate to not downgrade all the way to "locality". The "isolated dwelling" tag is not literal - imo it's more about placename significance and associated rendering. Do you see it differently?

Hi there - Please explain what is meant by "needs station verification" for the Empire Builder route (relation/10946021). Is there a question of accuracy here, or is there something else at play?

Claro - gracias por arreglarlo

@Viajero No worries - I appreciate you chiming in. Glad to know I'm not overreacting.
@carpbunker There are many problems with the data you're importing:
1) It's Canvec, so it's usually outdated at best, and in the case of backwoods waterways, often just plain WRONG. If you import waterways from Canvec, you should do it one river at a time and check to make sure the data is at least somewhat accurate, and try to fix it where it's not. The Tanzilla and Stikine are good examples - the water area defined by Canvec is decades old, and needs a lot of editing to fix what you placed. The Stikine in particular now has two separate channels for long stretches: the original river way, hand-traced, and your parallel CANVEC polygon that is largely incorrect, running alongside. Awful.
2) River polygons (natural=water + water=river) are importing incorrectly as named water bodies. (see my comment in change #81351653). The way in the middle of the river takes the name and all other appropriate data - not the polygon. You should especially NOT be deleting an already placed river way and replacing it with a named river polygon. Which brings me to...
3) You are deleting some waterways before replacing with Canvec data. As Viajero pointed out, that's not cool at all. I'm personally pretty steamed about it - I don't know how much other data you have treated similarly, but I'm quite sure others will also take offense.
4) You're importing river data but not lake data, so the waterways that are hitting small lakes just stop and then restart, over and over again.
5) All your waterways are importing as rivers - even the smallest creek.
6) You're placing waterways over roads without creating bridges, culverts or fords, and triggering a TON of Osmose errors in the process. That's how I found out about your imports - my Osmose errors were skyrocketing from you placing rivers over roads I placed.

I'm not an "All Imports Are Bad" mapper, and I'm grateful that you didn't import any of the land cover polygons from Canvec (which are absolute dog sh*t), but I'm asking you earnestly to fix what you've done so far, and endeavor to import more carefully in future.
Thank you!

Here ya go...
water=river :

Draw the outline area of the river and add natural=water + water=river. For long rivers the area should be split into several segments of manageable size.
In addition a way tagged as waterway=river, must be drawn in the direction of the river flow. ALL TAGS OF THE RIVER (LIKE NAME=* AND OTHER SUPPLEMENTAL TAGS) SHOULD GO TO THIS CENTER LINE.
(emphasis mine)

Add to that the cardinal rule "One feature = One name" (yeah that's a bad paraphrase).

The main issue is that data consumers generally pull water polygon data as non-flowing bodies of water, and labels are applied accordingly: One label, affixed roughly in the center of the feature. If you name a river polygon, it will not render the name correctly.

Do NOT name the river area - the named portion of the river needs to be the way in the center.

Looks to me like you're deleting and replacing some of these instead of just adding. If you're going to import CANVEC crap, you shouldn't be deleting features that are already there, when you're only replacing the feature with a new version.

Yeah - what phideaux said.
I was going to give another example of what you could do - but now notice that you're using Potlatch... which I know absolutely nothing about.
Well if you *were* using iD, you can create your natural area and snap to whatever boundaries you desire, and then when done, while the new area is selected and fully visible (zoom out if necessary), hit "d" to disconnect all nodes.
In essence, it's far less future work for mappers should landuse or boundaries change - then only the one element needs to be updated. Ultimately not a *huge* deal - mostly just a helpful fyi from a fellow pnw-er.

FYI - Gluing "natural=" areas to civic boundaries really shouldn't be done.
Gluing land areas to water bodies in generally frowned on, too. Just so you know.

I understand what you're saying, and I totally support what you're trying to do - I just need to reiterate that the administrative boundary of Inuvik does not correspond to the IANA of the same name.
FYI, I had to redo the admin boundary, as it was fouled up AND incorrect to boot.
Accordingly, I did not replace the Inuvik IANA boundary you created.
I did find that iana.org has a tarballed data file, but it was filled with old references and invalid URLs. Was hoping for lat-long and other details, but no...
https://www.iana.org/time-zones

Looks like it's actually the union of admin_level 5 boundaries (in Canada, second-level census divisions) and each timezone.
The main point is that the Inuvik IANA boundary is HUGE - it's not the town's boundary!
https://upload.wikimedia.org/wikipedia/commons/6/64/UTC_hue4map_CAN.png

I actually had thought that the IANA zone boundaries were simply the union of timezone and admin_level boundaries of 4 or 5. But there's a tz distinction between Inuvik and Yellowknife, which blows that out of the water. *shrug*

I see what's going on - you were looking at https://en.wikipedia.org/wiki/List_of_tz_database_time_zones, undoubtedly.
This tz database contains geographical markers for timezone locations, but they themselves are NOT timezones.
I'll let you revert, as this is not a valid map change - but I'll do it myself in 48 hours if I don't get a response. Thanks!

"Inuvik Timezone"? How is there such a thing? What is your source?

Hiya! FYI - you don't need to mark a ford for a waterway that passes under a roadway in a tunnel - only when the waterway and roadway are on the same level! :)

Another thing - tracktypes don't render if you just use a number. Instead of 'tracktype=3' you have to use 'tracktype=grade3'.

How did you come to see a water body here?
way/722842789
This is most definitely NOT a lake.

Hold on - If you're talking about ending a waterway on a water body, and then restarting again on the other side - yes, that is an error, and I take full responsibility for doing that. That usually happens when there are multiple inflows into a waterbody and I haven't figured out which one (if any) continues.
But if you're talking about connecting a waterway node to a water-body node, that wiki page says nothing about that, and neither do osm.wiki/Rivers or natural=water.

I actually can't find the forum post that led me to start connecting waterways to lakes they feed. Do you have a link to anything that says to NOT do that? I looked at various places around Europe and found a mixture of both options being mapped.