I tag the roof as amenity=fuel and then tag the building with shop=convenience (or whatever fits). I really try to avoid giving a single address to the landuse area, instead giving addresses to the buildings. There is at least one case where someone gave an address to a landuse area stretching across multiple streets not terribly far from me, and I don’t know enough about the college/university in question to know where that address should actually go.

I have cleaned up quite a few mis-mapped fuel stations where amenity=fuel was mapped as a node where the convenience store would be. This is clearly wrong by just about any standard.

I know this is an old entry… I’ve been mapping Houston since 2012. My current main project is improving the quality of the area along Tidwell Road west of I-45 going towards US 290, as well as adding/updating the businesses near the shopping center Target at US 290 and Hollister Road. My secondary project is adding building outlines in certain areas using MapWithAI, and then of course there is updating data from surveys wherever else I happen to go.

This is too powerful for a block function on a site like GitHub. It’s almost as bad as Facebook’s and Instagram’s block functions (which make the blocker’s entire account disappear, including comments and other interactions, for the person being blocked).

I usually use English, but as it happens, I edit mostly English-speaking countries. I don’t really know any other languages (well, I took a semester of Latin in high school, and then part of a semester of Spanish before I had to drop out and get my GED, but even my Latin is rather rusty and I didn’t pick up much Spanish in the class).

If I see non-English changeset comments locally, I’ll deal with it by translating as needed. But that’s usually not much of a problem around here as most of the mappers are anglophone even though we have a rather high hispanophone population.

@n76: I had this happen when I did some mapping in the UK, Puerto Rico, and a couple of other places. Finally I got sick of seeing the Osmose errors under my name so I went back and fixed them where I could. Even though Osmose has a disclaimer saying “not all of these may be this user’s fault” that’s still the implication more or less.

In general, these diary entries should relate, however tangentially, to OSM.

In general, contributions to OSM that are license-compatible and otherwise follow the rules are welcomed. However, there are rules for imports and where you can pull data from, and how to use tags. You cannot use data from Google Maps; it’s specifically against their terms of use as well as incompatible with OSM’s licensing (and don’t assume USPS data is license compatible, some of it isn’t). You cannot just do an import without consulting with the community and following the rules for imports. name=* is not for describing the feature (e.g. do not use things like name=”Swimming Pool”). It’s bad form to redraw the same object over an existing version and then delete the original, as this loses the original object history. Even when upgrading a node to a building outline I will keep the original node in the outline with tags removed to help preserve the history (though I may be the only mapper that does this).

Good intentions are good, but non-conforming data polluting the database really doesn’t help a whole lot, and may even make OSM data less useful to everyone in that area, at which point some will say “let’s just use Google Maps” (or Bing, etc).

I hope you’re moving to Houston, we could use some help over here. I’ve been adding a lot more as I’ve had more reasons to go out into the world, but I can’t map everything (I wish Amazon mappers did more than just service roads and related items).

In the US there’s a TIGER Roads 2019 overlay for this purpose, containing the latest road names from TIGER (US Census Bureau) data. Sometimes these are wrong, and the original TIGER data at least has been known to have some weird inconsistencies (roads changing from X Street to X Avenue and back several times in a mile).

If you live near enough to it, you could always survey it, too.

Houston could use some more mappers too. I can’t do it all (well, we have a few other mappers but not as many as we really need).

I map mostly the urbanized area of greater Houston, Texas, US. Here the pockets of wooded areas are relatively few and relatively easy to map, and my primary reason for doing so is that it exists in the OSM history for places that are later developed. Even in the rural areas it is relatively straightforward to map isolated pockets of woods among mostly open land, though in some areas getting the boundary accurate is a bit more work than usual. Nevertheless I can see how not mapping woods in some areas would make the task a lot easier as other parts of the US and beyond as there are a lot of heavily wooded areas out there.

Great story! I’m glad you finally got the data.

I read https://www.openstreetmap.org/changeset/68807119 and to be honest, I was quite alarmed at first; I now wonder if we have scared off poor “sharon in dc” for good (she has only ever made the one changeset). The presence of an actual changeset comment and a username not resembling the business name would have given me pause for thought, if I was the one doing this.

I agree that we need to rid the database of SEO spam and similar rubbish-quality mapping, but a “false positive” of this sort will turn what could have been a potentially very useful new mapper into someone who says “#$%& this, I’m just going to use G–gl- Maps from now on”.

I say leave them as is. Making them all trunk, except where they connect to a trunk road, is just going to make a mess and make it harder to tell where the real trunk roads are.

I’m in favor of the lanes/turn:lanes syntax, if only because that’s the style used by the current plugin and it allows for center lane uses other than left (or right) turns.

What we are really missing is a consistent way to tag reversible lanes, either as a center lane or such as those found in the Houston area as HOV/HOT lanes. The syntax used by the plugin isn’t recognized by the map paint style, the default rendering style doesn’t seem to do anything special for oneway=reversible, and that tag seems to confuse a lot of tools.

A lot of these mistagged roundabouts are in places where it would be difficult if not outright impossible to add a third road. If it’s obvious the intent is to build an actual roundabout at some point, that’s another story (Keep Right will still complain until that other road is actually mapped though).

Nice work! This will come in handy fixing certain areas of Houston where the Bing and NAIP imagery are both lacking.

Hooray for separation of church and state in the US.

In the US, these types of crossings on Interstate highways are usually signed “For Official or Emergency Use Only” and for good reason.

access=no with a possible emergency=yes is proper tagging.

I have come to appreciate this mode myself. It has made a few highway and path re-alignments a lot less painful. It even works on closed ways like water and buildings, which I have used it for a couple of times.