Re: [josm-dev] Checking tags
On Fr, Mär 27, 2015 at 10:48:58 +0100, Paul Hartmann wrote: On 27.03.2015 09:07, Jochen Topf wrote: On Fri, Mar 27, 2015 at 12:51:12AM +0100, Paul Hartmann wrote: On 24.03.2015 09:50, Jochen Topf wrote: This way we have: light green means we know that tag and it's accepted. I would not require accepted but settle with documented. It should recognize complicated tags like healthcare:speciality=ophthalmology and parking:lane:both:parallel=on_street both in key and value, otherwise it would be pointless as a spellchecker. I guess a lot of wiki pages need to be adapted, so this information can be extracted. But there would be a value in that beyond the JOSM use. If I learned one thing from years of working on taginfo is that there is no correlation between accepted, documented, often used or anything like that. From my point of view, we can leave it up to the user to decide if a tag is accepted enough or not. What I'd find useful though, is some kind of quick spellchecking. This means it is enough simply extract all tags from the wiki, maybe along with an exclusion list that is maintained by hand. Unfortunately there a many many tags commonly used that are not in the wiki. So that approach is not enough. Thats why I created the lists mentioned earlier in this discussion that does a bit more than just taking tags from the wiki. But it would do just what you want: create a simple spell-checking. I started out calling that list the green list, but I see now it is better suited as the grey list, because it is autogenerated and contains questionable tags, too, as I have mentioned in a posting further up in the discussion. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On Fr, Mär 27, 2015 at 10:48:58 +0100, Paul Hartmann wrote:
From my point of view, we can leave it up to the user to decide if a tag is
accepted enough or not. What I'd find useful though, is some kind of quick
spellchecking. This means it is enough simply extract all tags from the
wiki, maybe along with an exclusion list that is maintained by hand.
As I understand, you already do this for taginfo, but the algorithm does not
capture all tag combinations. [1]
[...]
[1] for example, I see {{tag|healthcare:speciality|ophthalmology}} on the
wiki page, but no entry on
http://taginfo.openstreetmap.org/tags/healthcare:speciality=ophthalmology#wiki.
This is all a bit off-topic here, but I want to answer to this.
The {{tag|healthcare:speciality|ophthalmology}} just creates a link to a
tag page, in this case, a non-existing Wiki page called
Tag:healthcare:speciality=ophthalmology. Taginfo can only pick up
existing pages, otherwise where would it get the tag description etc? In
this case it seems whoever invented this tagging scheme decided to document
it in a non-standard way where all values for healthcare:speciality are
document in a table on the Key:healthcare page instead of in their own
Tag pages.
I realize that having such a table view is useful, but we still need the
Tag: pages. I have made some efforts towards creating such overview tables
automatically from the information taken from Key: and Tag: pages, but it
is unclear how to best do this. See here for some details:
http://blog.jochentopf.com/2013-02-25-using-taginfo-to-create-map-feature-tables.html
Jochen
--
Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On Fri, Mar 27, 2015 at 12:51:12AM +0100, Paul Hartmann wrote: On 24.03.2015 09:50, Jochen Topf wrote: This way we have: light green means we know that tag and it's accepted. I would not require accepted but settle with documented. It should recognize complicated tags like healthcare:speciality=ophthalmology and parking:lane:both:parallel=on_street both in key and value, otherwise it would be pointless as a spellchecker. I guess a lot of wiki pages need to be adapted, so this information can be extracted. But there would be a value in that beyond the JOSM use. If I learned one thing from years of working on taginfo is that there is no correlation between accepted, documented, often used or anything like that. This is a rather difficult task, but could certainly be useful, and as you say, something beyond the JOSM use, so maybe it should be discussed in a larger forum. I think in the end it would come down to a few people coming up with some criteria and creating such as list. Then the community can discuss the criteria and discuss this list. But before somebody makes the effort, it is all rather theoretical. grey like now means any other tags but is actually a positive list of tags that are very common and/or docmented on the wiki etc. light yellow looks suspicious, take extra care and re-check, is actually the list of all other tags we don't know anything about light red means we know the tag is bad. Maybe it is better to go forward with the grey/yellow/red part first, which is somewhat easier, and add the green part later if and when we have such a list. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-173-7019282 ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On 27.03.2015 09:07, Jochen Topf wrote:
On Fri, Mar 27, 2015 at 12:51:12AM +0100, Paul Hartmann wrote:
On 24.03.2015 09:50, Jochen Topf wrote:
This way we have:
light green means we know that tag and it's accepted.
I would not require accepted but settle with documented.
It should recognize complicated tags like
healthcare:speciality=ophthalmology and parking:lane:both:parallel=on_street
both in key and value, otherwise it would be pointless as a spellchecker. I
guess a lot of wiki pages need to be adapted, so this information can be
extracted. But there would be a value in that beyond the JOSM use.
If I learned one thing from years of working on taginfo is that there is no
correlation between accepted, documented, often used or anything like
that.
From my point of view, we can leave it up to the user to decide if a
tag is accepted enough or not. What I'd find useful though, is some kind
of quick spellchecking. This means it is enough simply extract all tags
from the wiki, maybe along with an exclusion list that is maintained by
hand.
As I understand, you already do this for taginfo, but the algorithm does
not capture all tag combinations. [1]
If a user finds a documented tag that is not recognized in JOSM, they
should be able to fix the formatting in the wiki and have and updated
list in JOSM within a day or so.
This is a rather difficult task, but could certainly be useful, and as
you say, something beyond the JOSM use, so maybe it should be discussed in a
larger forum. I think in the end it would come down to a few people coming up
with some criteria and creating such as list. Then the community can discuss
the criteria and discuss this list. But before somebody makes the effort, it is
all rather theoretical.
grey like now means any other tags but is actually a positive list of
tags that are very common and/or docmented on the wiki etc.
light yellow looks suspicious, take extra care and re-check, is actually
the list of all other tags we don't know anything about
light red means we know the tag is bad.
Maybe it is better to go forward with the grey/yellow/red part first, which
is somewhat easier, and add the green part later if and when we have such
a list.
The validator already checks suspicious and bad tags. I see limited use
in duplicating this functionality.
[1] for example, I see {{tag|healthcare:speciality|ophthalmology}} on
the wiki page, but no entry on
http://taginfo.openstreetmap.org/tags/healthcare:speciality=ophthalmology#wiki.
Paul
___
josm-dev mailing list
josm-dev@openstreetmap.org
https://lists.openstreetmap.org/listinfo/josm-dev
Re: [josm-dev] Checking tags
On 27.03.2015 11:46, Jochen Topf wrote: On Fr, Mär 27, 2015 at 10:48:58 +0100, Paul Hartmann wrote: From my point of view, we can leave it up to the user to decide if a tag is accepted enough or not. What I'd find useful though, is some kind of quick spellchecking. This means it is enough simply extract all tags from the wiki, maybe along with an exclusion list that is maintained by hand. Unfortunately there a many many tags commonly used that are not in the wiki. So that approach is not enough. I would see this as an additional benefit because it creates an incentive to document tags and improve the wiki. Thats why I created the lists mentioned earlier in this discussion that does a bit more than just taking tags from the wiki. But it would do just what you want: create a simple spell-checking. I started out calling that list the green list, but I see now it is better suited as the grey list, because it is autogenerated and contains questionable tags, too, as I have mentioned in a posting further up in the discussion. A normal spellchecker marks every word it doesn't find in the dictionary as error. We cannot do that: There are always legitimate tags we don't know about. All we can do is give positive feedback for tags we do know (i.e. mark them green). As you say, the good.gz list isn't suitable for green markup. Paul ___ josm-dev mailing list josm-dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/josm-dev
[OSM-dev] GSoC: Improve the UI of OsmAnd
Hi, I do not even know, if OsmAnd is even supported by the OpenStreetMap project, but I was so annoyed of it this week that I wrote a proposal to improve it. The proposal is public, so last-minute GSoC applications might still be possible for the same project, since I belive that my JOSM project will be more beneficial to OSM and that it is a nicer, more compact project ideal for GSoC. http://www.google-melange.com/gsoc/proposal/public/google/gsoc2015/michaelz/5700735861784576 Regards, Michael ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] [GSOC] - Extend GraphHopper to support Multi-Floor Indoor Navigation
My name is Muhammad ElTaweel, i'm a final-year undergraduate Computer Engineering student at Faculty of Engineering, Mansoura University, Egypt. i'm working in Indoor Navigation Positioning [ WiFi / Dead-Reckoning ] System. and i'm already using the Awesome GraphHopper as an offline routing engine on the Android App, alongside with Mapsforge / Nutiteq different MapViews implementations. While outdoor mapping navigation is mature now, The demand for indoor navigation is booming, because people spend most of their time indoors. GraphHopper is able to work with indoor data as it does with the outdoor, but for a single floor. There is no support for Multi-Floor Indoor Navigation! So i proposed to extend GraphHopper to support Multi-Floor Indoor Navigation. I introduced myself to Peter GraphHopper Author few days ago and he is interested in the idea. then i started working on the proposal and just finished. The proposal is on google melange now and i hope to get feedback and reviews from the mentors. sorry for being late to introduce myself here. Regards, Muhammad. ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] New features in iD - looking for feedback and beta testers..
Hi Everyone… It’s been a busy few months for the iD team, and we have a handful of new features that will be launching soon. We’d love to get some mappers to beta test and provide feedback! These features are available now by using the latest development branch of iD hosted at http://openstreetmap.us/iD/master/ http://openstreetmap.us/iD/master/ Please try them out and report any issues or questions on our Github issue tracker: https://github.com/openstreetmap/iD/issues https://github.com/openstreetmap/iD/issues - Copy and Paste selected features with ⌘-C and ⌘-V https://github.com/openstreetmap/iD/pull/2498 https://github.com/openstreetmap/iD/pull/2498 - Conflict Resolution iD will now check if any of your modifications conflict with edits made by other users, and will present you with a UI to see the difference and choose how to resolve the conflict. https://github.com/openstreetmap/iD/pull/2489 https://github.com/openstreetmap/iD/pull/2489 - Smarter Way Movement When moving a connected way, iD will now slide the moving way along the non-moving way, rather than “zorroing” the connection point. https://github.com/openstreetmap/iD/pull/2516 https://github.com/openstreetmap/iD/pull/2516 - Don’t delete ways that are part of a route/boundary Relation This will prevent a bunch of breaking edits to relations - Thanks RichardF! https://github.com/openstreetmap/iD/pull/2526 https://github.com/openstreetmap/iD/pull/2526 - Map-In-Map You can now bring up a locator mini-map with the ‘/‘ key. By default it displays the current area but zoomed out by -6. Zoom and pan the mini-map to quickly find and move to different locations. https://github.com/openstreetmap/iD/pull/2554 https://github.com/openstreetmap/iD/pull/2554 Thanks! Bryan___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] Summary of GSoC applications
Hi all, the deadline has passed and I'd like to notify you about the current status: We have the amazing number of 54 applications, made by 48 different students for more than 15 project ideas. I've had a look at some of them in more details and I have to tell you, that it'll be hard to choose which students we take as we have many great students and applications. Anyway, I think this will be a fun GSoC. Happy Hacking, Peda ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Summary of GSoC applications
Hi Peter, Could you elaborate where we go from here. If I understood correctly, we can enter into dialogue with the candidate students to discuss their applications and have them further improve them. By when should we assign scores to them? When does it make sense to start scoring? Should all mentors and co-mentors and dementors assign scores to all applications? What to do with the applications which merely indicate the student's willingness to participate in the GSoC, but who didn't actually select a project they wanted to work on? Good night, Polyglot 2015-03-27 23:37 GMT+01:00 Peter Barth osm-p...@won2.de: Hi all, the deadline has passed and I'd like to notify you about the current status: We have the amazing number of 54 applications, made by 48 different students for more than 15 project ideas. I've had a look at some of them in more details and I have to tell you, that it'll be hard to choose which students we take as we have many great students and applications. Anyway, I think this will be a fun GSoC. Happy Hacking, Peda ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
Re: [OSM-dev] Summary of GSoC applications
Hi Polyglot, Jo schrieb: If I understood correctly, we can enter into dialogue with the candidate students to discuss their applications and have them further improve them. you may request further details from students, you can ask questions,... it is also possible to allow students to improve their applications, but this should not happen without a good reason. By when should we assign scores to them? When does it make sense to start scoring? Should all mentors and co-mentors and dementors assign scores to all applications? You may start scoring those projects you're willing to mentor. Especially you should request mentorship for those projects so we can add you to it. Regarding the scoring details, some mentors have already expressed their opinion to discuss this on a mentor-only list. I'll write a second mail in a minute with some more details... What to do with the applications which merely indicate the student's willingness to participate in the GSoC, but who didn't actually select a project they wanted to work on? We simply ignore them. If a student is not able to write a proper application within the normal timeslot and didn't introduce himself to a specific project, we should not consider him for this year's GSoC. Peda ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
[OSM-dev] GSoC mentor informations
Hi mentors, as I wrote in my other post, we have 54 applications by 48 different students, which is great. I've two notes/appeals for the mentors/devs on this list: 1. as we have many projects, we might need more help to reduce the bus factor. If you have time and feel like it, consider dropping me a mail and adding yourself as a backup mentor. 2. All mentors that are already signed in to melange, please drop me a mail with subject GSoC mentor. We'd like to talk with you about the ranking process, what you should consider,.. and for further mentor discussions. Thanks, Peda ___ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
