Talk:Keypad-Mapper 3

Faster GUI Mockup for Most Common Use Cases

Hi there. After reading reviews on Google Play and using KPM myself, it struck me how entering all the numbers should be able to be much faster. Currently to enter house numbers from 2500 to 2599 requires typing in "25" at the start of every. single. number (ie all 100 times ). I thought about how we could streamline this while still being easy to use on a phone interface, and came up with the mockup below based on two kinetically scrolling "dials" showing last selected house numbers (one dial for each side of the road). It is *not* designed to replace the current interface 100% of the time, but I suspect it could 95% of the time, while being much faster (often requiring 75% less clicks). For the other 5% of the time, it would be possible to toggle to the current interface with a single click.

Take a look:

Features / Functioning:

• Entering 4 digit house numbers are reduced from 4 clicks to 1 (a 75% reduction or fourfold increase in speed).
• The twin columns of dials allow for when numbers on each side of the road vary significantly, avoiding going back and forth on the dialer^. This avoids the problems seen by just having +1,-1 buttons.
• On choosing a number in one of the dials, it would immediately be centered in the dial (eg in this example, if 2708 was tapped in the left column, the dial would scroll so tht 2708 is where 2706 is in this image)
• The last selected number is hilighted, so that where unit numbers are the only varying part, people only need to click the new letter and the direction.
• There is no need for delete / backspace keys, as alterations are made just by clicking on the correct number / letter.
• Does not do away with the traditional number pad for more unusual / complex entries. The classic number entry is accessed with the keyboard button (bottom right corner)
• This mockup shows blank space at the bottom. In reality we can extend the number of house numbers shown on the dials, and letters available, or show last entered house numbers.
• When a new house number is tapped, the dialer scrolls to put it in the center, so incrementing by the same amount^ can be achieved simply by clicking in the same place on screen.
• For initial position of number dials, either estimate nearest housenumber if a number range for this street exists, with even on left and odd (even +1) on right. Dials with kinetic scrolling make it very quick to move between a large number of house numbers. If no nearby housenumbers are found, start on classic number pad, and switch when the first number is entered, with a pop up note on how to switch back (keyboard button).
• Reduces phone keyboard typing to almost nothing, replacing it with a more mobile style kinetic interface.
• You could also allow users to double tap a number to have it entered instantly without any letters / unit numbers, or to double tap a letter to enter it instantly using the last selected number. This way they don't even need to tap the arrow buttons above. Left or right would come from which dial column was just used.

^ Solution to a problem mentioned in Play Store reviews

Github

The github link is not working --mac_do 012:25, 24 February 2013 (UTC)

we have the source code avail as a .zip file but do not know how to publish it on github. Could you do that for us? That would be great!

If you know Git a little, it needs only to create a repository, cloning and pushing data :) I cannot download the app on my Galaxy Mini, says it isn't compatible (but I have installed a CyanogenMod 7.2), via apk it could work perhaps, could you make it available to download? Thanks --Sarchittuorg (talk) 17:17, 24 February 2013 (UTC)

