Closed hagenburger closed 9 years ago
Yes, we should do this!
i won't have spare time for this at the moment. if anyone want's to push a PR for this, that would be :dancers:
I can help but how would you want this? Any mockups for example. Or show the wheelmap for the location where RugB is being organized. There is also a "locations" map right now, should that go away?
@rocky-jaiswal great, thanks! I can provide some mockups with description later.
@rocky-jaiswal my idea would be very simple. i don't know how wheelmap exposes it's data, so please correct me if my idea is stupid...
as a first integration, i would add an icon to our event page (and location page) that mirrors the accessibility for the location (aka the icon that you can find on the wheelmap).
does wheelmap provide shield-urls like the things you can have for code-coverage, etc? that would be a super-simple integration, we would just have to store the wheelmap id/url/whatever with our location data.
The API is documented here: http://wheelmap.org/is/api/docs/resources/nodes.
We might need to use the API when a location is created to search for it. It’s hard to do it later if the location names don’t match automatically.
(Btw. the API is written by @christoph-buente.)
we might be able to proxy this through shields.io and render the badge there. what do you think?
To get it out quickly, I think it’s OK.
For my eyes it might not be beautiful. But what about accessibility of those badges within our website?
@hagenburger if it's properly linked and anchored, screen-readers should be fine with the badges. they are svgs, so i don't know if that is better or worse.
@rocky-jaiswal is this enough information to start?
Btw: I added the information for @bitcrowd . You can use this as a testcase for the api: http://wheelmap.org/nodes/2997279733
So i guess the idea is to get the wheelmap info for locations and show the appropriate badge. We do this when we store the locations.
If this is fine, I will work on this as soon as I can. Otherwise with this discussion's help someone else can also start with this story, I won't mind.
@rocky-jaiswal i would suggest having something that keeps the information up to date. i don't know how often it changes, but if it's user-generated content, i guess that it might be quite frequently. especially adding more information about places. that's why i suggested a badge-approache that get's proxied, so we have reasonable up-to-date information on the page. otherwise it's quite useless
Do we need automated matching (location names to names stored in Wheelmap)? I guess no. We only have little locations (in Berlin they repeat from time to time) and can do it manually by searching wheelman.org and entering the ID when creating a location.
@hagenburger yes, we should have this as an additional field on the model
I would like to work on this. But I probably would not able to do so before tuesday next week. If anyone comes first, that's fine.
@RmMsr great! Just directly discuss with @rocky-jaiswal :)
@RmMsr please go ahead. I myself had to deal with a few burning issues at work so have not worked on this so far.
in case anyone works on it, please push a branch with a pr so we can track progress
@RmMsr if you have any questions about the API, @christoph-buente can help you with that.
Thanks for the input. I could not put much effort into it till now. But want to share thoughts with you.
Given that we have a WheelMap Node ID for a location we could display the current wheelchair accessibility (yes, limited, no, unknown) as part of the location information. I would keep the colour schema (green, orange, red, grey).
To make it useable for screen readers I think we should write the information semantically into the HTML. Which means to process the lookup in the Rails backend. I suspect that the site of an event is visited more frequently the closer the event comes. Therefore I would say that the wheelchair status should not be older than one hour. I hope this might encourage people to update the location accessibility even shortly before a meetup.
For simplicity of the application and timeliness of the information I would do the API call on the fly when a event or location is requested. WheelMap requires just a single GET request to obtain the needed information. For speed and efficiency I would cache the data inside Rails.
My next steps would be:
@hagenburger I agree a automated matching of our location to a WheelMap Node would be difficult. I think that would require an interactive workflow to find the correct node or create a new one if it is missing. Just storing the ID in our database would be the best approach to get started.
A follow up issue might be a button for admins of on_ruby to register a location as new unknown node at WheelMap via API. If that is desirable. I am not sure what WheelMap's policy is for semi automatic creation of new unknown locations.
@RmMsr thanks so far!
To keept it simple, an update button in the admin section should be fine. If a location updates their status, they could just ask us (we don’t need to put too much effort in this as this is not a user-gerated content site).
New locations should be created manually at Wheelmap. This won’t happen too often (for Berlin maybe 5 times a year as soon as we have existing locations).
For the design just do something and ping me. I can have a look.
TL;DR: Displaying the data and being able to update in the first step is already awesome :)
steps as far as i see them
pushing a pr to shields.io would be a nice bonus, adding this functionality for everybody.
There has not been any status update for about 2 month. Is anyone actively working on the integration, or should i close it?
@phoet Sorry, I could not focus on the feature. If you don't mind, please leave it open some more time. I think it's worth working on.
Sure, go ahead, just looking for status!
now that i’m back home and still on vacation :relaxed: i will take a look at this.
:+1:
Rubii, I just saw the Tweet and started to tinker around. Perhaps we can merge efforts? (also vacation time here, basically) ;)
almost finished, too..
great! looks like there isn’t much left to do. tests maybe. and removing the tabs in wheelmap_api.rb
;)
i was really most interested in the wheelmap-api-client, so i might still work on a gem for that.
Here's what I've got so far in total: https://github.com/lukas2/on_ruby/commit/1eeaa3ce1f2be73732a7a24bef3a1a029695c55e
Perhaps you can use / build on it? I don't have any time for tests now, but I could take a look again later.
If you made a proper gem, that's be best of course. :)
Also pls. remove my own wheelmap-apikey perhaps.. ok gotta go.
@phoet Thank you for the comments. I'll take a look tomorrow.
You could fetch data from osm via the overpass api too. No need for an wheel map client.
@christoph-buente you speaking of this? http://overpass-api.de/
can you point us to an example for how this would work?
Yep, that's the one. Essentially it is a fast replacement of the original osm api. What you can do is ask it for places with a given name/regexp within a certain area with optional type like office or so. I prepared a example query, which takes actually XML as body. Not sure if there is an ruby/js client for it. Have a look at this:
http://overpass-turbo.eu/s/5zB
This is the actual payload transfered to overpass:
<!--
This has been generated by the overpass-turbo wizard.
Get all nodes, ways and areas with "tourism=zoo”
-->
<osm-script output="json" timeout="25">
<!-- gather results -->
<union>
<query type="node">
<!-- query for name -->
<has-kv k="name" regv="[Rr]adialsystem"/>
<!-- query for bbox -->
<bbox-query w="13.421509081363313" s="52.50602020821643" e="13.436237918636687" n="52.51500679178358"/>
</query>
<query type="way">
<!-- query for name -->
<has-kv k="name" regv="[Rr]adialsystem"/>
<!-- query for bbox -->
<bbox-query w="13.421509081363313" s="52.50602020821643" e="13.436237918636687" n="52.51500679178358"/>
</query>
<query type="relation">
<!-- query for name -->
<has-kv k="name" regv="[Rr]adialsystem"/>
<!-- query for bbox -->
<bbox-query w="13.421509081363313" s="52.50602020821643" e="13.436237918636687" n="52.51500679178358"/>
</query>
</union>
<!-- print results -->
<print mode="body" geometry="center" order="quadtile"/>
</osm-script>
What it does is: Search for node, way and relations (which are different geo types) within OSM with a name regexp and a given 1x1 km area. You can add more conditions like the type of place and so on. It will return a json object with a list elements with type and lat/lon and the osm id of course. Plus some more extra data like tags. The tag you are most interested in is: "wheelchair" wich can have the value yes/no/limited.
{
"version": 0.6,
"generator": "Overpass API",
"osm3s": {
"timestamp_osm_base": "2014-10-22T13:48:02Z",
"copyright": "The data included in this document is from www.openstreetmap.org. The data is made available under ODbL."
},
"elements": [
{
"type": "way",
"id": 42163186,
"center": {
"lat": 52.5103095,
"lon": 13.4286402
},
"nodes": [
524763649,
524763650,
524763652,
524763655,
524763649
],
"tags": {
"addr:city": "Berlin",
"addr:country": "DE",
"addr:housenumber": "33",
"addr:postcode": "10243",
"addr:street": "Holzmarktstraße",
"building": "yes",
"name": "Radialsystem V",
"website": "http://www.radialsystem.de/",
"wheelchair": "limited"
}
}
]
}
Hope that helps.
Do you think the data is superior to that of wheelmap.org? Or do I misunderstand.. is it somehow already merged in?
@christoph-buente i'm also unsure about how this might be of help here. we already know the locations, we just want the accessibility information for them. if we need to match anything, that's gonna be much more work.
It is basically the same data as wheelmap is minutely synced with osm. I just thought it was easier to use existing tools with a proper search in place. The wheelmap search is not so good and not fast either.
AFAIK we don't want to search, but lookup by id
Ok, where does that id comes from? It is manually attached to the venue? Then using the wheelmap api is perfectly fine. Also the overpass API :)
Currently you have to enter the node-id manually, yes.
@phoet just replaced httpparty with faraday, see https://github.com/lukas2/on_ruby/commit/4279de8d6758b666c0d8ff3dd418dab1f2653696 , however, I'm not grokking your views-code yet. Perhaps you can easily do the view-helper? Otherwise I can take a look tomorrow.
Also https://github.com/lukas2/on_ruby/commit/67dc286dc276b9631d02fa820048a7c79f5783ce is about getting the api-key from an ENV-variable.
Ok, i thought you want something like suggestions from a given area that might be the venue. Didn't mean to confuse you.
@christoph-buente we were thinking about that, but ditched the idea in favorite with the explicit approach of adding the wheelmap id to our database. KISS
@lukas2 yeah, my view suggestion was a bit ambiguous because the view actually uses the JSON to fill in the html on the coffescript side. so you might leave it as is (or change the code to fetch pre-rendered html-snippets from the view instead of composing them in js).
What just came to my mind: I wrote a ruby client for the standard OSM API, which i use in wheelmap to send data back. But of course it can be used to fetch single Nodes or Ways too. Have a look at: https://github.com/sozialhelden/rosemary
Just a note: There are negative ids in wheelmap. These negative ids correspond to a way with the same positive id in OSM.
Maybe that eliminates the need for an wheelmap client, even though i like the idea to have one :)
@christoph-buente any chance to get read-only api-keys, for wheelmap?
ah well... http://wheelmap.org/nodes/2323004600.json i guess that's good enough
I thought about to make read access work without api key, but i didn't find time to do. There is no difference between read and write so far. If i gave you a key, you could write too, which is not, what i want.
ok, so we’re waiting for badges/shields#287 now :)
Just added some tests: https://github.com/lukas2/on_ruby/commit/32bdeeaa5ed78535f1266e0edab6b4ac4fa46a14
Please review and critique. I've been doing iOS for too long.. ;)
@rubiii ok, i am waiting, too. :)
To make it easy to know if a location is accessible for everybody. This is especially useful for user groups like Cologne or Berlin that change locations each time.