The possibility of minutely updates was one of the nice things about Sophox back when it was functional.

Sophox is functional again!

I see. The possibility of minutely updates was one of the nice things about Sophox back when it was functional. It also queried Wikidata directly instead of keeping a local copy, at the expense of running time.

Have you checked out QLever yet? It’s a fast alternative for federated queries on the server side. This diary post provides some examples to work off of.

I think setting it up would require as first step to dump the data items as RDF but I can’t find any documentation on that in the wiki.

You can get a full dump of the wiki’s pages and data items from this directory. I added a passage about it to the wiki page.

To your first point above: the close button on the banner was not about you. A number of us experienced the bug, yours truly took the time to calmly report the bug, you had some suggestions for fixing it, and it got fixed a different way. I’m sorry it didn’t get fixed in quite the way you suggested. Personally, I was pleasantly surprised at the turnaround time, and I don’t see any motive behind the bug that can be tied to the incident about AWS credits.

To your other points: I’m just a simpleton to whom clouds are welcome relief from the incessant sun in this part of the world. Simpletons like me don’t know what to do with all this melodrama.

Bottom line, all POIs are questionable until checked by a person, which is

The line below this line is whether a local community considers this dataset to be a good use of their time versus other potential data sources as a reference point for verification (either in person or in an armchair). There isn’t a single global answer to that question.

There’s a lot to unpack here, but just for awareness:

It’s JSON, which explains just how disconnected it actually is to the MediaWiki experience. That’s why it feels so foreign and disorienting, and functions like the completely tacked-onto experience it provides.

Wikitext is only one of the page content models that MediaWiki supports. For example, the Module: namespace is in Lua, and every user can personalize their wiki experience via personal subpages in JavaScript and CSS. Pages in the template namespace can also be in JSON, irrespective of Wikibase. Though this isn’t currently enabled on the OSM Wiki, we did consider it for event listings and such until OSMCal came along.

For all its warts, I appreciate the fact that Wikibase is intended for structured data. We can of course make wikitext look like structured data by convention and build custom tooling around it, but ultimately that results in a different kind of subpar experience for anyone who attempts to edit the wiki: you can write a wiki page using simple wikitext syntax as long as you avoid breaking several lightly documented tools that place arbitrary constraints on exactly how you write (e.g., whitespace and capitalization) it due to assumptions they make. Writing for the renderer, in other words.

I appreciate your efforts at data mining the OSM Wiki, to the extent that you find the output useful. I also appreciate your emphasis on reusing existing content without creating extra maintenance overhead. However, we should view this kind of tooling as being complementary to structured data, not in competition with it.

I thought maybe the curious dynamic on mastodon where we have a “osm.town” grouping of users then a wider fediverse might mean we’re more likely to get lots of engagement from the users in our instance. That might mean it’s a better channel for talking to our community, but not so good for outreach.

At the moment, in raw numbers, Mastodon probably isn’t as powerful for outreach as Twitter used to be, but then again neither is Twitter these days.

Mastodon has the advantage of being the social network where many OSM-adjacent people have congregated, people who are likely to understand the OSM account’s posts without needing background context and a glossary, and thus more likely to get involved OSM because of these posts. I agree that en.osm.town is a bit too cozy to serve as an outreach venue on its own, though this probably means it’s up to others to boost the posts to their still-likeminded followers beyond that server.

Crossposted to this forum thread about solutions for avoiding link rot.

Thanks for running these numbers. It helps to get a sense of where the missing imagery will be most acutely felt. Another measure of that would be the countries with the greatest share of Maxar-based changesets out of the total number of changesets.

Indeed, there are two mapping styles. The two-relation approach is an optional enhancement over the one-relation approach. It has some benefits, including less likelihood of breakage (especially scrambled member order) when other editors come in later to split a way or remodel an intersection, and a more robust way to tag the signposted cardinal direction, if any.

Because these detours are bidirectional, the from and to tags aren’t necessary.

Maybe it would be useful to create two relations, one in each direction, with the exit numbers as from and to, instead of relying on the name to communicate that information?

My point is that runways (and taxiways) are not “navigable” - they are not joined or connected to create routes or other relations.

It may help to consider nontrivial examples such as an international commercial airport that typically has not only taxiways but also service roads for airport vehicles crisscrossing the taxiways and apron.

OSM is already being used by flight simulator games that make use of runway centerlines (as well as their surface areas) for rendering and gameplay. This is not routing in the sense of an OsmAnd user getting directions to the supermarket, but it is still relevant for a “navigable path” concept to be mapped.

It also conforms to the very basic principle of “one feature on the ground, one entry in OSM”.

The “One feature, one OSM element” guideline goes on to list many examples of where multiple features are a good idea.

Sometimes it’s a matter of perspective. When you think of a river, you might be thinking of a channel to cross or navigate along, or you may be thinking of a body of water to enter. We can reconcile these two perspectives by mapping the “centerline” or perhaps the thalweg as a waterway=river way and simultaneously mapping the waterbody as a natural=water water=river area. Similarly, the idea behind area:aeroway=runway or any other area:*=* key is to provide an option to micromap the surface of something as opposed to the navigable path of something. By this logic, aeroway=runway would correspond to the centerline marking.

From a technical perspective, it’s possible but not necessarily straightforward to simplify a series of runway and taxiway areas into a series of centerlines that intersect correctly, especially because an area:aeroway=taxiway area would join to an area:aeroway=runway area with gentle curves on both sides. It wouldn’t be unreasonable for a renderer to make use of this kind of simplification as you zoom out.