Git:we are no devs here :-(. I´m sure we´ll find a way.

Galaxy mini: so far the app was restricted to Android 2.3.3. We have uploaded a new version supporting 2.1 and higher to Google which will be avail in a few hours.
On our server the new version can already be downloaded. CyanogenMod 7.2: we didn´t try but we have a Galaxy mini here with standard OS and it works fine: we used that phone for testing the reduced UI for small phones.

The source code is available now at https://github.com/msemm/Keypad-Mapper-3.git

Thanks, I've downloaded the app from the website, now I want to test it during mapping :-) One proposal, on the optimized vs non - optimized layout, can you try to put a button to take notes near the textbox? (like the question mark) So it doesn't waste vertical space.. --Sarchittuorg (talk) 21:14, 25 February 2013 (UTC)

will add this idea to the whishlist

Arrows instead of L/F/R

Did you think of replacing L/F/R on buttons with respective arrows? I think it would make the interface more user-friendly and rid translators of coming up with one-letter translations for these. --Zverik (talk) 09:04, 28 February 2013 (UTC)

we discussed it even today because of a similar inquiry. What do others think about this idea? Markus59

Done

Permissions

Would you be so kind as to explain why do you need "to read phone state and identity"? I do not think my phone number or call state is any business of keypadmapper. --grin ✎ 16:28, 28 March 2013 (UTC

These credentials are required to read the cell-id information for OpenCellID. The app does NOT use any other information of the phone state and identity except MCC, MNC, LAC, cellID, signal-strength. You can use keypadmapper2 or OSMpad instead of Keypad-Mapper 3 if you do not like to grant these credentials. --Markus59 (talk) 16:35, 28 March 2013 (UTC)

Can CellID scanning turned off? --!i! 15:01, 5 April 2013 (UTC)

no. You can use keypadmapper2 if you do not want to contribute to OpenCellID

As Keypad Mapper 3 is Open Source you can of course take a look for yourself and find out that Markus' claims are in fact accurate (see here). Hopefully "TODO: UserID" will be a todo for quite some time. One thing I've noticed is that Ilya will receive my email address in case of a crash report. But hey, production software doesn't crash and you can still choose not to send the report. So all good here .) Mmd (talk) 13:37, 6 April 2013 (UTC)

pls explain your requirements regarding the userID. In the next version we will implement a generic email address that points directly to the Redmine issue tracking instance of KPM --Markus59 (talk) 14:25, 6 April 2013 (UTC)

No real issue here from my side. It seemed to be that opencellid could also receive a userID as part of the upload data. However, in Keypad Mapper 3 this userID is hardcoded to the string "TODO: UserID ". This statement was to underline that no user specific information is collected. Mmd (talk) 14:38, 6 April 2013 (UTC)

If anybody could create a patch/fork to disable the OCID functionality (if wanted by the user), this would be nice. Usually I'm very ok to help mapping that way, bad I have a very strange feeling on this, if this "feature" is hidden and a organisation doesn't introduce it at startup.--!i! 11:45, 29 September 2013 (UTC)

Indeed, OpenCellId integration might reveal quite a bit of information about you, the user of the App. Markus59 is correct in stating that no directly identifiable information about a user (such as user name, IMSI or the like) is collected. However, depending on your usage behavior the information gathered by the OpenCellID client might be suitable to track you down to your home location in the worst case. The data still doesn't say that "Joe Mapper" actually lives there. But you will get the idea.

You might ask yourself: How it this possible? Once you activate the recording mechanism at home and start walking/driving around, your current GPS location will be determined every few seconds along with the current timestamp (second resolution) and GSM/UMTS cell ID. It is eventually uploaded to ENAiKOON's server for everyone else to see on opencellids.org. Although, ENAiKOON also provides aggregated information about cell locations, the raw and detailed measurements are also accessible via opencellids.org (including the option to download it to your own machine).

Take a look at the following two screenshots: The big picture gives you an impression what a half-day's itinerary might look like, while the Detail shows you how precise the recorded probes are in fact. What you don't see on the second screenshot is that our mapper (let's call him Walter) spent around 20 minutes in the Penny supermarket on Monday afternoon. Try it out for yourself on opencellids.org, navigate to your area and display the recently uploaded traces by restricting it to a suitable date range.

We feel it is basically acceptable for an app to collect aggregated cell tower information for the benefit of everyone. However, a user should be made very well aware of the implications. Unfortunately there's no way to deactivate this feature nor to make it less aggressive in terms of "take a probe every n seconds or every x meters" as you might known from similar tools. Google Play! description doesn't mention this feature at all, you have to really dig into the Wiki or listen to FOSM / SotM 2013 presentations to find out some more details. This is quite disappointing, given that the app is considered very helpful and useful by the OSM community. I guess not (talk) 15:12, 29 September 2013 (UTC)

Unfortunatly, it's very hard to keep the data anonymous in every case. For example: There is only one inhabitant that lives at a lonely road at the countryside and he likes to track GSM BTS all the day. Then it's very easy to identify him, as he "can't hide" with the help of other users.

But as you say, more over than just the technical POV, it's about the way how a company asks for assistance by a community. IMHO in that case, it completely failed for the mentioned reasons :( --!i! 08:29, 30 September 2013 (UTC)

The help message coming with the the app contains this information very detailed.

It´s always the same story: those spreading some criticism the loudest have no idea what they are talking about.

!i!: pls stop misleading people with wrong information.

If you do not like this feature, there are three options for you:

- Do not use the software; there are many other tools you can use to contribute to OSM

- Use version 2 of the software

- Compile your own version; source code is on Github

Pls note that I personally spent more than 20.000 Euros cash so far to pay someone to develop this application.

If you want us to continue, you should support this app, not fight it with wrong facts.

If you continue like that, we will simply block the download of the app for Germany. In no other country we have such a discussion and we are not planning to waste time with it.

Make your choice. --Markus59 (talk) 14:31, 30 September 2013 (UTC)

I'm not sure to what kind of spreading wrong informations you accuse me Markus? Both user:I guess not and myself had some critics about the way how this (in our opinion) "hidden feature" is introduced and just say, that transparency here would help to avoid any misunderstandings. I'm not sure in what meaning this informations (here: personal perspectives of a problem) are wrong, esp. as I heared a other users are unhappy with the situation, too [1].

The OSM community is always welcome any company to support us in multiple ways. If the results are open source, everybody can benefit and we get a max. revenu from financial donations. BUT if a company tries to use their support to wipe possible critics away, then at least from my POV the community should take care.

Personally I don't "fight this app", otherwise why should I help you the clean up the wiki page? For me the OCID feature is a small con and most of that is based on the way how it is introduced, not the feature itself, as I pointed out already.

From my perspective EOD, as the disc gets offtopic --!i! 15:01, 30 September 2013 (UTC)

That's the ultimate solution: A germany based company is blocking the download of their app in germany because of getting "bad feedback" Great! --wambacher 23:28, 2 October 2013 (CEST)

For me personally this is utterly unacceptable and an unconditional deal-breaker: there's no way I'll ever use any app the gathers and transmits data I did not ask it to, full stop.--Max (talk) 19:12, 2 January 2015 (UTC)

Information about 'Assign each house number to the related building' in Quick start

I used the Keypad-Mapper 3 the first time yesterday. I was able to store the housenumbers and to import them in josm, together with the .gpx file. But for me it was not clear how to progress. Now: How can I assign this housenumbers with the buildings. Should I do that manually for each housenumber or is there another way? May I missed something. The most efficient way to assign each house number to the related building should be explained.

Thx for asking for the best possible process!

I am using the following process in JOSM after loading BING data, .gpx fies and .osm files into JOSM

1) activate line drawing feature that is normally used to draw a line, eg. a street.

2) double klick with the mouse somewhere on the line of the house where the house number should be finally positioned. This allows to set a new node without changing the geometry of the house.

3) Left lick on the house number node (keep the button pressed) and drag it over the new node. It is sufficient if the red frame of the house number surrounds the new node somehow

