Should you rank all the candidates in the OpenStreetMap election?

TL;DR: The answer is yes. You don’t have to rank all the candidates, but there’s no reason not to.

The OpenStreetMap Foundation (OSMF) is currently holding an election for four seats on their Board of Directors. This is the governing body for the global OpenStreetMap project, and ideally the Board will represent all the diverse perspectives and communities within the overall OpenStreetMap movement. Thankfully, the OSMF board uses the Single Transferable Vote (STV) method for its elections (also known as multi-winner Ranked Choice Voting), which is perhaps the most robust and flexible form of Proportional Representation, giving the voting public the chance to elect representatives that fairly reflect the diversity of their views, without requiring candidates to form political parties or requiring that the voting public be divided up into artificial geographic regions. I previously wrote a post explaining the benefits of STV for OSM elections here.

As someone who has administered several STV elections in the past (as the elections observer for the OSM-US board and as a co-founder of FairVote Washington) a lot of people ask me for advice about how to fill out their ballot. Not about who to vote for, but how to fill out their rankings so that the candidates they like have the best chance of winning. Specifically, they most often ask whether they should fill out all the rankings, or leave some candidates unranked. Imagine that there are 12 candidates running, and you like six of them and dislike the other six. Should you rank your top six in order and leave your other preferences blank? Or should you keep going and rank your disliked candidates from 7 down to 12, your absolute most disliked candidate?

The great thing about Ranked Choice Voting (especially in a multi-winner form like STV) is that there is practically no reason to ever vote strategically. You can sincerely rank all the candidates in order of preference, from your most preferred all the way down to your least preferred, and be confident that none of your rankings will harm the chances of your favorite candidates to win. Simply put: in an STV election you can and should rank all the candidates according to how much you like or dislike them.

I have heard several people say that you should only rank candidates you like, and don’t rank any candidates you don’t want to win. This is a misconception. Under many non-STV systems, this is a good strategy. But with STV the only reason not to provide rankings for candidates you dislike is if you legitimately dislike them all equally. If you really truly don’t care which of the bad candidates might win, then you can leave those bottom rankings blank. But in my experience, most people do have some opinions about which candidates they somewhat dislike versus those that they really really would hate to see win. If you have these opinions, it’s okay to express them on your ballot. To emphasize it again: providing rankings for your disliked candidates will never harm the candidates you truly like.

We can see how this is true by examining how votes are tallied in an STV election. The important thing to remember is that you only have one vote, even though you have many rankings that express your instructions about how your vote should be allocated. Hence the “Single” in “Single Transferable Vote”. As the votes are counted in rounds (where some candidates in each round are elected if they’re above the threshold, or some candidates are eliminated when they’re on the bottom of the stack) your vote always stays with your highest-ranked candidate who is still in the running at each round. The only way your vote would ever transfer to one of your disliked candidates is if all of your more preferred candidates have already been elected or already been eliminated. So the only time where your vote would start counting for your disliked candidates is when your disliked candidates are the only ones left in the running. No matter what you do, the election is over for your favorite candidates. At this point, wouldn’t you still want to have some say about which of the disliked candidates goes on to win? If you ranked all the candidates, you would still have some say to help elect the lesser of these evils. If you left your lower rankings blank, then you would be sitting out these final rounds of the tally.

Here’s an article from New Zealand describing STV voting strategy in civic elections, which also concludes that there’s no harm in ranking candidates you dislike:

Finally, however, I want to reiterate that you don’t have to rank all the candidates. If you truly do not have an opinion about some names on your ballot, it’s fine to leave them unranked. This will not make your ballot invalid, and it will not help nor hurt your favorite candidates. If you feel like ranking all the candidates is overwhelming and might deter you from voting at all, don’t worry about it! Even if you only rank one candidate, that’s still better than not voting at all!

The point of this post is not to stress you out and make you feel like you should rank everyone. I merely want to drive home the point that you shouldn’t hold back for fear of hurting your favorites.

[Crossposted from Medium and OpenStreetMap]

Posted in Mapping, not_geowebchat | Tagged , | Leave a comment

Video: Getting Native Reservations on OpenStreetMap

[crossposted to]

