It’s up to you how important the features are to you.

To me, main buildings (houses, offices, …) are the most important, because they allow to visualise addresses.

I’ve been mapping houses (with address info) for a very long time, but never mapped garages or sheds until our region got access to an open dataset of buildings (which are now being individually checked and imported).

What are these diaries for I wonder?

For sharing your thoughts on OSM, for showcasing your achievements, for anything related to maps, …It’s up to you what you use it for.

Today was my first proper contribution to OSM.

Welcome! It doesn’t happen often that someone who has been a member for 8 years suddenly becomes active.

Learn more about the philosophy behind OSM

It’s pretty much like Wikipedia. Many people just like to gather knowledge, and everyone has their favorite on what is more important. Though in recent years, more and more big tech companies get involved too (Microsoft, Facebook, Apple, …)

I’d like a comparison with Europe. Although from some straight lines, I have the idea that the colours depend on imports quite a bit.

Wikidata only helps with big features as you said (regions, cities, …). You won’t find many translated streetnames (as we often have in Belgium) in Wikidata.

I would actually prefer a thematic editor/QA tool for this: go to an area, extract the important names of boundaries and cities (perhaps even up to villages or hamlets). Get a suggestion from Wikidata to what they can be translated, and approve it (or translate it yourself).

That said, the smaller you go, many names don’t have a translation but only a transliteration to the different alphabets. It’s sometimes odd what gets translated and what not. Like in Dutch, we never translate any American city or region, but we do translate big European cities and regions.

There are more insightful stats than just the number of changesets. Many people like to take a look at HDYC to check how a contributor is doing: https://hdyc.neis-one.org/?jimkats (nice history btw, a very active start).

You should try to * Limit it in time: at max a few hours, to avoid conflicts * Limit the area: don’t make continental or even country sized changesets, it will cause many people to see it in their history and investigate it * Just edit one topic per changeset: if your tagging is wrong, and a changeset should be reverted, you don’t lose the other changes.

There’s no hard limit of 10 or 100 changes. I even have changesets of over 1000 changes. These large changesets can happen when tracing rivers or streets in unmapped areas. They’re still just one feature and a limited area, so it should be fine.

Though every new mapper can make the mistake of letting a changeset become too big. I made that mistake too.

Hmm, this also got me interested in local names with “mile” in it.

One such name I know is “Millekruis” (Mile cross). But it seems to be 7 km from the nearest big historical city of Ypres (osm.org/directions?engine=graphhopper_foot&route=50.8058%2C2.8104%3B50.8454%2C2.8774#map=12/50.7923/2.8134)

Even if you count it just to the city walls.

However, it may depend on what kind of mile was used. Historically, a Flemish or Dutch mile was often synonim for 1 hour of walking. Which could again vary between 3.7km (Flemish) and 7.4km (Hollandic). I still believe you’d have to walk quite fast from Millekruis to Ypres, but it’s probably doable to get it in one hour.

Ça doit marcher automatiquement. Mais ça dépend du vitesse des imports de Qwant.

Je vois que mes modifs de hier ne sont pas inclus, mais ceux de 3 joirs avant sont inclus. Donc je pence que ça dure quelques jours.

what are the prerequisites for a valid tag?

For data to be added to OSM, it should just be static and verifiable.

If you try to add such data, and no tag for it exists, you are allowed to create your own tag. It is advised but not obligatory to document it.

However, the tag you mention is documented. It’s the lanes extension to the railway tag.

The railway tag is documented here: osm.wiki/Railways And how a lanes extension works is documented here: osm.wiki/Lanes

Any tag that can be used on a road can get a :lanes extension. So it’s perfectly valid tagging.

Hi Victor,

Businesses are welcome on OSM. There are just a few criteria for data to be allowed on OSM.

• It needs to be static (or recurrent). So no temporary road blockages, movable stores, … Recurrent features (like a speed limit during school hours) can be mapped with special tags
• It needs to be verifiable. So if you map a business, that business should be visible from the street. This also means that reviews or advertisements aren’t allowed.

As the business you want to add has an address, it’s probably signed, so it can be added.

IMO, the African schema is just a clarification of the European schema but for African roads.

If a European maps african roads, he’s often inclined to map everything that isn’t paved as track. Because in Europe, most unpaved roads are actually mainly for agricultural use.

But the tagging just implies the function: tertiary roads connect villages, secondary roads connect towns, primary roads connect cities, and trunk or motorway roads are just special primary roads (with special rights).

Then you have residential roads for accessing houses, and unclassified roads for any roads in between.

It seems all pretty simple to me. Of course there are cases where you can doubt between two classes. But just pick one and carry on.

Take a look at https://welcome.openstreetmap.org/ to get more information about the project.

Basically, we’re a “Wikipedia for maps”, where we try to make a free world map, made by its users.

You can simply zoom to a place you know, press the “Edit” button, and add or improve features. From simple object like paths or shops, to detailed information on those like speed limits, and contact information.

Happy mapping :)