4) drop the house number by releasing the mouse button

5) press "M" on the keyboard to combine the new node and the house number node at the position of the new node

6) repeat this step for each house number of one street.

7) select all house numbers, shops etc. of this one street by holding the CRTL/ STRG key and at the same time klicking on each shop/house number. Then assign addr:street, addr:city, addr:country and addr:postcode at the same time to all these nodes.

There is no way to automate this process with reasonable quality.

An alternate method is to use the Terracer plugin. Two advantages of this method is that it is quick and adds "associatedStreet" relations. For single-address buildings ("terraces" can be done similarly):

1. Select road.
2. Select building.
3. Shift-T
4. Type surveyed number in "Lowest number" field
   1. Select "create an associatedStreet relation"
   2. De-select "delete outline way"
   3. Hit "Enter"

Vorlage "Software"

Hallo, ich weiß nicht, ob der folgende Eintrag vom Bot korrekt erkannt werden kann. |platform=[http://wikipedia.org/wiki/Android Android] Gruß --Reneman (talk) 22:19, 12 June 2013 (UTC)

Wir wissen es auch nicht.--Markus59 (talk) 09:14, 23 July 2013 (UTC)

Der Bot unterstützt sowas derzeit nicht, deshalb habe ich es mal entfernt. --!i! 11:52, 29 September 2013 (UTC)

Bug report and support

There doesn't seem to be any information on how to file bug reports nor get support. I seem to have a problem where as I'm mapping it just resets, wipes out previous information and starts at zero again and I can't figure out where to send information to.

Please send bug reports to kpm@redmine.enaikoon.null (for null pls use German domaine .de)

Escape characters

If you type in a & (ampersand) or " (quotation mark) or < (less than) or > (greater than) in a note, then you can't load the .osm file in JOSM. These characters should be encoded with the XML entity. eg & for ampersand. --Vclaw (talk) 14:09, 26 August 2013 (UTC)

Forcing activated GPS

The app asks to enable GPS or quit which is very anoying when you just want to export the recorded data. Ogmios (talk) 11:14, 27 August 2013 (UTC)

Not only: if I click close (not activating the GPS) i stick with the software doesn't actually close and an appliaction message (recording active - or something) pops in the notifications - It's even impossible to quit without a GPS connection?

Too slow

My first experience with the recent Keypad-Mapper 3 (3.1.00) as an user of OSMTracker is good, but it could be better.

1. Please remove the long waiting time (which happens when touching on the text-field) until you are able to make a note via the Android keyboard!
2. I do not really know when K-M 3 records the gps coordinates. Maybe there should be something more intuitive. At OSMTracker you know that notes get the gps coordinates when you are pushing the shortcut.
3. Sometimes I get the error that I do not have a GPS signal and my edit cannot be saved. This is annoying. actually it does not always count whether the node is on the right place, but it does count that the housenumber exists in my data somewhere. A warning would be much better.
4. I am a not-only-housenumbers-mapper, so maybe K-M 3 is not the right choice for me. But something like the possibility to switch the interface from housenumbers keypad to something like OSMTracker would be great. This would be an awesome Tracker! This is also subjecting OSMTracker the other way round that there is no housenumber interface.
5. (The survey-date for housenumbers is not really relevant in my eyes because housenumbers do not change very often and in general you are able to view the upload date.)

Finally all these problems make K-M 3 too slow for me at the moment and the usage not beneficial. Maybe I do not understand and know all the features at the moment so somebody can give me some hints what he does to work around these problems. The own habits are sometimes a big problem.

wish list

new features planned for version 3.2

• highlights
  • Configurable buttons:
    Keypad-Mapper is currently highly optimized for mapping house numbers and addresses. With limited effort and annoyance to house number mappers, it is possible to enhance the app for mapping other types of nodes. This feature is exemplified by a story Nic told us: 'After writing KeypadMapper2, I was contacted by a bush pilot; he makes wildlife surveys for African nature reserves. So I changed the buttons of the app from text buttons to image buttons. I added an image chooser so that he can bind each button to an image, a command and a piece of text that will be added to the log file. The target device is a 10" tablet. Attached is the source code.'
    The following features will be implemented:
    
    • add some configurable buttons (or make existing ones configurable) - the configurability should allow for switching additional configurable but fixed OSM tags (e.g. 'roof:shape=gabled') being applied to the next application of an address
    • option to store separate addr:flat values, this is currently done using the notation 'x,y-z' for 'house number, flat range' but this requires a manual translation into two tags
    • option to add wheelchair=*, entrance=*, building=* and other tags associated with buildings, addresses, and house numbers
    • option to add housename/note/fixme etc.
    • option to assign any image to each keypad
    • option to switch between multiple sets of tags
    • editor to allow the user to define the tags to be added to the .osm file when tapping on one of the keys of the keypad
    • option to allow the user to complete tags if required (e.g. add the building height to the tag building:levels=*)
    • option to hide the configurable buttons features
  • provide customisable menu bar:
    customize visible icons and customize icon sorting order, allow 1 or 2 menu bars, allow different menu bars for each screen, allow different menu bars for both orientations
  • integrate geoChat feature: http://wiki.openstreetmap.org/wiki/JOSM/Plugins/GeoChat/API

• other new features
  • list with missing house numbers in the currently active street / around me
  • offline data for street names, postal codes, and city names; allow the area to be downloaded; be able to download and save multiple areas; delete offline data older than x days (customizable))
  • GPS based drop down menus for selecting the current street name, zip code and city name; use online data if available, otherwise offline data
  • customisable track logging interval for .gpx file
  • play sound file or vibrate if GPS reception is poor
  • write HDOP into .gpx file. JOSM can display circles around the track points. The radius of these circles indicates the DOP value (high DOP = bad GPS = large circle).
  • offer a dropdown menu for selecting nearby country, postal code, city/subburb, street in the keypad screen and in the address editor screen
  • include a feature to add addr:flat values like addr:housenumber=15 addr:flats=a-c