Last month I gave a presentation at the North American Cartographic Information Society (NACIS) conference. NACIS is always one of my favorite conference, and you can now watch videos of most of the presentations on YouTube here

My talk was about getting Native Reservations to show up on OpenStreetMap. I blogged about this previously: “It’s about time OpenStreetMap showed native lands on the map”. Now you can watch the video of my presentation:

You can also follow along with the slides on SpeakerDeck.

Posted in Mapping, not_geowebchat | Leave a comment

It’s about time OpenStreetMap showed native lands on the map

[crossposted to]

I’ve been using OpenStreetMap (OSM) for over 12 years now, and to this day I’m still impressed and amazed by how far this project has come. The audacity of OpenStreetMap’s core ideals–that volunteers can create and maintain a detailed map of the world, and that this collaborative map would be more democratic and fair than any other–are constantly inspiring, and also frequently frustrating when we as a community have a hard time living up to those ideals.

We often say that OSM is a collaborative map of the world, but in reality, it’s a collaborative database of map features. There is only one database, but there are many possible maps that can be made from that data. But when it comes down to it, there’s still one map that matters most to the OSM community, and that’s the “default” map that you see on the OpenStreetMap website.

One thing that’s always frustrated me about that map is that it doesn’t include native reservations. You can add reservations to the database, (and many of us have been doing just that) but they don’t show up on the default map. As far as I can tell, no one has ever tried to add them. But since OSM is a collaborative, open-source project, I have nobody to blame for that but myself. If you don’t like how something works in an open source project, then try to fix it yourself! So let’s try.

I just filed a “pull request” (which is open source speak for “here is a suggested modification to the code that I’d like you to consider”) on the GitHub repository for the default OSM map style. Here’s my pull request, #3521. And here’s the discussion issue to go with it, #3520. It’s just a simple change, but if they accept my request, then native reservations will start showing up on the map. It should look a bit like this:

Screen Shot 2018-11-22 at 22 Nov 11.04.23

And like this:

Screen Shot 2018-11-22 at 22 Nov 11.09.40

(See the GitHub discussion for more images).

If you feel like you know your way around GitHub and/or OpenStreetMap, please join the discussion and help out.

As someone who was born into a settler culture, I’ve lived my whole life on native land. Some of it was “legally” ceded under threat of force and questionable treaties, and some of it remains unceded to this day. These native reservations that should show up on the map are tiny compared to the traditional lands of the native people of North America, but mapping reservations is the very least we can do as a start. To see a glimpse of the full extent of claimed and traditional territory, check out the excellent map at

Screen Shot 2018-11-22 at 22 Nov 1.22.31

Today is American Thanksgiving, and I give thanks to the Lhaq’temish (Lummi), the Nuxwsa’7aq (Nooksack), the Duwamish, the Ohlone, the Lenape, the xʷməθkʷəy̓əm (Musqueam), and all the other indigenous peoples who once lived and still do live on the lands that I’ve been lucky to call home.


Posted in Mapping, not_geowebchat | 3 Responses

OpenStreetMap past(s), OpenStreetMap future(s)

[Crossposted from Slides at]

I gave a talk at AAG last week, as part of a session about OpenStreetMap data analysis.

I followed three presentations by some of my favorite OSM researchers, Sterling Quinn (@SterlingGIS), Indy Hurt (@IndyMapper), and Jennings Anderson (@JenningsatCU), all of them using OSM history data to see what it tells us about OSM’s past and its present. You can read more about their presentations in Diana Stinton’s article for Directions Magazine: “The simple map that became a global movement.”

My own dissertation research also looks at OSM’s history data, but for this presentation I wanted to try speculating about OpenStreetMap’s future. Specifically, what if you take a chart that looks like this, and extrapolate what happens if the number of nodes keeps going up up up:

Like all of my co-presenters, we’re really not that interested in counting nodes, but we’re more interested in what those nodes tell us about the people who make up OpenStreetMap. You may have heard recently that OSM passed 2 million registered users, but the reality is that most of those people have never even edited OSM. A more meaningful statistic is the count of users who have been active editors each month. Right now the number is around 25,000 people. Smaller than 2 million, but still steadily increasing:

In my research I make a lot of comparisons with Wikipedia, which is a much bigger and older project than OSM, but similar in many ways. Wikipedia is also still growing in size, but if you look closely you’ll see that the rate of new articles has been slowing down for a long time, since 2007 approximately.

The same thing is true about Wikipedia’s users. Their monthly count of active editors has been dropping since 2007. A smaller number of people is doing more and more of the work.

If you talk to Wikipedia researchers, they’ve been freaking out about this statistic for a long time. Nobody knows exactly why it’s happening. It’s probably caused by a variety of factors, and one possibility (to simplify things greatly) is that the Wikipedia community has become increasingly unwelcoming and difficult to become a part of. Or at least that there are enough difficult people to deal with that it drives away new contributors. (Those who have been active in the OSM community might notice some parallels here.)

Another possible reason is Wikipedia’s Notability Guideline. Basically, Wikipedia has come to a consensus that there are only some topics that are notable enough to be in an encyclopedia. Any new articles that aren’t considered notable are candidates for speedy deletion.

Of course, there are many Wikipedians who argue that Wikipedia shouldn’t be held to the standards of a traditional encyclopedia: there are no space constraints because it’s not printed on paper, so why not have an article about basically everything, notable or not?

These two factions became known as Inclusionists and Deletionists, and pretty much everyone agrees that the Deletionists won.

However, this is one of the key places where OSM differs from Wikipedia. OpenStreetMap has no notability rule! An arbitrary amount of detail is theoretically possible. When you’re done mapping roads, you can start mapping sidewalks. When you’re done with sidewalks, you can map mailboxes, trees, and benches. Nobody knows where the level of detail will end.

But if OSM allows this much detail, somebody has to maintain it!

This question of maintenance is the key focus of my dissertation research. Who maintains OSM? Are they the same people who mapped the roads to begin with, or do different people come along to do maintenance? Is there enough maintenance happening to keep OSM up-to-date?

In my research I call this “map gardening”, borrowing the concept of “wiki gardening” from the community of wikis (Wikipedia being only one of these). A wiki gardener is someone who doesn’t necessarily write new articles, but instead enjoys fixing typos and grammar in existing articles, fixing up formatting and broken links, basically doing all the thankless and unsexy tasks that are necessary to keep a wiki functioning. Presumably a similar “map gardening” must exist in OSM, so what does it look like?

And what does it look like going into the future?

Here I’d like to step back, way back, and borrow an analogy from cosmology, the study of the life and death of the universe. Following the Big Bang, the universe expanded rapidly. After a while, the expansion slowed down, but recent studies have found that it’s actually speeding back up again. Cosmologists think there is something called dark energy that is causing this acceleration, but nobody knows how much dark energy is out there. If it’s a lot, then the universe will keep expanding and eventually even molecules and atoms will be torn apart. This is called the Big Rip. If there’s not much dark energy out there, then eventually gravity will overcome it and the universe will collapse into the Big Crunch.

So what are the “cosmological” futures for OSM? The number of new features (points, lines, polygons) could keep increasing, or maybe that pace will slow down or stop entirely. Similarly, the amount of maintenance edits (those “map gardening” tasks) could keep growing, or they could slow down to a trickle. The balance between those two activities could lead to the OSM equivalent of a Big Rip, a Big Crunch, or something else entirely.

Here are (at least) four scenarios that might occur:

But before we look at those scenarios, here’s a chart (not with real data, yet) that illustrates the possibilities. Note that this chart is different from the cosmological chart that I just showed. Instead of time along the bottom axis, this is a cumulative chart where time moves somewhere up and to the right.

As people create new nodes in OSM, the dot moves to the right. Every time someone edits an existing node, the dot moves upward on the chart. Because it’s cumulative, the line will never curve downward, or bend backward to the left. Each year’s worth of edits moves the dot some amount right, up, or both. (Also note, for simplicity’s sake I’m ignoring all the lines and areas in OSM, and only looking at the raw points, which OSM calls “nodes”).

Now let’s look at the four scenarios.

#1. Ghost town

Our first scenario is the “Ghost town”, where new nodes slow down, and so do the modifications. Basically, this is what happens if everyone gets bored of OSM (or if community disfunction causes everyone to leave).

