Label/Street Tile without public transportation - here-api

I am looking for a way to disable public transportation on a Label/Street tile request. We have a lot of bustops in Copenhagen and they clutter the map and block street names. They have no value in my use-case.
I know that it is possible to use "Map No Public Transport Tile (mapnopttile)", which I do for normal vector maps, but I also need to show roads/labels on my thirdparty WTMS satellite source.
Is this possible? Does HERE have a place to send in feature requests?
Thank you in advance.

You can use the mapnopttile. Map No Public Transport Tile (mapnopttile) returns a map tile image without public transport information. Here is an example:
https://3.base.maps.cit.api.here.com/maptile/2.1/mapnopttile/c98407140a/normal.day/14/8424/5388/256/png8?xnlp=CL_JSMv3.0.17.0&app_id=inCUge3uprAQEtRaruyaZ8&app_code=9Vyk_MElhgPCytA7z3iuPA&lg=ENG&lg2=ENG

Related

Which is best layer to place mapper code, service layer or controller layer?

I want to ask about Architectural pattern. I write two snippet code to demo what i ask.
The first way is:
//a method on controller layer (in spring framework)
#RequestMapping(...)
public ShopDTO findShop(final Long shopId){
Shop shop = shopService.getShopById(shopId);
ShopDTO shopDTO = shopMapper.toShopDTO(shop);
return shopDTO;
}
//A method on service layer
#Transactional
public Shop getShopById(final Long shopId){
//some code to find an entity by id
}
* Note: the code what maps from shop entity to shopDTO in controller layer.
The second way is:
//a method on controller layer (in spring framework)
#RequestMapping(...)
public ShopDTO findShop(final Long shopId){
ShopDTO shopDTO = shopService.getShopById(shopId);
return shopDTO;
}
//A method on service layer
#Transactional
public ShopDTO getShopById(final Long shopId){
Shop shop = shopRepository.findById(shopId);
ShopDTO shopDTO = shopMapper.toShopDTO(shop);
return shopDTO;
}
* Note: the code what maps from shop entity to shopDTO in service layer.
I use Spring framework code for example.
My question is: Which is the best layer to place mapper code. And can you tell me why ?
By the side, what type logic should place on controller layer and what should place on service layer?
Thanks.
The second way is better.
The reason is, that you want to have certain abstraction between your layers. The controller should just get the shop by its id. That way, you can change how you map and retrieve data without having to change the controller. Then you should go to the next step and think how to best design the abstraction on the boundaries of your data access layer and the service layer.
About what logic to have in the controller. In the controller you should place logic related to the incoming request and the final response of your API. Maybe you can do some validation (althought most is better to be performed via interceptors), extract header values and do things with them and have your final exception handling clause so that nothing spills outside your API unexpectedly and you can reply with the proper HTTP 5xx response. In general the controller should not have large methods, they are primary there to expose your API endpoints.

Firebase, filter results at database level

We are running a project which contains some maps.
We have this under the node:
root.maps //object
It is a list of maps, in case some are private and some are public. Which is under the node:
root.maps.$mapId.config.isPrivate //boolean
root.maps.$mapId.config.uid //string
Now we have a problem. We listen on the maps node for changes, but we want only to return the public nodes, and the private nodes of the user.
So we added rules but it does not seem to work. The maps are either all displayed or none. When we try to set a restriction on a map itself it does not work.
Now after some searching on the internet we read that in order to manage the security rules well the private and public maps should be moved to private or public nodes.
So like this
root.maps.private.$mapId.uid
root.maps.public.$mapId.uid
Which I can't believe is true. In order to change this boolean value, we have to move the complete node from the public to the private node.
Is this really how this database should work? It does not sound logical at all to me.
Is there any other way on how to filter this data based on rules (maps should not be known to the client, client side filtering is not an option)
And if the really strange case of moving complete nodes based on changing boolean values is really true.
What is the idea behind it? This can't be true right?

Access google Maps API in nokia series 40