• UI improvements
  • save vertical space by presenting a button on the keypad screen instead of the 'note for this location' line
  • additional translations: Chinese, Portugese, Japanese, other?
  • additional menu bar option to enable/disable auto-rotate of display
  • remember address editor settings after quitting the app for the next session
  • allow launching the app without switching GPS on
  • additional menu bar option to switch the LED light of the device on/off for reading a house number
  • allow multiple pictures at the same time

new features in version 3.3 or later (not yet decided)

• implement new screen with OsmAnd features: pan map below fixed marker in the middle of the screen, then enter house number and save it - Is there any chance of this being implemented soon? I currently use OSMPad for exactly this functionality but would love to have the additional features of Keypadmapper (audio, photos etc) if only this feature were enabled - DaCor (talk) 00:27, 25 June 2014 (UTC)
• provide platform to upload recorded data for other mappers to process it with JOSM
• gamification: implement more features to motivate the mapper (e.g. scoring lists)
• allow editing tags of an existing house number
• adopt house number format to http://www.druckeselbst.de/briefbogen/din5008.php
• OpenStreetBugs integration: execute an alert if the mapper is close to a bug reported in OpenStreetBugs or one of the other OSM bug portals and allow the mapper to correct the bug. For the Keypad-Mapper this should be limited to bugs in data the Keypad-Mapper is dedicated to (missing street for house number, missing house number of a building...)
• offer menu item “new street” where house numbers that were already tagged would be asked how old it is, otherwise it will ask for the name of the new street; if this is skipped when the next house number is being created, it will ask again
• add overview map for better orientation
• hide the house number entry field
• option to disable the survey:date key (which is useless in my eyes --Klumbumbus (talk) 00:51, 25 June 2014 (UTC))
• Use offline map data (e.g. from OsmAnd) to assign current street into "associatedStreet" relation and entered number to nearest building in direction indicated. While this won't be perfect, it will probably reduce time to assign addresses. The "raw" .osm file could still be generated as it is today. --Sappjw (talk) 18:31, 27 July 2014 (UTC)
• Add a waypoint (wpt) to the .gpx for each node recorded. This would solve at least two usecases:
  • If there's a POI right there in the sidewalk (e.g. a bus stop or waste basket or bench) or street (hump or bump) while I'm recording houses, I'd like to have its actual position. Perhaps OSMTracker is better for this, but when I switched tasks to OsmAnd to record the bus stop, it discarded the .osm (starting a new one) and stopped recording the .gpx (not creating a new one), so I'm reluctant now to switch away.
  • I had the "distance of the address nodes" set to the maximum (80 feet) by mistake; this was my first time using any version of Keypad-Mapper, I don't know if it was due to a bad default or an errant swipe under poor lighting conditions. With the .osm nodes so far away from the street (to the other side of the blocks!), I was unable to determine where they should actually be, and I ended up discarding the entire hour's mapping. Recording a waypoint would permit visualizing a vector between waypoint and node and then correlating with aerial imagery or building outlines to interpolate position; this would be especially helpful when walking on a sidewalk rather than in the middle of the road.