It wouldn’t necessarily look like this: (although this is the first result when you search for “ghost town” in OpenStreetMap).

In fact, the Ghost Town scenario might look like a fully complete street map. But it would be slowly getting out of date, and no one would be increasing the amount of detail. It would become a snapshot in time.

#2: Garden

The second scenario is what happens if people stop adding new features to OSM, but they continue to edit them and keep them up to date. Maybe this would happen if OSM institutes something like Wikipedia’s Notability Rule. Perhaps OSM decides that streets and addresses are good to have, but trees and mailboxes are too much detail.

But this scenario requires a large community of OSM editors who enjoy maintenance. There will always be new buildings built and old ones torn down, roads that are widened or redirected, river banks that change their course. All of these things need to be updated in OSM if it’s going to stay useful.

For example, here’s a nice garden in OSM, next to some well-mapped riverbanks that will be shifting and changing year after year.

Here’s another lovely garden. (Of course, I’m talking about all kinds of OSM features, not just literal gardens… but if you do find any nice examples of gardens in OSM, please send me a tweet!)

#3: Borgesian map

The third scenario is what happens if people keep adding more and more detail to OSM, but nobody can keep up maintaining it.

In this scenario, eventually everyone has mapped all the streets and sidewalks, and they start mapping every tree and shrub, maybe even every blade of grass (to borrow Harry Wood’s “most insane” example from his 2011 talk at State of the Map about OSM as a garden).

Eventually, OSM would approach the 1:1 scale map described by Lewis Carroll, and later in a short story by Jorge Luis Borges. In Borges’s story, cartographers succeeded in creating a 1:1 map, only to find it impossible to use. Eventually they abandon the map, parts of which can still be found scattered about in the desert.

In OSM, a 1:1 map without enough maintenance would be equally useless. It might not be fully abandoned, as people keep adding more and more data, but everything they did add would become out-of-date and impossible to verify. The OSM database would be cluttered with useless information.

But we’re probably not yet at the limit of detail that is both useful and (potentially) maintainable. OSM already has some proposals underway about mapping roads as areas instead of lines. Here’s an example of some municipal data (not from OSM) visualized by Lou Huang at Mapzen, showing curblines maintained by the city of Philadelphia. I won’t be surprised is OSM volunteers start adding data at this resolution.

But then where do we stop? As another example of municipal micromapping, here are the outlines of all the street markings painted by the city of Cambridge, Massachusetts. Surely some amateur mapper in Germany with too much time on his/her hands is thinking about how to tag features like these in OSM…

#4: Singularity:

But what if Borges’s 1:1 map doesn’t get abandoned to crumble apart in the desert? What if, somehow, OSM keeps adding features, but the community keeps maintaining those features too? What if OSM didn’t just have 25,000 monthly editors, but actually did have 2 million or 25 million editors checking OSM and fixing data every day?

I’m calling this scenario The Singularity, but you’ll have to excuse me for mixing my metaphors. I’m not talking about a cosmological singularity like a black hole, or the Big Bang. Instead I’m borrowing from Ray Kurzweil’s idea of rapidly accelerating computational power and information growth. Partly I like this concept because the singularity is the point past which we can’t predict or imagine what would happen, and I can’t really imagine what OSM would look like if it were a constantly-maintained 1:1 map. But Kurzweil’s singularity is also relevant because OSM probably couldn’t achieve a perfectly up-to-date 1:1 map without the help of algorithms and machine intelligence. But that’s a topic for another presentation.

Who knows what that would look like? The gardens of Versailles in OpenStreetMap are the most detailed gardens I could find, but this level of detail might only be the beginning.


So we’ve spent a lot of time speculating about what these different scenarios might look like, and I’ve shown charts that illustrate how we might see those scenarios manifest themselves in the data. But what does the real data look like?

Here’s the chart showing the OpenStreetMap planet file, from the earliest OSM nodes around 2005, up to January 1st 2016. The line shows the cumulative count of nodes created and nodes edited for each month, with dots every January.