I want to access the Google map API in series 40 mobiles. I tried with using http connection but the map displayed statically. I want to load the map and moving the location in the map so that I have to use the Google map dynamically.
Please give an idea to do this.
The Google Maps API site does not contain a specific SDK for JavaME (or Series 40). The static Maps API can be used, but only for static images (no dynamic panning or zooming).
A good alternative is to use Nokia's HERE Maps. Its API is designed to work with JavaME and it offers a dynamic experience in Series 40 devices. Code Examples are also available and seem to be quite comprehensive, including panning, zoom and different map types.
PS: I'm not affiliated with Nokia in any way. I do use Here Maps on my Nokia quite frequently and I find it a good mapping solution.
EDIT: I got the Nokia HERE Maps working on a Java SDK1.1 emulator doing the following:
Download the Nokia Asha SDK 1.0. This (HUGE) download contains the most up to date libraries.
Create a new JavaME project using the Java SDK 1.1.
Sign in to HERE Maps and create an App Id and Token.
Add the following code in your MIDlet.
public class MapMIDlet extends MIDlet {
protected void startApp() throws MIDletStateChangeException {
ApplicationContext.getInstance().setAppID("API IP");
ApplicationContext.getInstance().setToken("API TOKEN");
Display display = Display.getDisplay(this);
MapCanvas mapCanvas = new MapCanvas(display){
public void onMapUpdateError(String description,
Throwable detail, boolean critical) {
// Error handling goes here.
}
public void onMapContentComplete() {
}
};
mapCanvas.getMapDisplay().setState(
new MapDisplayState(new GeoCoordinate(52.51, 13.4, 0), 10));
display.setCurrent(mapCanvas);
}
}
Reference the maps-core.jar located in "C:\Nokia\Devices\Nokia_Asha_SDK_1_0\plugins\maps api\lib".
Clean the project and run. This should display a basic pannable and zoomable map.

Where to Use Abstact Class and Where to Use Interface?

I am asp.net programmer.i have read the articles of abstract class and interface and i know how to implement it also.but can anybody explain me practically i.e. by referring project scenario where to use abstract class and where to use interface?
I need a very practical or real world project example, so that i can implement it in my project very efficiently?
Thanks in advanced.
I can't give you a practical example straightaway but let me explain the fundamental difference between both things with small examples:
An abstract class is part of a hierarchical structure of classes. That means they are used for inheritance. Interfaces have nothing to do with inheritance. An abstract class means you cannot instantiate it, and all members (fields, methods and constructors) are inherited by subclasses. An interface can only define methods to be implemented.
You should use an abstract class where you have a hierarchical structure that makes sense:
A vehicle can be an abstract class to car and boat, if you only want actual cars and boats to be instantiated. The vehicle can have a maximumSpeed field, which is then inherited. An interface can not define this field.
You should use an interface when you only need the methods. Suppose you are writing a program that interacts with these vehicles ("drive them"), but does not care about the state of these objects, you can define an interface vehicle with a method drive() so that the program can drive all boats and cars, without knowing what they really are.
Finally, a class can implement multiple interfaces. Another example to show the difference, if you can picture your object in real life, think how you would interact with it. Suppose a coffeemaker, it has an on/off buttons. An "abstract coffee machine" does not really make sense. All you need to know is that there is an setOn() and setOff() method.
I personally like to use interfaces when I have to define a characteristic or an ability of an object regardless of what the object is.
In a "real life" example figure out to have 2 classes, Person and Mones (my nick name :D), and 1 interface, IGuitarPlayer.
So, Mones inherits from Person, and if Mones has the ability to play the guitar it implements the IGuitarPlayer interface.
Since examples from projects depend on the domain, which you have to understand first to be able to understand the example, I will abstract it with a cooking example.
Suppose we want to be able to cook pasta with different sauces: we want to handle pasta independently of its sauce in our source code. A first approach could be that of defining an interface IPasta with a method Cook:
public interface IPasta
{
void Cook();
}
Our client code can then cook the pasta independently from the implementation of it: tomato sauce, pesto sauce? You name it, we can cook it:
...
IPasta pasta = GetPasta();
pasta.Cook();
...
Thinking about the problem more carefully, though, we find out that cooking pasta is always the same process, excluding the point where we want to prepare the sauce.
This means that we have a base algorithm for pasta that we can implement independently from any sauce: boil the water, prepare a sauce, take the pasta out of the pot and merge it with the sauce.
public abstract class Pasta
{
public void Cook()
{
BoilWater();
PrepareSauce();
...
}
protected abstract void PrepareSauce();
private void BoilWater()
{
// Boil some water
}
}
public class PastaWithPestoSauce
{
protected override void PrepareSauce()
{
// Prepare pesto sauce
}
}
And our clients will use it like this:
...
Pasta pasta = GetPasta();
pasta.Cook();
...
So we still have an interface, not in C# sense but in the generic sense of a well known public behavior (the public method Cook of the abstract class), but we also managed to spare some code.

ASP.NET MVC routing based on data store values