Information recorded in the waypoints (e.g. both actual and frozen location if they differ, direction and house info) could be processed to make a better tailored .osm (e.g. change left/right position offsets within a range) via scripts and/or a plugin, if one elected to do so. I originally thought of encoding the information in the .osm's latitude and longitude (replacing digits beyond the 7th decimal point) in a form of steganography, but in the .gpx file seems more straight-forward. --goldfndr (talk) 07:33, 7 August 2014 (UTC)

requested features present in current Google Play version

• audio note feature: works similar to the photo feature – allows users to record a voice memo and to save it along with a GPS coordinate. Users can load these voice memos on JOSM for specific GPS positions and to play it back. - implemented 2013-06-13
• improved UI for big tablets; differentiate between phones, phablets and tablets and differentiate portrait and landscape - implemented 2013-06-13
• add 'L', 'F' or 'R' to the list of added house numbers in the keypad screen - implemented 2013-06-13
• add "survey:date" tag to each address node - implemented 2013-06-13
• restore start/stop button known from version 2 - implemented 2013-06-13
• replace the letters 'L', 'F' and 'R' in the keypad screen with arrows ,  ,   - implemented 2013-06-13
• a long tap on house number entry field in the keypad screen opens a full keyboard for entering an unusual house number - implemented 2013-06-13
• various readability improvements (bigger characters, better contrast etc.) especially for mapping in direct sunlight - implemented 2013-06-13
• improved response time of the app in case many house numbers are mapped - implemented 2013-06-13
• new settings option 'turn off GPS updates': allows users to optionally continue with the .gpx route recording, even when the Keypad-Mapper 3 app remains on in background and/or while screen is off - implemented 2013-06-13
• new settings option 'vibrate on save': defines the duration of the vibration when saving an address node (when tapping on ,  ,  ) - implemented 2013-06-13
• new settings option 'keypad vibration': defines the duration of the vibration when tapping on any key except ,  ,   in the keypad screen - implemented 2013-06-13
• new settings option 'use compass': defines up to which speed the compass information is used instead of GPS heading information for calculating the direction - implemented 2013-06-13
• Have option to save the app on the SD card. - implemented 2013-03-01

