The first ones I noticed were originally mapped with the “Go map!” editor. So it seems likely that’s the curlpit.

They’re also very recent, so the bug likely is still around.

@arnielsewhere, what timing do you propose?

I believe the time has mainly been chosen to suit Europe and California. As OSM is still European for a big part, while most big tech companies are based in California.

When you’d take global population per time zone into account, it seems however that you need to focus on East-Asian, Indian en West-European/Central-African time zones.

If you consider those three regions, you indeed have a reasonable time frame to plan a meeting (from 6:00 to 13:00 UTC is acceptable for all involved).

However, if you still want to add the US at all, adding the eastern time zone leaves you with just one hour that’s feasible for all (13:00 UTC). If you want to add California (which is a valid request IMO, due to the amount of big-tech companies, even though the overall population isn’t that high), there are no common times to be found.

Compare times in timezones: https://www.timeanddate.com/worldclock/meetingtime.html?iso=20201214&p1=195&p2=176&p3=33&p4=179&p5=137

Oh, your name is Paul… right, sorry

I’m not sure what you mean by “Field number”. But if you think it’s valuable information, you can go ahead and map it. You shouldn’t be afraid to add stuff. I listed the only hard rules above, apart from that, it’s all just conventions we try to follow (without conventions, it would be very hard for data users).

If features have verifiable names or references, you can always slap on a generic name=*or ref=* tag (note that a name is not a description).

You may receive suggestions from other mappers in the region on how you’d better map something this or that way for this or that use case. But we’re normally very happy with any added information.

Do you mean this road: https://www.openstreetmap.org/way/94565751/history ?

Well, apparently you removed the highway=tertiary tag from it about 3 months ago. This removed the road from all maps, as it wasn’t considered a road anymore.

But you already fixed your mistake yesterday by adding highway=residential, and later changing it to highway=unclassified.

Independent services, like snapchat, don’t update their data constantly, so probably just have to wait a bit for the road to appear again.

I see that the road is in a residential area, could you change the tag back to highway=residential? This will appear the same on the map as highway=unclassified, but can be used differently for routing.

Hi Viktor,

Perhaps you’re right. On the other hand, we map more than businesses (also natural features, roads, buildings, …). And when it comes to businesses, there are some we go to more often (like shops and bars) than others (like factories and offices). So the shops and other “amenities” are easier to tag than factories or offices.

A real estate agent falls in the office category, so is hidden a bit more.

To map a real estate agent, choose the point feature in the editor

Add the point to the map, and search for “Office” in the side bar. This will add a generic office for which you can add a name, address, contact info, … To map it as a real estate agent, you can scroll down to the tags, and change the office type.

Hello and welcome to OSM!

You’ve allready done a great job. Local mappers are indeed important, but it’s surprising how much a single active mapper can change on the map.

If you want to become a real power mapper, I’d suggest you to eventually invest a bit in learning JOSM. JOSM has many powerful features like advanced search, hiding or disabling certain features (if you’re only doing buildings, you can disable landuse to avoid messing that up). And JOSM also has many plugins and styles for mapping certain subjects (like coloring streets and addresses based on the streetname).

But on the downside, it has a bit of a learning curve, and you need to learn the actual tag names, rather than the human-friendly categories offered by iD.

Dag Frank.

Bedoel je deze begin en eindpunten? https://www.openstreetmap.org/directions?engine=fossgis_osrm_car&route=52.81317%2C5.00147%3B52.80950%2C5.00831#map=17/52.81100/5.00486

Zowel OSRM als GraphHopper lijken daar een logische route te nemen. Maar misschien is hier wat context nodig.

OpenStreetMap is in eerste plaats de data. Rond die data is software gemaakt om de data te gebruiken (zoekmachines, weergave applicaties, routeer algoritmes, …). Deze gebruiken OSM data, en zijn vaak specifiek geschreven voor OSM, maar zijn geen onderdeel van OSM.

Ik heb het gevoel dat je een specifieke app gebruikt die OSM data gebruikt. Zou je die app kunnen vermelden?

Als je problemen hebt met OSM (verkeerde weergaves, verkeerde routes, verkeerde zoekresultaten, …) dan kan dat ofwel aan de software, ofwel aan de data zelf liggen. Soms is er data tekort om een correcte tijdsinschatting te maken, soms wordt data verkeerd geïnterpreteerd door de software, soms is de data inmiddels als gecorrigeerd, maar gebruikt de software nog een oude export (vaak bij offline apps).

In ieder geval kan ik hier niets verkeerd vinden, aangezien zowel OSRM als GraphHopper correcte routes vinden.

If you need to go more precise than GPS, your get into land surveyor territory. Land surveyors typically start from a well known point (which is often something precise and high, like church towers), and then perform a mesh of triangulated distance measures to get exact coordinates of some feature (like a parcel of land, or a building).