A multicourt surface is sometimes named and signposted and even addressable as if it’s a “tennis center”, but often it’s just two or four conjoined courts that happen to share some out-of-bounds space. I guess the closest analogy would be baseball diamonds, which are often arranged so that the outfields overlap significantly. Basketball courts can also be combined on a single surface, but hoops is already well established for that scenario.

If these multi-court tennis complexes are tagged as sports centers, renderers need to be prepared for the possibility of sports centers within larger sports centers, as well as other edge cases. Plenty a YMCA features a fenced-in complex of two or four tennis courts. This actual tennis center containing a dozen courts each with spectator stands, three stadiums, and a campground would be tagged identically. This sports complex contains a tennis complex that has not been mapped because each court has been mapped individually.

I’m curious if folks would recommend also mapping a single fenced-in court as a pitch surrounded by a leisure=sports_centre. Otherwise it’s kind of inconsistent to map some courts along the out-of-bounds line and others at the edge of the pavement.

The second screenshot shows the result of moving the building areas to align them with the base of the building rather than its roofline. For tall buildings, the subject of this diary post, it will appear misaligned unless you pay close attention to the shadows. This is relevant when using an imagery layer that isn’t perfectly orthorectified – which is essentially every available layer.

Sometimes if I know that most of the buildings are approximately the same height, I’ll temporarily offset the imagery layer so I don’t have to move the buildings after drawing them. But in this example, the buildings appear to have varying heights and even uneven roofs. 😣

I don’t want to distract from the main topic, but since you seemed to be troubled by Mapbox’s flag in this sidenote:

While I do have prior advanced experience in other areas, as you can see from my account, I’m so new to the project that as a newbie user of iD left after the tutorial in India I got scared that if someone touches something, after that validators will assume that person is responsible for errors in that something. In my case it was “Mapbox: Fictional mapping” from OSMCha.

So assume that this text is written by someone who one day ignored iD warnings for something I touched, still not sure how to fix the changeset 127073124 😐

Sorry you found this intimidating. OSMCha has an API that allows individual features in a changeset to be flagged as “suspicious” for a particular reason. Not every flagged feature is rejected; OSMCha itself sometimes applies suspicious reasons like “New mapper” and “Possible import” that only serve as a heads-up to someone doing a manual review at Mapbox or elsewhere.

Mapbox’s data team flagged this way as appearing to be fictional, as it looks like someone doodling a road through a populated place without any resemblence to aerial imagery. (You can find the specific feature by clicking the ⚠️ tab.) Perhaps you had meant to draw something else but accidentally tagged it as a road? You’re welcome to use these flags to detect and fix errors too. In any event, Mapbox accepted the rest of your changeset; for example, you can already see this road in Mapbox maps. If you don’t have a Mapbox account, you can check using this example page or a map by one of Mapbox’s customers.

OSMCha doesn’t track how many flagged features you’ve accrued, so even a false positive shouldn’t be an ongoing problem for you. OSMCha does track how many changesets its users rate as good or bad. Review teams at Mapbox or elsewhere could theoretically consider this statistic when judging whether to scrutinize a changeset more closely.

Hope this addresses your concern. (For full disclosure, I work at Mapbox but not on the teams involved with this software or process.)

Thanks for taking the time to explain more about the purpose and reasoning behind Wikidata and Wikibase. It’s entirely possible that some of the misunderstanding and reticence that persists today can be traced to some early missed opportunities to explain these unfamiliar concepts patiently and effectively. At least that was my takeaway when compiling a bibliography of OSM discussions about Wikidata.

As many of us discovered at this weekend’s joint conference, “WikiConference North America + Mapping USA”, an increasing number of people in both the OSM and Wikimedia communities are interested in exploring what our projects can accomplish together. Personally, I think the best way to overcome the skepticism about Wikidata is to demonstrate the value of the currently limited integration in the form of creative visualizations, analyses, and tools.

In general, having the address on the house is a great thing IMO (good to review, map, query, audit). However, that only works for rural areas (AKA not cities), and mostly for residential buildings (AKA “one family houses”, not shopping centers, commercial buildings, apartments).

I think a more general way of putting it is that sometimes an address applies to the entire building (every room on every floor) or even the entire property encompassing the building.¹ In this case, tagging the building itself with address tags explicitly tells other mappers that the building is complete in OSM and there are no more addresses to add. It also makes it easier for data consumers to determine the extent of an address (similar to how a boundary provides information that a lone place node does not).

The prevalence of this case depends on the local addressing practices. In parts of the U.S. that I’m familiar with, it’s quite common for a retail or commercial building in an urban or suburban area to have just one street address (often but not always with individually numbered units within). Some postal codes in New York City consist of just one tall building with one street address. On the other hand, if a single building occupies an entire city block, the whole building may have as many as four overlapping street addresses, one for each bounding street. The addresses may be used interchangeably, or each address may be for a specific purpose (e.g., mail versus wayfinding versus taxation).

One way to account for both of these cases while preserving the benefits above is to draw an address area coincident with the building. This already happens sometimes due to 3D and indoor mapping. However, some data consumers (such as openstreetmap-carto) are currently unable to handle address areas unless tagged with another primary feature tag. So tagging the building itself would be a more compatible approach.

Either an addressed building or a coincident area would make it easier for geocoders to associate entrances with an address for routing purposes. By comparison, if a geocoder encounters an address node floating within a building, it can’t be sure that all the building’s entrances can reach the unit with that address, versus another address that may or may not have been mapped yet.

1. Authorities in the U.S. typically assign an address to an area, such as a plot or building, but a delivery point can refer to the mailbox or entrance in particular. ↩