How would you tackle this problem:
I have data in my data store. Each item has information about:
URL = an arbitrary number of first route segments that will be used with requests
some item type = display will be related to this type (read on)
title = used for example in navigation around my application
etc.
Since each item can have an arbitrary number of segments, I created a custom route, that allows me to handle these kind of requests without using the default route and having a single greedy route parameter.
Item type will actually define in what way should content of a particular item be displayed to the client. I was thinking of creating just as many controllers to not have too much code in a single controller action.
So how would you do this in ASP.NET MVC or what would you suggest would be the most feasible way of doing this?
Edit: A few more details
My items are stored in a database. Since they can have very different types (not inheritable) I thought of creating just as many controllers. But questions arise:
How should I create these controllers on each request since they are related to some dynamic data? I could create my own Controller factory or Route handler or possibly some other extension points as well, but which one would be best?
I want to use MVC basic functionality of using things like Html.ActionLink(action, controller, linkText) or make my own extension like Html.ActionLink(itemType, linkText) to make it even more flexible, so Action link should create correct routes based on Route data (because that's what's going on in the background - it goes through routes top down and see which one returns a resulting URL).
I was thinking of having a configuration of relation between itemType and route values (controller, action, defaults). Defaults setting may be tricky since defaults should be deserialized from a configuration string into an object (that may as well be complex). So I thought of maybe even having a configurable relation between itemType and class type that implements a certain interface like written in the example below.
My routes can be changed (or some new ones added) in the data store. But new types should not be added. Configuration would provide these scenarios, because they would link types with route defaults.
Example:
Interface definition:
public interface IRouteDefaults
{
object GetRouteDefaults();
}
Interface implementation example:
public class DefaultType : IRouteDefaults
{
public object GetRouteDefaults()
{
return new {
controller = "Default",
action = "Show",
itemComplex = new Person {
Name = "John Doe",
IsAdmin = true
}
}
}
Configuration example:
<customRoutes>
<route name="Cars" type="TypeEnum.Car" defaults="MyApp.Routing.Defaults.Car, MyApp.Routing" />
<route name="Fruits" type="TypeEnum.Fruit" defaults="MyApp.Routing.Defaults.Fruit, MyApp.Routing" />
<route name="Shoes" type="TypeEnum.Shoe" defaults="MyApp.Routing.Defaults.Shoe, MyApp.Routing" />
...
<route name="Others" type="TypeEnum.Other" defaults="MyApp.Routing.Defaults.DefaultType, MyApp.Routing" />
</customRoutes>
To address performance hit I can cache my items and work with in-memory data and avoid accessing the database on each request. These items tend to not change too often. I could cache them for like 60 minutes without degrading application experience.
There is no significant performance issue if you define a complex routing dictionary, or just have one generic routing entry and handle all the cases yourself. Code is code
Even if your data types are not inheritable, most likely you have common display patterns. e.g.
List of titles and summary text
item display, with title, image, description
etc
If you can breakdown your site into a finite number of display patterns, then you only need to make those finite controllers and views
You them provide a services layer which is selected by the routing parameter than uses a data transfer object (DTO) pattern to take the case data and move it into the standard data structure for the view
The general concept you mention is not at all uncommon and there are a few things to consider:
The moment I hear about URL routing taking a dependency on data coming from a database, the first thing I think about is performance. One way to alleviate potentialy performance concerns is to use the built in Route class and have a very generic pattern, such as "somethingStatic/{*everythingElse}". This way if the URL doesn't start with "somethingStatic" it will immediately fail to match and routing will continue to the next route. Then you'll get all the interesting data as the catch-all "everythingElse" parameter.
You can then associate this route with a custom route handler that derives from MvcRouteHandler and overrides GetHttpHandler to go to the database, make sense of the "everythingElse" value, and perhaps dynamically determine which controller and action should be used to handle this request. You can get/set the routing values by accessing requestContext.RouteData.Values.
Whether to use one controller and one action or many of one or many of each is a discussion unto itself. The question boils down to how many different types of data do you have? Are they mostly similar (they're all books, but some are hardcover and some are softcover)? Completely different (some are cars, some are books, and some are houses)? The answer to this should be the same answer you'd have if this were a computer programming class and you had to decide from an OOP perspective whether they all have a base class and their own derives types, or whether they could be easily represented by one common type. If they're all different types then I'd recommend different controllers - especially if each requires a distinct set of actions. For example, for a house you might want to see an inspection report. But for a book you might want to preview the first five pages and read a book review. These items have nothing in common: The actions for one would never be used for the other.
The problem described in #3 can also occur in reverse, though: What if you have 1,000 different object types? Do you want 1,000 different controllers? Without having any more information, I'd say for this scenario 1,000 controllers is a bit too much.
Hopefully these thoughts help guide you to the right solution. If you can provide more information about some of the specific scenarios you have (such as what kind of objects these are and what actions can apply to them) then the answer can be refined as well.

Resources