[Osmf-talk] Fwd: Google Open Buildings now licensed ODbL
Johann Haag
johannhaag at hxg.at
Sun Dec 5 09:23:24 UTC 2021
---------- Forwarded message ---------
Von: Johann Haag <johannhaag at hxg.at>
Date: So., 5. Dez. 2021 um 10:22 Uhr
Subject: Re: [Osmf-talk] Google Open Buildings now licensed ODbL
To: <dfjkman at gmail.com>
Am So., 5. Dez. 2021 um 08:46 Uhr schrieb <dfjkman at gmail.com>:
>
> Apart from the inbuilt biases in any AI
>
If OpemStreetMap operates its own AI instance, then we can determine
the accuracy and the rhythm of the calculation of changing building
outlines ourselves.
> many of the larger African cities are developing rapidly so would require constant passes with AI to keep them close to being partially accurate. Lusaka has seen a massive change in the last decade or so with new buildings springing up almost overnight, many in previously built up residential areas, the same goes for new roads and widening of existing roads. In the more remote rural areas you will find that whole clusters of dwellings will appear and disappear in imagery of differing ages. This is due to the fact that many of these houses are built from unburnt mud brick and are temporary by the very nature of their construction materials, when the house is rebuilt it may be built in an entirely different spot. A very wet year in Zambia may mean that even in the high density parts of cities buildings collapse and are rebuilt to a different design. How does AI distinguish between solid structures and temporary ones such as roadside stalls constructed from iron sheets or, in rural areas, grass? These 'ntembas' may be dismantled when the person operating the stall decides to move to a better spot or the authorities decide to do a 'clean up' and remove the lot, only for them to spring up again a few months later in a different layout.
>
If societies change quickly, there are also good macroeconomic reasons
to take aerial photos of such regions at shorter intervals.
>
> Google maps may be fairly accurate with its road lay out in the ordered part of cities such as Lusaka that resemble any small town or city but is way out in the more densely populated outer rings of these cities, if you relied on it you would have the classic large trucks going down small tracks of the early days of Google maps in the UK and other Western countries. In the rural areas, apart from the major roads, Google Maps is worse than useless. Googles AI relies on the idea of an ordered road lay out, not a network of interconnecting informal tracks that will vary in width and uniformity. When it finds a nice set of what it assumes are uniformly laid out wide roads in farming areas it happily lays them out. These tend to be 2 tracks on either side of a barbed wire fence within a wide firebreak bordering cattle paddocks. Furthermore Google is just plain wrong with some of the road references in Zambia.
>
If OpenStreetMap has a self-determined AI instance and integrates such
techniques into the ongoing workflow, OpenStreetMap would also be able
to react more quickly to disaster situations.
In the event of disasters in particular, highly up-to-date aerial
images are available to us in a short time, and those looking for help
cannot wait days for a nerd in the northern hemisphere to find time
for hotosm mapping.
https://www.heise.de/wissenschaft/Karten-fuer-Haiti-908272.html
Fire fighting vehicles and rescue technologies are not built for each
use, they are available at the push of a button and require regular
exercises. Established AI technologies that are maintained during
operation could help quickly in the event of a disaster.
Greetings Johann
>
> -----Original Message-----
> From: Johann Haag <johannhaag at hxg.at>
> Sent: 05 December 2021 00:45
> To: Simon Poole <simon at poole.ch>; osmf-talk at openstreetmap.org
> Subject: Re: [Osmf-talk] Google Open Buildings now licensed ODbL
>
> In recent years I have dealt intensively with the situation of building outlines in OpenStreetMap, and building outlines calculated by AI in official maps. OpenStreetMap today are mostly the same aerial images that Google has to purchase for a fee. Why don't we create AI-determined outlines ourselves from the aerial photographs made available to us. The AI technology required for this should have been directly available to OpenStreetMap for a long time.
>
> A future OpenStreetMap would primarily consist of cyclically imported official OGD data and building outlines calculated from aerial photographs.
> We OpenStreetMap Mapper would close the time gap between official publications and thus provide official services with valuable local information on errors in their geodata.
>
> Am Sa., 4. Dez. 2021 um 11:24 Uhr schrieb Simon Poole <simon at poole.ch>:
> >
> >
> > Am 04.12.2021 um 04:18 schrieb Martin Machyna:
> >
> > If we go with CC-BY 4.0 + waiver, would that solve the problem?
> >
> > Possibly. Note that it doesn't solve the quality issues with the data and other aspects that should be considered. I haven't seen anything that indicates that the discussion around this data has progressed to a point at which it simply can be shoved in the face of contributors without the risk of things going really wrong.
> >
> >
> >
> > As a side note, I don't think it is healthy for us to think about somebody as a competitor. We are here to create/gather geospatial data and provide it for free to everybody, not to compete with someone. As far as I know Google is not a data provider, but rather a provider of map services so if it is competing with someone it is more Mapbox, Geofabrik,... etc. Google has decided to help us and recently also started using our data, I think we should embrace it as a recognition of our hard work and use any help there is to fulfill our mission.
> >
> > While google does not provide data without any services attached it does clearly provide replacement products and competes with the OSM ecosystem as a whole. It would be naive to not recognize that. That doesn't mean we can't accept support and data from them, but it shouldn't be in a form that restricts our freedom going forward over what we have agreed upon as a core property of the project (in this case that we provide our data on open terms).
> >
> > During the licence change we had to negotiate with, in some cases unhappy, third parties in exactly that situation (Nearmap comes to mind, but there were others). Regardless of how amicable a relationship was at one point in time, we need to recognize that things change and flexibility that was there at one time might go away.
> >
> > Simon
> >
> > PS: A third party GTFS data source that google uses, utilize OSM data and google is displaying the attribution that that data source requires. That is a far cry from "google started using our data" as a deliberate decision on behalf of google. It was note worthy more as an amusing quirk than anything else.
> >
> > PPS: the timing of the announcement in the OSMFs silly season is not lost on me.
> >
> >
> >
> > Martin
> >
> > On Fri, Dec 3, 2021 at 7:41 PM Simon Poole <simon at poole.ch> wrote:
> >>
> >>
> >> Am 17.09.2021 um 17:02 schrieb Mikel Maron:
> >> > Agreed this shouldn't be used for bulk import. Human reviewed conflation and editing signal I think will be useful in some regions.
> >>
> >> It seems as if this is now available via RapiD and it is likely going
> >> to be added come what may.
> >>
> >> I know nobody asked for my opinion, but I don't consider it a
> >> particularly good idea that somebody will need to go back to google
> >> and ask for their permission to retain the data if OSM ever decides
> >> it wants to change its licence. While it is true that there have
> >> been, and continue to be, other cases in which ODbL licensed data has
> >> been imported (not that I consider that a particularly good idea in
> >> those cases either), it hasn't been from a de facto competitor that
> >> is known to change its policies at the drop of a hat.
> >>
> >> Simon
> >>
> >>
> >> >
> >> > * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Friday, September 17, 2021, 09:54:53 AM EDT, <dfjkman at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > Hi all,
> >> >
> >> > As an example as to why it is not a good idea to use this data for a bulk import have a look at this link of one small part of Lusaka ( https://sites.research.google/open-buildings/?lat=-15.390364893412949&lng=28.321204487879392&zoom=17#explore), select the hybrid option to see how out it is. This shopping centre is several years old.
> >> >
> >> > Dave
> >> >
> >> > -----Original Message-----
> >> > From: Mikel Maron <mikel.maron at gmail.com>
> >> > Sent: 17 September 2021 15:20
> >> > To: osmf-talk at openstreetmap.org
> >> > Subject: Re: [Osmf-talk] Google Open Buildings now licensed ODbL
> >> >
> >> > As agreed with Google, I've added Google Buildings to the list of
> >> > Contributors,
> >> > https://wiki.openstreetmap.org/wiki/Contributors#Multiple_African_c
> >> > ountries
> >> >
> >> > * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >> >
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > On Thursday, September 16, 2021, 12:29:52 PM EDT, Mikel Maron <mikel.maron at gmail.com> wrote:
> >> >
> >> >
> >> >
> >> >
> >> >
> >> > https://sites.research.google/open-buildings/#faq
> >> >
> >> > OSM can now use this data set. Very interesting change to see G support OSM directly.
> >> >
> >> > Noting the prior discussion on quality issues on this list, expect
> >> > to see this more useful in peri-urban and rural areas. The FAQ
> >> > notes the importance of human review and when possible local
> >> > knowledge
> >> >
> >> > -Mikel
> >> >
> >> > * Mikel Maron * +14152835207 @mikel s:mikelmaron
> >> >
> >> > _______________________________________________
> >> > osmf-talk mailing list
> >> > osmf-talk at openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >> >
> >> > _______________________________________________
> >> > osmf-talk mailing list
> >> > osmf-talk at openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >> >
> >> >
> >> > _______________________________________________
> >> > osmf-talk mailing list
> >> > osmf-talk at openstreetmap.org
> >> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >> _______________________________________________
> >> osmf-talk mailing list
> >> osmf-talk at openstreetmap.org
> >> https://lists.openstreetmap.org/listinfo/osmf-talk
> >
> >
> > _______________________________________________
> > osmf-talk mailing list
> > osmf-talk at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
> >
> > _______________________________________________
> > osmf-talk mailing list
> > osmf-talk at openstreetmap.org
> > https://lists.openstreetmap.org/listinfo/osmf-talk
>
>
>
> --
> Mst. Johann Haag
> Innsbruckerstraße 42
> 6380 St. Johann in Tirol
> ÖSTERREICH
> Tel: +43 664/174 7414
> Mailto:johannhaag at hxg.at
>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
>
>
> _______________________________________________
> osmf-talk mailing list
> osmf-talk at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/osmf-talk
--
Mst. Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannhaag at hxg.at
--
Mst. Johann Haag
Innsbruckerstraße 42
6380 St. Johann in Tirol
ÖSTERREICH
Tel: +43 664/174 7414
Mailto:johannhaag at hxg.at
More information about the osmf-talk
mailing list