Hi Peter, Yes, I know. But even though I configure it the same, it will also throw an exception due to my own flagEncoder, if I don't change EncodingManger, or do some similar stuff in GraphHopper. :)
*Best Regards,* *ZhiQiang ZHAO* On Thu, May 28, 2015 at 12:34 PM, Peter <[email protected]> wrote: > Hi John, > > if you load GH from extracted files you setup the GraphHopper class the > same way as you would when doing the import. > I.e. you will have to configure the GraphHopper class identical as you did > for the import. > > Peter > > > On 28.05.2015 21:25, John Zhao wrote: > > There might be a little misunderstanding here. > If I start up GH with extracted files, the below string will be feed into > EncodingManger. > And it will throw an exception due to xxxcar is not found. > > Now my solution is write the similar code as EncodingManger. > My thinking is if we use reflection here, it will be very easy to extend > any kind of flagEncoder. > > I can do it on my own project, but for MoutainBike-->mtb, it's still > annoying. > > Nvm, thank you Peter. > > *Best Regards,* > *ZhiQiang ZHAO* > > On Thu, May 28, 2015 at 12:16 PM, Peter <[email protected]> wrote: > >> you can do so too: >> new YourFlagEncoder("speedFactor=5.0|speedBits=5|turnCosts=true") >> >> or use the normal java way: >> new YourFlagEncoder(5, 5, 1) >> >> Regards, >> Peter >> >> >> On 28.05.2015 21:11, John Zhao wrote: >> >> Thanks Peter for your answer. >> >> I mean "combne" is if I have something inside properties like: >> graph.flagEncoders=xxxcar|speedFactor=5.0|speedBits=5|turnCosts=true, >> bike, mtb, foot >> >> I want to it can be parsed by the program without hard code. >> >> *Best Regards,* >> *ZhiQiang ZHAO* >> >> On Thu, May 28, 2015 at 12:01 PM, Peter <[email protected]> wrote: >> >>> Hi, >>> >>> I'm not sure what you mean with 'combine'. You can mix Java API and read >>> from config too e.g. via >>> >>> graphHopper.init(CmdArgs.readFromConfig(..)) >>> graphHopper.setEncodingManager(new YourFlagEncoder(), new >>> CarFlagEncoder(), ...) >>> >>> > Could you elaborate a little bit more about the portability reason? I >>> am new to reflection. >>> >>> It is just that we want to support JavaScript (TeaVM) and iOS, and for >>> them we need to avoid some stuff. >>> >>> Kind Regards, >>> Peter >>> >>> On 28.05.2015 20:49, John Zhao wrote: >>> >>> Hi Peter, >>> >>> I want to keep the compatibility of combine the existing flagEncoder >>> with my customized flagEncoder. >>> And intialize them from the properties file. >>> >>> Could you elaborate a little bit more about the portability reason? >>> I am new to reflection. >>> >>> *Best Regards,* >>> *ZhiQiang ZHAO* >>> >>> On Thu, May 28, 2015 at 11:44 AM, Peter <[email protected]> wrote: >>> >>>> Hi John, >>>> >>>> if you have a custom flagencoder why not just call >>>> new EncodingManager(new YourFlagEncoder()) ? >>>> >>>> Reflections was abandoned due to portability reasons but also it is not >>>> really necessary here, especially as you use it as a library and you have a >>>> custom flag encoder anyway. >>>> >>>> Regards, >>>> Peter >>>> >>>> >>>> On 28.05.2015 20:14, John Zhao wrote: >>>> >>>> Hi, >>>> >>>> I have a project which use GH as a library. >>>> I have implemented my own flag encoder, like xxxFlagEncoder. >>>> I don't figure out a good way to initialize it, except to change the >>>> EncodingManger to insert xxxFlagEncoder on parseEncoderString(). >>>> I think it's better the change the way EncodingManger initialize all >>>> the flagEncoders. >>>> EncodingManger can use reflection to find the class or flagEncoder from >>>> its name, if we standardize the name and toString method. >>>> >>>> Do you think it's a good idea, or there is a better way? >>>> >>>> >>> >>> >> > > _______________________________________________ > GraphHopper mailing list > [email protected] > https://lists.openstreetmap.org/listinfo/graphhopper > >
_______________________________________________ GraphHopper mailing list [email protected] https://lists.openstreetmap.org/listinfo/graphhopper
