Notices
Page 3 of 105 12 3 4513 Last »
Reply
Thread Tools
rinigus is offline rinigus
2018-08-24 , 17:39
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#21
Originally Posted by DrYak View Post
1. Destination-less navigation :
Added issue https://github.com/rinigus/pure-maps/issues/22 .

Originally Posted by DrYak View Post
2. Foreign-language street names :

Currently when speaking out navigation instruction, the whole sentence string is passed as-is to the speech engine. Which usually gives rise to "To turn right into {completely garbled name }"
(e.g.: last week I was vacationing in Portugal, and the English text-to-speech engine was unable to meaningfully handle the local names).
It's probably going to be even worse if the street names aren't even written in latin script.

In case of using an engine that supports multiple language (like pico with english, german, etc.), would it be possible to flag the street names as the foreign language so that the correct "text-to-phoneme" processor handles it ?
I'm almost sure that the openstreet maps data has the necessary tagging for that.
The question is : does the speech engine support tags to mark different languages (I haven't been playing with TTS engine for at least a decade) ?

Alternative fallbacks would be to generate and concatenate the different parts separately (one separate job on the TTS engine for each separate language block) while using correct punctuation to avoid having the intonation mark an end of sentence.
(pico.say("Turn left into...", "en-US"); pico.say("Hautpbahnhofstrasse.", "de-DE"); )

Another alternative would be to check which speech engine exposes the text-to-phoneme step separately (the one I used I long time ago did), to concatenate them at the phoneme step, and hope that the final phoneme-to-audio engine will be able to manage all the diverse phonemes.
To work properly, the router and TTS engine should understand each other and which parts are spoken in which language. As far as I remember when looking into it, Valhalla doesn't support it. But this can be asked for. I haven't done it, since we don't have TTS engine supporting it well anyway. On TTS side, its supposed to be coded by SSML.

IMHO, we should get a better TTS engine before worrying and hacking around very limited TTS support that we have. Mimic2 and others are developed, but I have not looked into them (https://github.com/MycroftAI/mimic2).

If someone wants to look into it and bring better TTS to the platform - that would be great!
 

The Following 8 Users Say Thank You to rinigus For This Useful Post:
rinigus is offline rinigus
2018-08-26 , 04:16
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#22
Looks like someone used my keys for MapQuest for DDOS attack or some other use. While we are using "Open" versions of geocoder and router, someone used their regular geocoding and directions service. As a result, instead of ~150 calls by Pure Maps users, 16000 were done in addition wiping out monthly quota.

Osmo, MartinK: has something like it happened for you?

For now, please use some other service for routing and search.

I would prefer not to think about how to start securing the keys and focus on other aspects. Right now they are available as a part of the source, but that has been like that for other projects as well.
 

The Following 10 Users Say Thank You to rinigus For This Useful Post:
Fellfrosch's Avatar
Fellfrosch is offline Fellfrosch
2018-08-26 , 06:47
Posts: 1,092 | Thanked: 4,995 times | Joined on Dec 2009 @ beautiful cave
#23
Originally Posted by pichlo View Post
For the record, I like the idea of showing the speed limit only when it differs from default. It is a nice reminder to be extra careful.
I concur with that. Maybe that's nice as a option. But for me it's helpful to see the Speedlimit all the time it is available. Sometimes I just miss how fast I'm allowed to drive. Than a short glance on the Display helps me a lot.
 

The Following 5 Users Say Thank You to Fellfrosch For This Useful Post:
rinigus is offline rinigus
2018-08-26 , 07:03
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#24
Originally Posted by Fellfrosch View Post
I concur with that. Maybe that's nice as a option. But for me it's helpful to see the Speedlimit all the time it is available. Sometimes I just miss how fast I'm allowed to drive. Than a short glance on the Display helps me a lot.
Its option already. You could choose on navigation page (the one where you start navigation) whether you want to see it always, on exceeding, or never.
 

The Following 6 Users Say Thank You to rinigus For This Useful Post:
Fellfrosch's Avatar
Fellfrosch is offline Fellfrosch
2018-08-26 , 08:36
Posts: 1,092 | Thanked: 4,995 times | Joined on Dec 2009 @ beautiful cave
#25
Originally Posted by rinigus View Post
Its option already. You could choose on navigation page (the one where you start navigation) whether you want to see it always, on exceeding, or never.
Brilliant - as always

By the way you didn't really answer the question for a liberapay alternative, or have they found a solution for there problems meanwhile?
 

The Following 6 Users Say Thank You to Fellfrosch For This Useful Post:
rinigus is offline rinigus
2018-08-26 , 11:47
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#26
1.3.0 is out.

Its mainly polishing Valhalla's router and exposing its options, including, as requested, consideration of tolls and preference for the shorter route. In addition to earlier types of transportation, you could specify if you go by bus or high-occupancy vehicle. In future, after new OSM Scout Server maps are imported (coming in a week or two), motor scooter and motorcycle will be enabled too (relevant code is commented out right now).

Due to the lack of access to MapQuest for at least about a month now, I have set Stadia Maps as a default router. Use that if you prefer to use online routers. Anyway, Valhalla, the router behind Stadia, is supported the best by the application.

Translations have been updated - thank you all who have worked on it!

Originally Posted by Fellfrosch View Post
By the way you didn't really answer the question for a liberapay alternative, or have they found a solution for there problems meanwhile?
Not yet, let's see when it will reopen. Thanks!
 

The Following 8 Users Say Thank You to rinigus For This Useful Post:
otsaloma's Avatar
otsaloma is offline otsaloma
2018-08-26 , 12:04
Posts: 141 | Thanked: 1,530 times | Joined on May 2011 @ Finland
#27
Originally Posted by rinigus View Post
Looks like someone used my keys for MapQuest for DDOS attack or some other use. While we are using "Open" versions of geocoder and router, someone used their regular geocoding and directions service. As a result, instead of ~150 calls by Pure Maps users, 16000 were done in addition wiping out monthly quota.

Osmo, MartinK: has something like it happened for you?
Ouch. I have noticed some "extra" use, of Mapbox if I recall correctly, basically stats showing use of some particular services that I hadn't shipped with Poor/WhoGo Maps. But that was such small scale use that I didn't bother to react to it. I haven't seen anything that could be called malicious.

But, I have thought about this, the obvious first thing to do is to revoke the key and get a new one. The next step would be to remove the keys from the source and when running qml/qmlscene, read them from environment variables and when building the RPM, write them from environment variables into JSON. The keys would still be installed as plain text, but getting them away from GitHub might help. Plain text files in RPMs and on devices could still be a problem, but that seems more difficult to solve.
 

The Following 11 Users Say Thank You to otsaloma For This Useful Post:
rinigus is offline rinigus
2018-08-26 , 12:34
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#28
Originally Posted by otsaloma View Post
Ouch. I have noticed some "extra" use, of Mapbox if I recall correctly, basically stats showing use of some particular services that I hadn't shipped with Poor/WhoGo Maps. But that was such small scale use that I didn't bother to react to it. I haven't seen anything that could be called malicious.

But, I have thought about this, the obvious first thing to do is to revoke the key and get a new one. The next step would be to remove the keys from the source and when running qml/qmlscene, read them from environment variables and when building the RPM, write them from environment variables into JSON. The keys would still be installed as plain text, but getting them away from GitHub might help. Plain text files in RPMs and on devices could still be a problem, but that seems more difficult to solve.
I did revoke the key, that's done. But yes, let's hope that the attack comes via Github source and not RPM. I'll look into how to inject the keys on RPM building. I was mainly thinking about sed and writing them into the code as a part of packaging. That would allow to keep the code as it is.

For users: I probably would have to do it relatively fast, just to be sure that some other vital service will not be lost. So, if suddenly all online services will stop working, please check whether there is a new version with new access codes is released.
 

The Following 9 Users Say Thank You to rinigus For This Useful Post:
MartinK is offline MartinK
2018-08-26 , 16:18
Posts: 1,548 | Thanked: 7,510 times | Joined on Apr 2010 @ Czech Republic
#29
Originally Posted by rinigus View Post
Osmo, MartinK: has something like it happened for you?
I don't think I've ever encountered something like this. But on the other hand, I don't think this is really avoidable in principle, especially for open source applications. Proprietary apps can try to obfuscate the API key somehow but that's not really doable for open source apps.

Indeed, one possibility is to inject the key at package build time, but each user will still have to get a copy as part of the package. Not to mention that ideally all the package build source artifacts & the build system would be open (as when building packages in Fedora) so there would be no place to hide the key - every user should be able to audit the package build and rebuilt the package, so needs all of the input artifacts.

For that reason I prefer "public" APIs that don't use API keys where possible and that apply IP base rate limiting (IIRC geonames and Nominatim work that way).

Another possibility is to add an option for users to add they own API keys, so they can get stuff working if the default one goes bad or even by default if you want to use an API with so low rate limit a shared key is unusable.
__________________
modRana: a flexible GPS navigation system
Mieru: a flexible manga and comic book reader
Universal Components - a solution for native looking yet component set independent QML appliactions (QtQuick Controls 2 & Silica supported as backends)
 

The Following 9 Users Say Thank You to MartinK For This Useful Post:
rinigus is offline rinigus
2018-08-26 , 17:16
Posts: 1,414 | Thanked: 7,547 times | Joined on Aug 2016 @ Estonia
#30
@MartinK: well said. For now, I have removed the keys from the source and made new ones for services that allow multiple keys. Keys are injected at rpm build time by a small script

Let's see if this will help and whether such accident was one-off.
 

The Following 6 Users Say Thank You to rinigus For This Useful Post:
Reply
Page 3 of 105 12 3 4513 Last »

« Previous Thread | Next Thread »

 
Forum Jump


All times are GMT. The time now is 18:46.

Contact Us - Home - Archive - Top