In Flanders(1), we’ve had great quality imagery since 2015. It has 10cm pixels, is guaranteed to be sub 50cm accurate, and is taken in the winter (when less trees obscure features).

At some places, gardens have been mapped for a long time(2), but it never gained much traction, and most cities don’t have any gardens mapped at all.

I also think it’s a bit ugly. But it’s not wrong. IMO, it’s up to the renderer to turn down the look of private gardens.

1: Belgium is that split up that the geography department is regionally organised, and Flanders has different access to geographic data than Brussels or Wallonia 2: Example garden: osm.org/way/315514701

Personally, I think Osmose is way too strict on many issues. And especially to strict in assigning issues to people.

I was a bigger fan of keep-right, which puts more emphasis on the error than on the mapper.

I really don’t care if I fix an issue, that my name will be attached to the other issues of that road.

Buildings is useful for statistical analysis. Hence why HOT has such a focus on buildings: it allows them to estimate how many people live in a certain region or how spread out they are. That’s important information for aid organisations.

However, you are correct that most often the buildings don’t get mapped by the local community. Either they get mapped by foreign mappers, or they get imported. Even in many European places, the buildings are imported and not drawn by the local community.

For local people, it’s way more important to have local features (amenities, shops, …) with detailed information (name, contact info, …). That’s not something a remote mapper can achieve. But it’s also way harder to analyse: you have no idea how many features there should be.

Hello

Welcome to the JOSM users. Be aware that JOSM will not hold your hand when making changes. You can put any data that fits in the OSM model, and even automate a lot (via the selection filters and plugins). But that does bring some danger to it.

On of the dangers is to use too many relations. Relations are easy to make in JOSM, but should not be used to making generic categories of objects.

I see only a few good uses of relations:

• Multipolygons, as these cannot be expressed by ways
• boundaries
• Routes (bus, hiking, cycle, …)

These often have a bunch of tags that apply to the complete feature. So repeating that on every member might be wasteful, hence relations are used.

AssociatedStreet relations for addresses are an edge case. It depends on your local administrative situation whether you need more than a streetname to see the correct address. In Belgium we’ve opted not to use those relations. A number, streetname and boundary relation is enough to get the correct address.

Other features should generally be achieved by tagging. In your example, if the campus has an area mapped, it’s quite easy to query the bike sharing stations inside an area. So you don’t need to add them to a relation. If the campus doesn’t have an area, you may tag them with operator=”Campus XYZ” to be able to query them.

In JOSM, finding a relation and selecting its members is about equally hard as hitting CTRL+F and searching for the correct tag. So there’s really no need for a relation here.

I just tried this a bit, and it’s an improvement, but it seems to be very street-focused.

Finding a street in a city is no problem. But typing a country or city name to just roughly go to an area doesn’t suggest the city (but it does suggest all streets that have that city in their name).

Also, it would be nice if you could find a good sorting based on a combination of proximity and importance. When I’m viewing my region (province of West-Vlaanderen in Belgium), and I type “Ro”, I would expect “Roeselare” to be the first result as it’s a decent city right in the center of my view. Later down the list, it would perhaps show “Roesbrugge”, which is a small village still in my view. Then perhaps “Romania”, a country (thus important), but way out of my view. And when all countries, cities and villages are listed, only then show the streets.

For a rough static importance, you could perhaps count the number of obects (nodes/addresses/other features) in the city limits, or along the street (a certain distance away from the road). Which would account for area, population, and even correlate to OSM users.

The dynamic importance (based on the current view) will probably be harder in elasticsearch. You could implement something based on the number of tiles away. Like divide the importance by log(2+x) where x=0 means it’s in the current view, x=1 means it’s a neighbour of the current view, …

But perhaps even a bigger difficulty. When I look for a street, I may be looking for an address. So when the street is completed, it should probably start to suggest addresses in that street.

Hello,

Welcome to the OSM project.

I took the liberty to take a look at some of your changes. First of all, thank you for adding some names. Names are very important on the map and very valuable information.

But I notice you also added some data that isn’t needed. Like on some small roads (i.e. osm.org/way/829633542), you put oneway=no.

Openstreetmap has a concept of “default values”. Like a highway=residential is by default accessible by anyone, while a highway=footpath is by default only accessible by pedestrians. You do not need to specify this when it just follows the default.

The same for oneway=*. Regular streets are by default not oneway. You should only use the oneway=no tag when it’s a special case (like a motorway that’s two-way). You don’t need to put it on every road.

I used the older version of the plugin, not this alpha release. The old version can just be installed from inside the JOSM plugins.

But it only supports roads, hence it’s only useful in unmapped areas.

I have worked a bit with MapWithAI to map roads in Peru.

Manual checking is still very much needed. Even if the alignment doesn’t matter that much (when there are no other features present), MapWithAI seems to struggle with tight bends and foiliage covering the streets (where a human would just connect it through).

That said, the plugin did help a lot with lowering the amount of work. It’s far less work to just scroll over a road, and touch up a few points, than having to draw it completely by hand.

Oracle removed webstart from newer versions.

So JNLP is a dead technology. Even on Oracle Java.