In Flanders, we actually got access to all surveyed buildings: the front side of the buildings have been measured with cm precision (you can’t go to mm precision, as the walls are most often not that flat).

The most general concensus is to map what’s signed.

Drawing borders and naming stuff can be very controversial. See the issues in Crimea for example. Mapping what’s signed usually means that you map for whoever has actual control over the region (not just claims control). And it also excludes a big part of remote mapping because you need to survey the local signs. It also takes the controversy away from OSM, and into the political level.

But then ofc you have the bilingual signs, which usually means that politics reached an agreement on some level. And it would be shameful if OSM cannot reach an agreement on it.

In a global project, one global entity can never decide what’s needed in local situations. That’s why OSM as a whole doesn’t make those decisions.

Instead, it’s up to local people to come together (in a virtual way during Covid times), and to decide what the best practices are.

So I’m sorry to hear you had a bad experience, but if you think there isn’t a good community around you, try to create one. Take a look at who’s mapping around you (like with the “Who’s around me” tool from Pascal Neis: https://resultmaps.neis-one.org/oooc ). Try to contact them, and discuss the matter.

IMO, a number of OSM tools could be better integrated on the main site, to improve community building. There are many tools around from 3rd parties (like als the Neis resultmaps, or QA tools). But as long as those are external tools, I can see why people find it hard to build a community.

Well, this is not an OSM issue, but rather Jitsi that doesn’t support Firefox: https://community.jitsi.org/t/software-unusable-on-firefox-why/22143

But after reading the bug report, it seems it mostly works, so you should be able to connect with Firefox.

Don’t you think it’s a bit harsh to leave a big project because one person wants to use a service that seemingly requires Google Chrome?

Diaries don’t have a special algorithm to get “on top”. They’re just in reverse chronological order. But your post is both interesting and controversial, that’s why you get so many comments.

I think the example given on that “unnecessary” picture is a bit of a big omission. Certainly because it’s the streetside (so very visible for mapping from the streetside) and it repeats on every building.

There are also a few options to draw those quickly: * draw two, use copy-paste and merge the correct nodes * draw a big rectangle including the extrusions, terrace it, extrude inwards and reconnect the correct nodes.

Given how quick that process is, I wouldn’t agree with omitting those extrusions.

The last picture however also shows a lot of extrusions. But for those, every house is different, they’re on the backside, and it’s hard to see if it’s actually an extended roof or just some ground texture.

In that case, I’d certainly agree it’s too much work for little added value to try and draw those extrusions.

PasqG, starting to edit is easy. Just remember something you did last week (grocery shopping, visiting something, …) go to the map there, and add that feature.

Great job!

The US is really lacking local mappers that are able to survey the region. Thanks for your work.

Hmm, I don’t like that way of voting.

Voting should be considered the last step, after the community is heard, and was able to give their comments, the resulting scheme should be put to a yes/no vote.

The problem with chosing between multiple choices is that very often, you’ll actually like multiple options, but also refuse to use a specific one.

Like if we would take address tagging to the vote today, I wouldn’t care if the tag is addr:street, address:street, addr:streetname or whatever version of that, but I would vote against using an AssociatedStreet relation (based on the past experiences I had).

However, if all those options are possible in a vote, it’s very likely many people will have similar strong feelings for or against relations. But the votes against relations would be divided over many different options making them less likely to win.

In the current way of accepting tags, it’s up to the one making the proposal to create a compromise that he believes will be accepted by a majority. The voting is only verifying whether his belief holds true.

A historical European city is almost unmappable without precise on-the-ground measuring equipment. Everything is just so close to each other, with odd angles and worst of all, many sheds or small extensions connected to the houses.

Even the governmental data we received, where they wenth through the effort of measuring all the streetside walls to cm precision, has wrong interpretations of the back sides.

That’s quite a difficult sign to understand. I wonder how many truck drivers can do the math while driving past that sign…

But I would propose to make a key source:maxweight in analogy to source:maxspeed. We use that source:maxspeed tag to encode which sign is used. So if legislation changes (and updates default rural or urban speeds), all roads with wrong maxspeeds can be found.

I.e. something like source:maxweight=US:R12-H17(-10%,Feb 1-May 15)

Documenting it in the wiki would also be handy ;)

I believe you want to add the “Berric fruit retail” business to the map, instead of putting it in a diary entry.

If that’s the case, please use the “Edit” button to modify the map data (see also this tutorial: https://learnosm.org/en/beginner/id-editor/ )

Sounds like the validator was crashing on something. I haven’t tested the latest version yet, so I can’t confirm it, but perhaps there was some special tag being used that caused the Validator to do too many checks, or even get in an infinite loop checking stuff.

What was the area you were editing?