There are a few surprising things about this chart that I didn’t expect to see. In the first few years, we see mostly new nodes added, and not a whole lot of modified nodes; that’s to be expected. You can see there were more new nodes in 2007 than there were in 2008, mostly due to the TIGER data import that happened in late 2007. Then in 2008 and especially 2009, we see a significant number of modifications. I’m not sure what was happening during this time to explain this burst of gardening. It doesn’t correlate exactly with changes in the OSM data structure (which might require fixing features that were incorrectly translated from one datatype to another), and it doesn’t match up with the availability of new higher-resolution satellite imagery (which might have triggered spurts of gardening where people would improve the geometry of poorly-traced roads). That early spike of gardening certainly merits more research.

The other striking aspect of this chart is the steady, smooth line from 2010 to the present day. It’s shocking to think that when you sum up all the editing activity all over the world in OSM, it always adds up to the exact same ratio of new features to modified features. From 2010 onward, every month in OSM, there were roughly three new features for every one modification of a feature. Did OSM stumble upon some perfect, magic balance that will be maintained forever? What is special about that ratio?

But if the study of geography teaches us anything, it’s that you can’t look at the whole world as a homogenous system. We need to zoom in on the local dynamics of the OSM community, not just look at the planet file as a whole. How has OSM evolved on smaller scales?

Here’s London, the place where OSM got started. It follows a similar path as the planet does overall. But if you look closely the spacing between years, it starting to slow down (even while the ratio between node creation and node modification is staying steady). Is London pulling back from a course towards the singularity? If it slows down too much, will it become a ghost town? Maybe the map of London is getting close to being “finished”?

However, if we look at Berlin, another extremely well-mapped city with a strong OSM community, we see something different. In the last two years, when London slowed down, Berlin sped up! Here they are still finding new things to map.

Tokyo is also still adding new features, although it might be slowing down a bit, like London. But one key difference between Tokyo and the first two is that the number of modified nodes is significantly lower compared to created nodes (the chart is further down toward the right). Tokyo is more on track to become a Borgesian map.

In a place like Port-au-Prince, Haiti, we can see the signature of an intense burst of humanitarian mapping after the 2010 earthquake. We also see sporadic bursts of subsequent activity: in some years there is almost no activity, but in other years there is a lively pace of new features with a bit of maintenance. This is an example of a place where a community is struggling to take root and avoid becoming a ghost town.

In San Francisco we can see the early influence of the TIGER import (the first year which is flat against the X axis: all new imported nodes, no maintenance). But in later years we see a strong and growing rate of activity: in relative terms, the TIGER data is just a blip, far in the past. More worrisome is the trend of the line, bending more towards the right instead of upwards. If San Francisco doesn’t increase the amount of gardening edits, all this rich data will become out of date and obsolete.

Finally, Moscow. Another well-mapped city with a strong community, similar to London or Berlin. But of all the cities we’ve looked at, the slope of the line is the steepest: Moscow has its own blend of node creators and node maintainers, with significantly higher rate of maintenance than anywhere else! Is this a cultural difference within the OSM community? Does it mean Moscow’s map is more up-to-date and better maintained? It will be fascinating to find out!

Finally, these charts can’t really tell us anything about how much maintenance is necessary to keep OSM at some minimum level of quality. But we can start thinking about what that equation would look like. We know there are at least two reasons why we need maintenance: to fix human error in the node creation process, and to keep OSM up-to-date to reflect changes out in the real world. The human error rate is a function of the number of new nodes (and also errors during the process of maintenance, we can ignore those for now), while the rate of real-world change is a function of the number of features in OSM that reflect features in the real world. If OSM decides to include features for blade of grass, that’s a lot of maintenance edits that will be required whenever someone mows the lawn.

Here’s what a first stab at that equation looks like. All the values are unknowns at this point, but one thing is clear: “map gardening” shouldn’t be and can’t be just an afterthought. In the long run, without maintenance OSM won’t add up to much.

I would love to hear what you think about this research. Please get in touch!

UPDATE: Bill Morris was quick to give an opinion: “I’m definitely voting ‘Borgesian map’ as the likely outcome here.” …which made me think, I should do a twitter poll. So let me know what you think will happen with OpenStreetMap. Remember that it might be years or decades before we know for sure: [twitter link]