Potlatch 2

The wiki page says "Potlatch2 cannot load .osm files. Therefore Potlatch is not suitable for processing Kepad-Mapper-3 data" which is not true - Potlatch 2 can and does load .osm files.

If you'd like to post an example Keypad Mapper file somewhere then I can take a look at writing some instructions on how to get it into P2.

--Richard (talk) 08:01, 7 April 2014 (UTC)

Death link

http://overpass-api.de/hausnummern.html in http://wiki.openstreetmap.org/wiki/Keypad-Mapper_3#quick_start

What dispute?

Apparently a recent edit states that support was dropped due to a recent edit, linking to Enaikoon's "spftware" page. Yet this page says absolutely nothing about a "dispute" with the OSM community. what is the source for this?

IpswichMapper (talk) 03:29, 12 January 2021 (UTC)

@IpswichMapper: yeah, it seems needlessly alarming to me. KM3 is still pretty good, even if development has completely stopped! It might be good to know why, but without knowing anything, I'd say it suffered the fate of lots of software and the developer just lost interest. Nothing wrong with that. —Sam Wilson 09:01, 26 March 2021 (UTC)

The user who wrote that section of the article emailed me (I can't find it know) after I asked them on the talk page. I think they should have responded on the talk page, but oh well. I'm pretty sure they said that they asked Enaikoon directly and Enaikoon said they aren't developing due to a dispute.

The app has become so old now it will start failing on newer devices (especially Android 11 since android 11 now bans you from saving files in your phone's root directory). I have been developing an alternative called SwiftAddress.

@IpswichMapper: Thanks for the update. And that's great news about a new alternative! I'll have a try getting SwiftAddress installed. :-) Sam Wilson 23:58, 31 March 2021 (UTC)