Talk:Public transport

Talk section moved here was 'Public Transport'

Approved features

Why are the approved features from Proposed_features/Public_Transport not copied to this page? Should the features be used now, or are there still problems? The vote ended more than 2 months ago already. Math1985 18:55, 24 June 2011 (BST)

Yes, the new features should be used. I (and others) did not find time to update the Public Transport page yet. A simple copy is IMHO not good enough. --Teddych 06:48, 25 June 2011 (BST)

Teddy, please find time for that work, becasue it would be important to see this proposal going officially live. (Even if it is, already.) It's difficult to find what's here and what's on the propsal and so on. Thank you. - Kempelen 22:33, 25 July 2011 (BST)

Hi is there any progress? This page refers to the Proposal that has been archived and refers to this page, so tagging is missing completely. --Kudlac (talk) 20:01, 15 February 2021 (UTC)

@Kudlac: please provide an example, I do not know what you mean. --Tigerfell  (Let's talk) 18:54, 17 February 2021 (UTC)

Section Public_transport#Tagging refers to -> Proposed_features/Public_Transport. But the page Proposed_features/Public_Transport says that proposal is located at Public_transport. Links goes into loop and tagging info is nowhere. --Kudlac (talk) 22:04, 17 February 2021 (UTC)

The current tagging information is on this page. The original proposal is found at Proposed features/Public Transport. Note the difference between "feature page" (a. k. a. current practices potentially combining multiple proposals) and "proposal" (a. k. a. historical information). Good catch BTW. --Tigerfell  (Let's talk) 13:33, 20 February 2021 (UTC)

How to map routes?

I can think of three methods to map bus routes: 1. Copy the routes from a map, for example on the bus companies' website. 2. Go outside and look in all bus stops which buses are announced to stop there. 3. Take a ride in all bus lines.

As far as I know, we have two reasons to not copy data from other maps: copyright/database right reasons and accuracy.

IMO, an overview of bus lines is not a creative work and is thus not protected by copyright (although the rendering of the map might be copyrighted - but we copy the data, not the rendering). For database rights, there needs to be "a substantial investment in obtaining, verifying or presenting the contents of the database". A bus company doesn't invest in obtaining or verifying timetable data, whether an investment is done is presenting a database is not clear to me. So database rights might be an issue with 1 (and maybe even with 2?), but this is not entirely clear.

Methods 1 and 2 might be less accurate (especially outside of Western Europe). Perhaps method 2 might be even more inaccurate than method 1.

Which methods would others consider acceptable? Math1985 19:19, 24 June 2011 (BST)

Or "4." contact the public transport companies for data. Budapest transport company released the full data to the public one month ago, when they went to Google Maps (in GTFS format). This is great, import is in progress. Kempelen 22:31, 25 July 2011 (BST)

Service routes

Q. 'Line' is also used in some places for this concept. which should we use? PeterIto 07:39, 6 August 2009 (UTC)

I think we should stick with 'Routes', as this is the name widely established on OSM. However, we clarify this by calling them Service Routes. For the infrastructure itself, I like the idea of also using the type=route tag, but using type=railway instead of type=train. We could call these Infrastructure routes. Frankie Roberto 11:52, 8 August 2009 (UTC)

Tram tracks

This page says that streets with tram tracks should be a single way for both road and tracks; OSM Inspector says that they should be separate ways to keep the names separate. Who’s right? --Wynndale 18:29, 8 August 2009 (UTC)

I am sure OSM Inspector is right! I have never tagged a tram track personally but have updated the description to match my current understanding (which matches a conversation I have had with someone on the subject some time ago). Would be great to have the views of a tram expert.PeterIto 18:15, 9 August 2009 (UTC)

I was under the impression that having two ways which use the same nodes was a bad idea (as it makes it difficult to select the different ways in editing tools). That said, I've only been using both tags (railway=tram and highway=secondary) where the tram and the cars share the same physical lane. Where they are grade separated, but part of the same road, then the two should have separate ways. Sometimes you can even get a mix of both on the same road - eg there's one near me where one side of the road, the tram has exclusive use, and on the other side of the road, the tram shares its lane with cars. This makes the road as a whole one-way for cars, but two-ways for trams. I've mapped this using two ways (one for each lane), but it looks a bit crap in current renderers... Frankie Roberto 20:12, 9 August 2009 (UTC)

• Firstly, can I suggest that it is a problem for the editors to solve. Fyi, in Potlatch someone finally showed me how to select any way from a stack of ways. click the node, if the way you want is not shown then type '/' which changes the way, then if that isn't the right one click the node again and type '/' again - repeat until the correct way is shown - not elegant but it does work. Secondly, can I suggest that we move this discussion about Tram tracks to the Trams page and just keep a brief link to it from this page? PeterIto 06:28, 10 August 2009 (UTC)

Copied from main page

Think these two need more work/thinking, as well as some examples. Frankie Roberto 22:36, 21 September 2009 (UTC)

Line Variant

A Line Variant can be used to define a particular calling pattern used by some vehicles operating on the Route.

A Line Variant is a relation which details a distinct ordered calling pattern for vehicles using a Route and there will normally be at least one Line Variant for each direction of travel for a Route. Each calling point should either be defined as a Stopping Place or Access; for preferences Accesses should be used, however if the actual Access cannot be determined for a particular calling point then the Stop Place should be included instead (Accesses will not known at calling points where the Access is allocated dynamically shortly before the actual vehicle arrives). Set-down only calling points can be assigned with the role Set-down only or pick-up only.

Using a Line Variant in association with a Route it should be possible to determine a single unambiguous route through the network. If this cannot be determined due to there being two valid routes between two stop points then one or more suitably chosen additional infrastructure nodes should be included as '[passing points' in the Line Variant within the ordered list at the appropriate position.

The following tags can be used:

Key	Value	Description
from	text	initial stop
to	text	terminal stop

A Line Variant should be a member of a Route Relation.

Network

A group of routes can be combined together to form a Network. A single route can, if necessary, be part of more then one network.

Key	Value	Description
name	text	name (e.g. Chicago Transit Authority)
abbreviation	text	abbreviation of the name (e.g. CTA)

One or more Routes can be a member of a Network relation.

Transit data standards

Transmodel

Transmodel is the European Reference Data Model for Public Transport. It is an abstract conceptual model to represent common public transport concepts such as network timetabling, ticketing, operations and realtime data. Transmodel is an important design tool, informing and guiding the design of public transport information systems.

If you want to follow the current discussion on the relevance of Transmodel to OSM and how OSM data will achieve compliance, join the mailing list talk-transit@openstreetmap.org.

IFOPT (Identification of Fixed Objects In Public Transport)

IFOPT (Identification of Fixed Objects in Public Transport) is a prCEN Technical Specification that provides a Reference Data Model for describing the main fixed objects required for public access to Public transport, that is to say Transportation hubs such as airports, stations, bus stops, ports, and other destination places and points of interest, as well as their entrances, platforms, concourses, internal spaces, equipment, facilities, accessibility etc.)

Wheelchair and accessibility

Q How explain if the station was being built for wheelchair with the new system ? In the past, we used highway=bus_stop and wheelchair=yes/no/limited. How we can do with the new system? Could we use wheelchair=yes/no/limited with platform ( station seem be to big for wheelchair=yes/no/limited ) ? --APP3L initiation (talk) 20:13, 4 March 2013 (UTC)

Outdoor elevator with public transport?

There is a unapproved proposal on elevators: http://wiki.openstreetmap.org/wiki/Elevator

How should this be used now with public transport?

Making two nodes on bottom and top with public_transport = stop_position elevator=yes

How could I know which is top and which is bottom? And I will have to cheat to get a little stretch of way, since often, elevators are exactly vertical ...

See example: http://www.openstreetmap.org/way/105616741#map=19/46.94659/7.45252

Bike racks

How to map transit service with bicycle carriers on the vehicles? In my city, several bus routes have some (not all) busses equipped with two bike racks for the passengers. Analogous to wheelchair=no/yes/limited, this could be bike_rack=no/yes/limited/partial.

Are there other types of bicycle accommodation on public transit? I guess some services might let passengers roll their bikes into the passenger compartment, or provide bike lockup. Perhaps it should be bike_carrier=rack. But then how to indicate that only some vehicles have this equipment? Should capacity be indicated?

We cannot use bicycle=yes, because that indicates legal bike access on the roadway, but we need to indicate availability of an amenity on the bus. —Michael Z. 2016-10-18 18:16 z

Use bicycle=yes on the type=route relation -Miklcct (talk) 01:36, 25 April 2017 (UTC)

Yes but still with route=bus. The route relation indicates a bus line, independantly of the type of highways permitted to and used by buses (still buses cannot go on cycleways if these highways don't have themselves a bicycle=yes). Normally QA analysers will detect routes that use incompatible ways.

However the question is more precise: bike_carrier=rack is a specific equipment within buses. It may exist buses where user's bikes may be transported, but only with luggages and on specific stations where buses can stop; there could also be an open area within buses where bikes may be parked, but without any attachment (passengers still need to stand near it and cannot sit down, and if the bus is too crowded, they won't be able to enter: priority will be given to wheelchairs or small carriers for young children or smaller luggages).

The same question may occur for train routes (only in some cars of the train that have a platform: many trains are not easy to climb into with bikes, and the doors must remain accessible for other passengers, I'm not talkiing about the very dangerous overcrowded trains in poor countries where many passengers are traveling on the rooftop or hanging to the windows or to open doors or could send their bike to the roof: there's no real equipment except on some train "cars" that are only open platforms noramlly made for the freight).

If there's such equipmeent for cycles onboard, additional keys may be needed such as the presence of a lock to secure the bike from falling or from being stolen by other passengers. In many buses, bikes are accepted only where the bus has a long stop and the bus driver will secure it with other luggages: passengers cannot do that themselves. In trains, it is possible to give your bike to a railway personnel that will put it in a specific car for the freight: that car is not open to the public (this is rare on modern high speed trains for long distance travels: you must buy a separate reservation ticket and your bike will be conveyed sepoarately and delivered some hours or days before or after your travel). For short distance city buses with many stops, it's not possible for the driver to handle luggages, there must be a specific equipment open to the public within buses, suitable for bikes or large luggages. — Verdy_p ^(talk) 02:03, 25 April 2017 (UTC)

Doubled tags in master and route relations

Hey, I would like to know why the page states that the tags ref, ref:<qualifier>, operator, network, and color are recommended. The proposal says: "recommended if no route_master=* exists, else optional". There must be a reason why it did not say "recommended". Editing PTv2 relations in north-east Germany, my experience is that every route relation has all of the tags mentioned above. If something changes, however just one or two values are updated by fellow mappers. This is why I see the current situation as a second choice, but surely not as good as it could be and not the way it was meant to be. I would therefore suggest to change the wiki page accordingly. Are there any opposing views? U30303020 (talk) 13:45, 4 January 2018 (UTC)

Done U30303020 (talk) 22:46, 10 March 2018 (UTC)

Bus platform: compatibility with PTv1

Regarding the recent changes of the wiki page, I'm wondering if it's a good idea to add a separate highway=bus_stop if the platform is already mapped with public_transport=platform, because only one of it can be added to the bus route(s). What is wrong with adding highway=bus_stop to a public_transport=platform way or area? This is what Key:public_transport recommends and what iD's Bus Stop / Platform presets do, too. --SelfishSeahorse (talk) 08:24, 10 March 2018 (UTC)

In PTv1 there was no distinction between stops and platforms, they were the same object (bus_stop nodes), almost always not on the road but beside it; there was no clear platform. And routing them was a problem.

PTv2 makes the distinction by placing stop_positions on roads (allowing correct routing). But platforms are not recognized by v1 applications, and that's why for compatiblity with these v1 apps only, a "bus_stop" node is still needed on the platform. When the platform is an unclosed way or closed way/area, we need the additional node, only used by v1 apps, not used at all by v2 apps. But I have doubts that v1 "bus_stop" could not be used as well on the platform object, even if it's an unclosed way or closed way/area (possibly a multipolygon relation). But I suppose that most v1 apps remaining are only accepting single nodes, and in this case that bus_stop node should be near on the platform the position where the bus stops and there's a bus_stop sign.

Note that most platforms for buses are still single nodes, so there's no need to create an extra node for compatibility, only tag the platform node also with highway=bus_stop.

Still, even if there's highway=bus_stop on that platform node, you need bus=yes (platforms are designed to be possibly multimodal, not just for buses, they could be used for taxis, or trams, with their own stop positions (possibly not the same stop_position if they are not exactly on the same type of way: note that a platform may have two sides, one along a highway for buses, another side along a light railway track for trams or a separate service way for taxis).

Adding this extra bus_stop node on platform ways/areas may still causes some problems. In my opinion these compatibility nodes should NOT be part of v2 "stop areas" to avoid detection of duplicate stops (e.g. for the tool that attempts to render line sketches). — Verdy_p ^(talk) 08:52, 10 March 2018 (UTC)

Thanks for your reply! I didn't think that PTv1 apps rely upon a highway=bus_stop node. It's not nice to have two bus stops in these cases, but I think I have to live with that ... at least until PTv1 finally isn't used anymore. :-) Regards --SelfishSeahorse (talk) 10:54, 10 March 2018 (UTC)

Note that with the slow development/migration to PTv2, msot apps still depend on PTv1 and many still don't care about PTv2 at all. This is progressing, but variably depending on cities where maps using PTv2 have been now been deployed. Completing Public transport lines is a big task that also needs regular maintenance (at least once each year in most cities, sometimes at each season, notably for buses; metros and rapid systems are more stable, but much simpler in comparison to maintain). — Verdy_p ^(talk) 12:08, 10 March 2018 (UTC)

In this case, it seems to make more sense to add only the bus stop node (highway=bus_stop + public_transport=platform + bus=yes) to the route relations, but not the platform (highway=platform). Because otherwise these apps display a bus stop icon but you don't get informations about the routes. --SelfishSeahorse (talk) 12:54, 10 March 2018 (UTC)

No, because platforms are part of route relations with the role "platform", even if they are ways or areas. The legacy v1 bus_stops are transitory but we should favor the v2 to allow the transition, otherwise we would be frozen to v1. The ways/areas for platforms are already part of v2 route relations.

But may be if route relations are still in v1 we could have these legacy nodes and not the way/area platforms: converting the v1 route to v2 would require replacing the legacy v1 nodes by v2 ways/area platforms, but not keeping both as members. Note also that stop areas are only in v2, not in v1, and it does not make sense to add these v1 bus_stop nodes to these stop areas.

This remark applies only when platforms are ways/areas (for a minority of stations), but not when they are (most frequent case) just nodes (having both tags as highway=bus_stop in v1 and public_transport=platform+bus=yes in v2).

And there's no such highway=platform tag, platforms in v2 are (or should be) only public_transport=platform; if you find them, they should be converted instantly to v2 without ambiguity ! — Verdy_p ^(talk) 14:18, 10 March 2018 (UTC)

This is incorrect. The proposal in 2011 listed highway=platform as one of the existing tags and said that none of them would be deprecated by the propoposal. This tag is still needed, because a public_transport=platform does not specify if it is a bus stop with only a sign (or even no sign), or if there is actually and elevated platform. A highway=platform is an elevated structure used for boarding a bus, similar to a railway platform. There is no replacement for this tag. Even for highway=bus_stop the tag public_transport=platform alone is not sufficient, because it doesn't specify if the stop is for a bus, a tram, or a train. --Jeisenbe (talk) 15:39, 29 July 2019 (UTC)

Wikidata and Wikipedia tags

Some users are adding key:wikidata and key:wikipedia tags to public transport routes, when such pages do exist.

I wonder what is the most appropriate object for those tags: should they go to the route master relation only, or to every itinerary variant route relation, or on both master relation and route relations, at the price of duplication of the same information and potential maintenance problems? Bxl-forever (talk) 22:57, 17 June 2018 (UTC)

Stop Numbers

Every stop in our bus system has a unique number on its sign. This number can be used to access arrival estimates by phone, text or web. Should this number be recorded (I believe it should) and if so, how? —Preceding unsigned comment added by TreeStryder (talk • contribs) 13:02, 31 August 2018

Hi! This is a good question. Unfortunately i can't help you. There's ref=*, but together with public_transport=platform it is used to tag the platform number or letter. You might want to ask your question on the Talk-transit mailing list. The mailing lists are the main communication channel on OpenStreetMap. Regards --SelfishSeahorse (talk) 14:40, 9 September 2018 (UTC)

PS: There's also the undocumented tag stop_id=* (see Taginfo).

"name" tag vs. "description" tag

Using name=* instead of description=* mismatches how name tag is supposed be used but follows proposal -- moved from main page to Talk page, originally posted by Mateusz Konieczny 6 May 2019

@Johnparis - are you claiming that "name tag is supposed to be used for name, not description" is just "one person's opinion"? I am pretty sure that "Name is the name only" is not just my personal preference - see https://wiki.openstreetmap.org/wiki/Names#Name_is_the_name_only Mateusz Konieczny (talk) 19:21, 11 May 2019 (UTC)

Perhaps I am unclear. It is your opinion that "Bus 93: Chatelet -> Montmartre" is a description. It is, in fact, by consensus, the name, as stated in the proposal. It is in fact also a description of sorts -- all names are descriptions in one way or another -- but to say that it is only a description is your opinion, not a fact. As stated in the page you cite, "It is certainly wrong for a mapper to invent a name for an airstrip; however most names were invented at some point in history, so if someone invents a name and it catches on and a sizeable group of people refer to the thing by that name, then it's ok to be mapped." Johnparis (talk) 14:20, 30 May 2019 (UTC)

There is now a proposal to deprecate the text: [1]. Andrew (talk) 19:10, 11 October 2023 (UTC)

Temporary closure of a bus route

A public transport company decided that some certain bus routes wouldn't be active during the summer which brings up the question of how to tag them. I believe it would be inappropriate to delete the routes as they will (most likely) be reactivated in the autumn. Is there a way to mark the routes in such a way that software would know not to display and/or utilise it during a certain defined time period? If not, how could I tag the routes so I could fairly sure the software would ignore it while the tag is there, while still keeping the associated data intact until it's reactivated? -Svavar Kjarrval (talk) 09:46, 12 May 2019 (UTC)

I would prefix route=bus with disused:, i.e. disused:route=bus. Regards --SelfishSeahorse (talk) 09:53, 14 May 2019 (UTC)

I would use a lifecycle prefix as proposed by Selfish Seahorse; perhaps disused is the best. In any case it's important not to use a tag that will be harmful if not changed at a certain point, so at the least a checkdate or opening date (as with a construction prefix) would be useful. Johnparis (talk) 14:24, 30 May 2019 (UTC)

For seasonal services I would recommend opening_hours=*. Please note that we shall not tag short term closures (e.g. by construction works), because many people use off-line copies. --GerdHH (talk) 10:52, 25 June 2019 (UTC)

Routes without line numbers

In Greece regional buses usually dont't have line numbers, but city buses have. As a result, map shows IDs (line numbers) for the city buses only, while regional buses are represented by a nameless red line. Thus it is impossible to follow the course of the regional bus in the city (example: osm.org, ÖPNV-Karte). I understand that we shall not "invent" references that do not exist in nature, but is there any other solution for this problem? Should the renderers create a "synthetic ID" from from=*/to=* or use name=*? --GerdHH (talk) 11:08, 25 June 2019 (UTC)

I could imagine making use of the color=*, but you should direct your requests to the companies standing behind these maps, because they are the only ones with the ability to change their rendering.

• In case of Transport Map it is Gravitystorm limited, supportthunderforestcom
• in case of ÖPNV-Karte it is MeMoMaps, infomemomapsde

In case of the first company, I can assure you that someone reads your message, I have contacted them in different matters before. --Tigerfell  (Let's talk) 21:13, 27 June 2019 (UTC)

It seems reasonable for renderer to make "synthetic ID" from from=*/to=* - but decision, as usual, is completely up to whoever makes it Mateusz Konieczny (talk) 21:14, 28 June 2019 (UTC)

An ID made up from name=* or from=*/to=* tends to be very long (only think of a bus running from Palaiochora to Elafonissi), thus again and again I return to some kind of "created" ID, e.g. unsigned_ref=* or ref:X=*.--GerdHH (talk) 11:13, 7 July 2019 (UTC)

I have just spotted some "generic" ref=* entries for use with PTNA, e.g. "BTANIC" (Botanic Gardens to Entertainment Centre Tram) or "GAWC" (Gawler Central Line) in Australia or "E-ALASORA-KOLOINA" (derived from the endpoints) on Madagascar. --GerdHH (talk) 17:56, 9 February 2021 (UTC)

Original tags are still more common

I've check the data with Taginfo and https://taghistory.raifer.tech, and the original "V1" tags are still more common than those using public_transport=*. The most extreme examples are for aerialway=station and amenity=ferry_terminal which are many times more common than the public_transport=* option, but common feature like bus stops are still more commonly added to the database with highway=bus_stop instead of public_transport=platform as of 2018 to 2019. I've made some edits to the page to mention which tags are actually more commonly in use. While some mappers seem to think that tags like railway=station should be discouraged (even though the proposal did not suggest this in 2011), the data shows that most mappers are continuing to add new features with the simpler, more specific tags. --Jeisenbe (talk) 15:51, 29 July 2019 (UTC)

Naming PT Stops

Looking into how to usefully name public transport stops (bus stops in particular), little general conventions or even suggested rules seem to exist.

"Ground truth" could be interpreted as "whats written on the sign", but also that often has issues, like signs not carrying a name at all, or in some cases signs only reflecting the portion of the name which is locally relevant (e.g. for the city bus), but not regionally for a long-haul service stopping there also. Also different time tables sometime carry contradicting name information for the very same stop.

Only few general conventions or published rules seem to exist, among them (only in German) https://www.berlin.de/senuvk/verkehr/politik_planung/oepnv/download/SBI_II/anlage2/SBI_II-VV_Anlage_FGIa.pdf, chapter "VBB-Konventionen zur Haltestellenbezeichnung".

With little "overall consistency" being achievable, I have over time found that the rule set I suggest below can generally help to create both a degree of consistency and usefulness:

• (1) I prefix the local bus stop name with the town or village name followed by comma, as in "Littleville, Market Square"

• (2) I omit the town name for larger settlements which have more than about 5 stops overall, unless where a particular stop is of regional or trans-regional importance like for long-haul services (Flixbus, etc.)

• (3) I use the dash "/" as a separator to denote street corners (e.g. "Main Street/First Avenue", or alternative stop names (e.g. Town Square/County Court), but not otherwise or as a general separator.

• (4) For stops on highway exits or bypass roads it seems useful to put the village name first, then where the stop is located ("Littleville, County Road"), not the other way round.
  • "name" is for actually used name. (1) is extremely unlikely to be actually used name, it smells like tagging for the renderer. Ad (3) - use alt_name=* for alternative names. In general you appear to advocate misuse of name=* tag Mateusz Konieczny (talk) 12:16, 26 September 2020 (UTC)

Private shuttle services

This may not be the right page to discuss, but does anyone know how to map a private shuttle service that offers lift from the city to the airport? Example: https://www.airportljubljana.co/ Martianfreeloader (talk) 21:25, 5 November 2021 (UTC)

If there's no physical presence not even a pick-up point (like a taxi stand) or ticketing counter, you should refrain from adding it for now. ---- Kovposch (talk) 07:35, 6 November 2021 (UTC)

Thanks Martianfreeloader (talk) 09:26, 6 November 2021 (UTC)

Metro system routes naming

Should metro systems follow the schema's naming?

At present, many metro systems in OSM do not follow this naming schema. Although it is common to prefix with metro, there are just as many names without <type of transport> or with <network> instead.

There are some problems with using <type of transport>. Some metro systems include light rail or other forms of rail transit, but people may rarely call them by type. The line name in some metro networks is the rail type, such as the Shanghai maglev line, which will cause the type to be repeated. ——Lepus (talk) 15:33, 23 January 2022 (UTC)

There was a complaint on this with bus routes somewhere. Ultimately caused by Tagging For Editor by PTv2. It should really be avoided. The arrows are equally annoying. iD already supports from=*, to=*, etc tags together for unnamed non-motorized routes. This allows mass transit to follow suit. ----- Kovposch (talk) 07:48, 24 January 2022 (UTC)

Hail and ride entey/exit only

If a route is hail and ride, but only for passengers exiting or only for passengers entering do hail_and_ride_exit_only and hail_and_ride_entry_only make sense as relation roles? Has anyone run into this and tried to map it? Bgo eiu (talk) 20:12, 26 May 2022 (UTC)

Why do we map public transport?

When it says in the section that Google Transit is making improvements - well, admittedly it has made them and now includes fairly comprehensive and reliable timetable information from the network databases. I still think that it makes sense to map PT in OSM. To give a quick, general overview of PT accessibility in an area, within OSM. What do you all think? --Alfons234 (talk) 19:50, 25 January 2023 (UTC)

I think this reasoning is strange. This is OPENstreetmap featuring open geographic data with a high quality in some areas. Both points are not in scope of Google's services. They want to make money with the highest return on investment rate. Consequently, they will never be as exact as OSM and never offer free geo-data as long as there are potential competitors. We are not mapping something because it is not included in Google maps. We do our own project here. --Tigerfell  (Let's talk) 21:23, 28 January 2023 (UTC)