Posted in Mapping, Networks, not_geowebchat | 1 Response

#geowebchat transcript, 5 January 2016: Predictions for 2016

@mappingmashups Jan 05, 9:45am Today on #geowebchat: share your #geospatial predictions for #2016! Join us at 12pm PST, Tuesday January 5th. Please RT! #gistribe

@mappingmashups Jan 05, 12:02pm Hello everyone joining today’s #geowebchat. Today we’re going to be making predictions for #2016. Feel free to join the chat!

@geoparadigm Jan 05, 12:02pm Is this thing on? #geowebchat

@mappingmashups Jan 05, 12:02pm As with all twitter chats, make sure you include the hashtag #geowebchat in your tweets to follow along. Or mute that hashtag to ignore us.

@mappingmashups Jan 05, 12:03pm You can also try to follow along with #geowebchat. More info about the chat here:

@mappingmashups Jan 05, 12:04pm @geoparadigm Welcome Alex, you do want to go out on a limb and make our first #geowebchat predictions?

@wildlifegisgirl Jan 05, 12:05pm Hello from Boulder CO #geowebchat

@geoparadigm Jan 05, 12:07pm Looking into the crystal ball…. I think #OpenSource will continue to be huge in the Geo space. #geowebchat

@mappingmashups Jan 05, 12:07pm @wildlifegisgirl Welcome Emily, and welcome #gistribe to #geowebchat!

@wildlifegisgirl Jan 05, 12:08pm +1 RT @geoparadigm: Looking into the crystal ball…. I think #OpenSource will continue to be huge in the Geo space. #geowebchat

@mappingmashups Jan 05, 12:09pm @geoparadigm Will there be any big new players joining #OpenSource geo, or will the innovation keep coming from familiar names? #geowebchat

@geoparadigm Jan 05, 12:10pm 2016 will be the year of maps and design. Lots of beautiful maps and visualizations being made by the masses. #geowebchat

@mappingmashups Jan 05, 12:10pm @geoparadigm New players might be new upstarts, or could be existing big names switching to #opensource… #geowebchat

@wildlifegisgirl Jan 05, 12:10pm @mappingmashups thanks Alan! I predict that the @geohipster 2016 Calendar will take over the world once and for all #geowebchat

@geoparadigm Jan 05, 12:12pm @mappingmashups I predict a surprising acquisition of a new upstart… #geowebchat

@mappingmashups Jan 05, 12:12pm @wildlifegisgirl So this is the year that @geohipster goes mainstream?! ;) #geowebchat

@Steven_Ramage Jan 05, 12:13pm I hope/predict some big shifts in how global geospatial policy is positively impacted by @UNGGIM in 2016 #geowebchat

@jQueryGeo Jan 05, 12:13pm Where will we go for great spatial data in 2016? And how will we know to go there? #geowebchat

@mappingmashups Jan 05, 12:13pm @geoparadigm hah! That’s possible! Things move so fast that right now we might not even know the name of that upstart! #geowebchat

@mappingmashups Jan 05, 12:14pm @geoparadigm A year ago we might not have known about a cool company like Mapsense, and then they were acquired by end of year! #geowebchat

@Steven_Ramage Jan 05, 12:15pm I also predict greater global awareness around the challenges of location referencing and addressing! #geowebchat

@geoparadigm Jan 05, 12:16pm @jQueryGeo We will go to the drones, and we will know when we hear an annoying buzzing sound overhead :) #geowebchat #drones

@dvolps Jan 05, 12:16pm 10 yrs ago, if you told me a major Auto OEM, a taxi company, & Apple would each become global map makers, I’d have scoffed #geowebchat

@polemic Jan 05, 12:17pm Oh hai #geowebchat tuning in from sunny Auckland, New Zealand.

@mappingmashups Jan 05, 12:18pm @polemic Welcome! I’m glad our timeslot works for you down there! #geowebchat

@mappingmashups Jan 05, 12:20pm @dvolps Are you inviting us to try making 10 year predictions? :) Even 1 year is hard, but I’d love some long-range guesses too! #geowebchat

@geoparadigm Jan 05, 12:20pm Prediction in 2016 (10 year): Geospatial community key to solving #climatechange #geowebchat

