We're sorry but this page doesn't work properly without JavaScript enabled. Please enable it to continue.
Feedback

Surveying amenities for OSM at scale

00:00

Formale Metadaten

Titel
Surveying amenities for OSM at scale
Serientitel
Anzahl der Teile
351
Autor
Lizenz
CC-Namensnennung 3.0 Unported:
Sie dürfen das Werk bzw. den Inhalt zu jedem legalen Zweck nutzen, verändern und in unveränderter oder veränderter Form vervielfältigen, verbreiten und öffentlich zugänglich machen, sofern Sie den Namen des Autors/Rechteinhabers in der von ihm festgelegten Weise nennen.
Identifikatoren
Herausgeber
Erscheinungsjahr
Sprache
Produktionsjahr2022

Inhaltliche Metadaten

Fachgebiet
Genre
Abstract
OpenStreetMap editing transitions to mobile devices. There are few editing apps, and the best ones are thematical. This year I've published "Every Door": an app specifically designed to collect hundreds of shops and amenities. I've made it with the experience of mapping in OSM, making a Telegram bot of a similar purpose, and studying geospatial UX design. I've surveyed half a thousand amenities with the bot, and even more — with this new app. In this talk we'll briefly touch on the app itself and the OSM tagging model. The main attraction would be map UX design: why you should remove the most interactivity from your maps. These are hard to use even on desktop, and a small screen provides an even bigger challenge. Can we get rid of them altogether? Let's see how working with maps can be made efficient, and how the ideas behind this app can make geodata collection apps better.
Schlagwörter
202
Vorschaubild
1:16:05
226
242
MaßstabReverse EngineeringAmenable GruppeInformationsspeicherungDatensatzTypentheorieBitTabelleDifferenteRechenwerkMultiplikationsoperatorGebäude <Mathematik>AdressraumZahlenbereichWendepunktOffene MengeEinflussgrößeObjekt <Kategorie>DatenmodellMultiplikationPunktTextur-MappingReverse EngineeringElementargeometrieFormale SemantikQuellcodeExistenzsatzAttributierte GrammatikCodierungAggregatzustandCoxeter-GruppePaarvergleichComputeranimation
Lie-GruppeTextur-MappingTexteditorDigitale Photographie
Offene MengePunktTextur-MappingDatenfeldApp <Programm>Quick-SortFlächeninhaltSchnittmengeComputeranimation
ZahlenbereichServerTypentheorieApp <Programm>BildschirmmaskeZentralisatorComputeranimation
DatenmodellDelisches ProblemValiditätInformationDigitale PhotographieDiagramm
Offene MengeÄußere Algebra eines ModulsProzess <Informatik>Physikalische TheorieTextur-MappingSchreib-Lese-KopfFlächeninhaltSoftwareentwicklerComputeranimationJSON
Roboter
Message-PassingTypentheorieRoboterPunktMessage-PassingComputeranimation
Displacement MappingVisuelles SystemDisplacement MappingBildschirmsymbolHilfesystemInformationTextur-MappingPunktMailing-ListeSchaltwerkBoolesche AlgebraHochdruckProdukt <Mathematik>RoboterAdressraumProjektive EbeneZweiDiagrammComputeranimation
ZufallszahlenPlastikkarteVerschlingungDigitale PhotographieDatenfeldRoboterDigitale PhotographieOffene MengeDatenmodellTextur-MappingURLDatenbankVerschlingungDifferenteComputeranimation
ZufallszahlenTexteditorTextur-MappingCase-ModdingDatenmodellOffene Menge
App <Programm>Offene MengeComputerspielWendepunktFlächeninhaltKonstanteTexteditorSoftwareentwicklerMultiplikationsoperatorProdukt <Mathematik>Prozess <Informatik>Textur-MappingDatenfeldMobiles InternetComputeranimation
Offene MengeSchnittmengeNichtlinearer OperatorQuellcodeTextur-MappingTypentheorieVerschlingungPlastikkarte
Nichtlinearer OperatorE-MailURLProgrammbibliothekEndliche ModelltheorieOffene MengeTextur-MappingCase-ModdingDatenmodellSchnittmengeAdressraumPunktProzess <Informatik>Reverse EngineeringKomplex <Algebra>TypentheorieComputeranimation
Abgeschlossene MengeTexteditorÄußere Algebra eines ModulsOffene MengeEndliche ModelltheorieSchaltwerkTextur-MappingTypentheorieSchnittmengeProgramm/QuellcodeComputeranimation
VerknüpfungsgliedEinfügungsdämpfungOffene MengeOpen SourceAmenable GruppeApp <Programm>Textur-MappingOffene MengeGrenzschichtablösungSondierungAggregatzustandSoftwaretestEinsPunktTexteditorWendepunktRechter WinkelFlächeninhaltReverse EngineeringRoboterZehnGebäude <Mathematik>MathematikAuswahlaxiomQuellcodeMAPServerComputeranimationJSONXML
Transkript: Englisch(automatisch erzeugt)
Hello everyone. I'm Ilya Zverev. I know everything about OpenStreetMap. I like to map it. And I really care about shops and amenities in OpenStreetMap, which is a bit unfortunate, because, well, OpenStreetMap has very few of these.
I don't use OpenStreetMap for searching for nearest H&M store or copy shop. I open Google Maps. And that's the common sentiment. Like, when you need POI, even commercial companies,
they just turn to commercial data sources, because it's much simpler. When I was working for a big American company to assess the quality of multiple POI datasets,
well, the state of OpenStreetMap was obvious from the beginning. Like, in the United States, it has only half a million POI. In comparison, all commercial data stores have 40 million, 80 times more. That fact alone was pretty decisive.
So, yeah, we paid for commercial data and so on. Even if you close your eyes at quantity, using commercial data is basically a simple table.
Each row has all the data for point of interest you need. Type, name, measure of existence, when it was surveyed, open addresses from house number to country, everything. Very simple to use. With OpenStreetMap, not so much.
With OpenStreetMap, you got tags. Data model has been evolved over 18 years, with thousands of people contributing it, and you can imagine what happens. Of course, there are some obvious tags, like name.
Actually, no, but kinda. There are types, which are kinda simple, but no. There are open hours, which are documented, but not easy to parse, but still. And there are ambiguous tags, like for floor in a shopping mall,
we got three different tags with different semantics, and you're not promised any. For payment types and fill types, you have to collect many tags into one single attribute again. And addresses are hard, which I guess Sara Hoffman can tell you in her presentation.
There are so many tags, and every country has their own different ideas on addressing. Like, you can't compare how buildings are addressed in the United States, in, I don't know, Czechia, in Japan, in Africa.
And more than that, in OpenStreetMap, in United States, only half of POI have addresses on objects themselves. Many mappers consider that you should get address for a shop from geometry,
like from enclosing building, or somehow revert geocoded. And as a person who has written, I think, the best revert geocoder for OpenStreetMap, revert geocoding is awfully hard.
You shouldn't make anybody do that, especially when they just need to know the address of a shop. So, yeah, commercial data source. But I care about OpenStreetMap. What can I do? Can I somehow fix this?
Well, I could try fix at least a quantity problem. Like, I can just take my camera and go outside, which I did like ten years ago. And I spent the entire day making photos of every shop, you know, the old way. And then came back and opened OpenStreetMap editor,
and was typing all the collected data for four days, morning to evening. And, yeah, OpenStreetMap got like 700 shops richer. But, like, everything hurts. Like, my feet, my hands. Never again have I repeated this experience, because it's very hard.
All these shops are obsolete now. It was ten years ago. Nobody, like, updated them. And I did that. Pretty, like, interesting experience. And I was, like, highly motivated, because I care about OpenStreetMap. People usually need some external motivation, like money.
Does OpenStreetMap have money? No. But there are commercial companies. Some that also care about points of interest, like Streetcred. They paid money to people.
Well, not directly paid, they organized a set of competitions. Who can collect the most points of interest in some enclosed area in a big city like New York? They used a simple, like, field collection app.
Kind of Next.js collector, or Qfield, or ODK, you know, the type. Like, when you prepare the form, spread it to apps, and then give that to people, and they collect it to a central server. Kind of like that. Except more flashy, because it was about the money.
And you can't trust people you pay money to. So you have to double-check everything and collect as many info as you could, including photos. Validation was very hard. But it worked. They collected, like, ten thousand shops, which is impressive.
All obsolete now, because it was very long ago. But, I don't know, the data model, there were not too many customers. The companies did not. And there are no alternatives. Sorry. So, what do we do?
Maybe... I still care. And maybe I can figure this some other way. Maybe it's not about quantity, but about quality.
Like, maybe, as a developer, I could invent some tools that make this whole process simpler, because we can't rely on paid people, there is no money in OpenSeatMap. We have to rely on the biggest strength OpenSeatMap has. It's millions of volunteer mappers. And for that, to make their lives easier, to not make their feet and head hurt,
we need to maybe make it simpler. I tested this tool's theory a year and a half ago. Like, privately, not in OpenSeatMap. I collected, like, in my very small area with lots of shopping malls,
half a thousand shops in, like, two weeks, on and off, using just a telegram bot. It's in Russian, sorry. This is the bot for searching, you know, the type. But the idea is that I didn't use any external tool.
I just opened my messenger, telegram is a messenger, it doesn't have anything besides, like, buttons and messages. No interactive maps, no nothing. And collecting half a thousand points was a breeze. I really liked the experience. I thought I was onto something.
How did I do that? Well, two things. First, telegram doesn't have interactive maps. Turns out this was really helpful, because we, as mappers, are easily distracted by the promise of interactive maps.
They are really easy to make, and they have everything, and they're fun to navigate, except they don't help with, like, work. Interactive maps for editing has very, quite a few drawbacks. Like, for example, they distract you
by having to scroll and zoom the map, like, instead of editing. You can't see all the shops, because there are too many in one point, and there's label and icon displacement that just doesn't allow you to see them. And there's basically, for each shop, there's just icon and label,
so you can't print all the information in it. It is hard to use interactiveators, and I did away with that. You know, when you don't have a map, you can have just a list, and lists are great. Like, I just saw shops around me in a list,
filtered by floor and address, of course, and it was really simple. So I look at a list, I look around and compare, and I immediately see what's missing, what's extra, what has changed. It got pretty fast.
And in the list, you are not limited by an icon and a label. You can print any info you want, like open hours on the phone, so you don't have to tap anything, you just immediately saw whether they have changed. Try, like, removing interactive maps from your project. It may boost your productivity.
The second thing, diagram what was created, is custom data model. I use my own database. I chose what fields I want to be searched and to be stored, like, I don't know, photos inside and outside, keywords for searching,
different links, like, locations, so on. Not, like, serious fields, but really helpful. I really benefited from this being my own database, not OpenStreetMap. So after I presented this Telegram bot,
enforced them and somewhere else, I got tons of questions. Are you planning to import this to OpenStreetMap? Why not use OpenStreetMap in the first place? Maybe you could make OpenStreetMap editor as a Telegram bot, and just know, why not use OpenStreetMap? It's a custom data model. It's, like, very different.
I don't want to deal with 18 years of tagging schemas in OpenStreetMap, except I care about OpenStreetMap. So that's got me thinking and presenting my ideas and, like, opening the editor,
learning mobile developments, because why not make open a mobile app to make people's life easier? And last week, I published the Every Door editor, which is a mobile app with basically the same principles, but for OpenStreetMap, that, like, fixes all the issues we have
with collecting POI data. And it's been, like, a blast. Since this March, I have been going out and mapping every shop I could find in my area and coming home and finding something to improve in the editor
to remove slowness, to make it more robust, more quick to collect. Like, this is a product of, like, half a year of constant mapping and making the process more effective. It's no longer, like, field data collection app.
It's like this juggernaut that will destroy everything. And at one time, I went to the second largest shopping mall in Estonia with 150 shops. I surveyed them in two and a half hours, basically a shop a minute.
And this might sound a lot, but it's not just names and types, as usual in OpenStreetMap, nor open hours. There's also, I don't know, wheelchair accessibility, whether you can pay by cards, and phones, links, operator names,
everything you can find in a serious data source. Every one of these 150 shops now has the full set of data collected in only two and a half hours. What enables it is that you don't see OpenStreetMap data model here. No text, nothing complex.
And also, it subtly changes the perceived priority of the text. Like, the address is actually the second after the name. So you're, like, inclined to just tap an address and set it directly to point of interest.
No reverse geocoding, finally. And multiple tags are just conflated into one, like Wi-Fi access. That's actually two tags in one button. And payment types, that's actually three tags in one button. Yeah, processing is not simple, but now it's documented.
Now you can have the data set of the same quality as commercial one from OpenStreetMap. And everything is optimized. Open hours. Open hours model in OpenStreetMap is very powerful.
Nothing you can find in commercial alternatives. Like, you can specify how the venue works on the first Thursday of the month or on December 24th. It's pretty simple. And the editor doesn't make you type, like, Monday, Friday, one, zero, seven.
No. Tap, tap, tap. You're set. Next step. Very fast. And finally, the date of serving. In OpenStreetMap now, you don't get when the shop was last seen in OpenStreetMap. All you have is date of last change.
And that can be like anything. That can be like reversion of malicious edit. This can be some bot, like, adding some useless tag. Now, this editor puts survey date on the forefront in these check marks. You go in the shop, near the shop,
you see it's still there. Nothing has changed. But it's still there. You just tap the check mark, and everybody in OpenStreetMap knows that you have seen it. It's still there. It works. It can be used. I went back to the shopping mall with 150 shops, and I confirmed every shop several months later
and added some new ones and removed some obsolete. In just half an hour, everything is made very fast. In the past half a year, when the app was beta testing, 700 mappers made 100,000 changes.
Roughly half of them were shops. Now, imagine what will happen, like, I published this app last week, and what will happen when tens of thousands of mappers from OpenStreetMap
get their hands on it, and they will start walking all around the world, adding millions and millions of shops and amenities they see, because it's so fun and easy. I just can't get my hands off the app, and I'm pretty sure other people too.
The state of points of interest in OpenStreetMap, it will be, like, on a completely different level. This changes how we map OpenStreetMap. This changes how we perceive OpenStreetMap as a data source. The choice between commercial data and OpenStreetMap
will not be that obvious in, like, three to five years. And obviously, that would put, like, many companies that fare by collecting POI data out of business.
OpenStreetMap was made to disrupt geospatial companies, and it doesn't stop at roads and buildings. It will continue, like, eat all of the areas that data companies profit from,
including right now POIs, but more things later. So, to stay in business, you obviously need to know how to work with POI, like we do in our company. We know everything about POI, we can do it. But you will have to learn how to live with OpenStreetMap too.
So, sorry about that, and thank you.