@mappingmashups Jan 05, 12:21pm @geoparadigm @jQueryGeo For sure #drones will still be big news. Any guess at the most shocking #drone story we’ll see in 2016? #geowebchat

@wildlifegisgirl Jan 05, 12:23pm In 10 years, even the professionals will be doing all of our GIS from mobile devices #NoMoreOffices #geowebchat

@spara Jan 05, 12:23pm Indoor mapping will heat up – see Project Tango #geowebchat

@geoparadigm Jan 05, 12:25pm Toyota’s own realtime streetview. Will more car companies purchase geospatial companies in 2016? #geowebchat

@jeresuikkila Jan 05, 12:25pm @mappingmashups @dvolps I wouldn’t dare to predict that far right now. So much happening in automated driving right now #geowebchat

@GonzoEarth Jan 05, 12:25pm big uptick in crowdsourced weather reporting and maps #geowebchat

@karldonert Jan 05, 12:26pm 2016: the year of digital data dashboards. Encouraging people to interact with beautiful maps & visualizations #geowebchat

@mapperz Jan 05, 12:27pm @mappingmashups @dvolps VR might make it if we shrink them goggles… #geowebchat

@UrbDemogrphics Jan 05, 12:29pm @geoparadigm yes, with lots of repeated maps from previous years published as new ones #geowebchat

@geoparadigm Jan 05, 12:30pm @UrbDemogrphics If you haven’t seen #popvssoda you really need to. It’s a classic! #geowebchat

@mappingmashups Jan 05, 12:31pm What does #geowebchat predict for the future of #openstreetmap this year? What will be the big #OSM stories in 2016?

@mapperz Jan 05, 12:34pm @jeresuikkila @mappingmashups @dvolps needs Ultra High Speed connectivity…. IEEE802.11ay range 3km to work #geowebchat

@geoparadigm Jan 05, 12:35pm Will folks embrace OpenStreetMap for navigation in 2016 and use Scout? #osm #geowebchat

@geoparadigm Jan 05, 12:38pm Will mappers take to hoverboards in 2016? #thefuture #geowebchat

@geoparadigm Jan 05, 12:40pm @mappingmashups my fake start-up gets acquired #geowebchat

@geoparadigm Jan 05, 12:41pm Will a practical use be found for @what3words in 2016, and will everyone start using it? I think that is very likely. #geowebchat

@polemic Jan 05, 12:41pm #geowebchat 2016: better use of geo and mapping in civil advocacy, e.g. around PT, infrastructure, planning etc.

@dvolps Jan 05, 12:42pm @mappingmashups more & extended mobile data collection & editing toolkits #geowebchat

@jQueryGeo Jan 05, 12:44pm @mappingmashups #openstreetmap will continue to not have true polygons or closed shapes in 2016 #geowebchat

@UrbDemogrphics Jan 05, 12:46pm @polemic yes, with more widespread use of #GTFS and Real-time transit data #geowebchat @mappingmashups

@geoparadigm Jan 05, 12:35pm Will folks embrace OpenStreetMap for navigation in 2016 and use Scout? #osm #geowebchat

@wildlifegisgirl Jan 05, 12:47pm @jonahadkins why do you say fake? #geowebchat

@Steven_Ramage Jan 05, 12:13pm I hope/predict some big shifts in how global geospatial policy is positively impacted by @UNGGIM in 2016 #geowebchat

@mappingmashups Jan 05, 12:52pm What are your predictions for the most surprising new #Maptime location that will appear in #2016? #geowebchat

@mappingmashups Jan 05, 12:58pm Any final #geo predictions for 2016 before we wrap up this month’s #geowebchat?

@prushforth Jan 05, 1:00pm In 2016, I am hoping/working for a good community to develop around #maps4html… #geowebchat

@mappingmashups Jan 05, 1:00pm Thanks for joining today’s #geowebchat, everybody. The transcript will be at Next chat will be in 1 month, Feb 2nd.

@mapperz Jan 05, 1:04pm @mappingmashups postgres to support 5d…. #geowebchat

Posted in geowebchat, Mapping, Networks | Leave a comment